|
From a customer service and customer standpoint, I happen to think you were both out of line and it degraded quickly. I am glad to see you not publicly shame the company though. However, I would like to speak to the original premise that a company should have a wget/curlable url for a Wordpress plugin as a basic need for the DevOps world we live in. This is patently false. From a company providing a plugin standpoint this makes no sense at all. If they would like to make a package which works with one of the myriad package management systems, that is one thing. If they would like to create chef and puppet scripts which install their plugin and the associated licensing needs for their clients who use these environments, then fantastic. This could be a market differentiator. But giving just a static URL system may not make business sense for even some of the mid and large size Wordpress plugin companies. It could effect the companies security, revenue model, and even the security of their customers. A DevOps ready plugin system would be a nice feature but it would also require thought and preparation. When I hear that you would like to be able to wget/curl the plugin so you have the "most up to date version of the plugin" without the work of doing this "manually" which is "very annoy", I get concerned. If a consultant I was using for my Wordpress needs were to want to automatically update third part plugins, even if only on initial install, without thoroughly testing and version locking them first, I would be mortified! With RubyGems, npm, and the like, there is a reason we version lock! Particularly in an automated deployment DevOps based environment. With this particular scenario the customer service agent had the right idea, though I admit it took the agent a while to get to the answer and the whole conversation could have been better. If it were me I would download the latest version of the plugin when I was ready to test it. I would test it in my test environments to make sure the most up to date version of the plugin worked as I expected it to, then I would load it into a private repository for deployment. I would then write a simple chef recipe to retrieve the latest version of the plugin on system install, or upgrade the plugin on all of my existing systems. Any future updates to a plugin would just require a single download of the updated plugin when I was ready to test, a test run through the test environment, and then a deployment to where my chef recipe could see the update. Simple, safe, automated, and effective. |
It's not like these wget operations would happen in production, they would happen at scaffold time. But let's not bring this into the realm of whether I know what I'm doing or not.
Most of these plugins provide insular services in and of themselves (i.e. no code in the rest of the project relies on them for anything) so the only way the would break a project is by screwing up with the core software it self, i.e. WordPress.
Anyways - trust me I'd sign for a composer deal this moment, but if I can get a wget/curl url, an api endpoint or anything else over having to go through several webpages and downloading a zip file for every single plugin for every single new project I'll take that deal for the time being.