When an orchestra plays, each musician has his/her own part to follow. They are designed to work together by a single composer to create a cohesive whole, a production with real polish.
But now imagine that each part was written by different composers who are supposed to be following some central guidelines, but are largely able to do whatever they want. And now imagine that these composers can “improve” their own scores and introduce them into the overall production at any time, including in the middle of a live performance.
One word: cacophony.
If you use a lot of plugins on a WordPress site, or any open source publishing platform such as Drupal or Joomla, this is almost exactly what you are doing, especially if you have auto-updates activated.
The Challenge
Plugins come from a wide variety of developers with basically no regulation or oversight. Developers tend to encourage users to enable auto-update features, too, so that when they improve their plugins, those changes are automatically pushed through to sites that use them.
This is a pro in that is saves you time and ensures you’re running the most recent version with all available bells and whistles. But you have to risk the con in that it can happen at any time without advance notice and push directly to you live site visible to your audience.
Most of the time, this turns out to be okay, especially if the developer is a larger publisher worried about reputation. For example, if you have Jetpack or Akismet installed, both of which are developed by the core WordPress team, these plugins are usually safe to update with minimal concern. But do you want the random programmer from who-knows-where being able to automatically add code to your website without review (read: add a new oboe line to your symphony between movements)?
Having said that, even established plugins, you often need to be careful. The most popular WordPress plugin for e-commerce is WooCommerce, which was recently acquired by Automattic, the publisher of WordPress itself. In a recent update article discussing the upcoming WooCommerce v2.7 release, scheduled for around March 6, 2017 (hey, that’s today!), there is a section on How will this affect existing plugins? (emphasis added).
If you do anything with product, customer, orders, and coupons, you will be affected in some way. Even if you do a simple update meta call. This won’t break immediately, but your code will not be future proof. As soon as the schema changes in another update, your code will fail.
This is a big deal becasue even though core WooCommerce provides a great deal of functionality, it is designed to provide additional features via plugins (WooCommerce calls extensions), like pulling real-time shipping rates from UPS or connectivity to a specific payment gateway provider.
There are hundreds of these extensions available from WooCommerce directly (some of which are from third party developers) and thousands more via the WordPress plugin repository and premium plugin venders.
When you take all of those variables into consideration, you begin to understand the impact of WooCommerc’s warning about the high likelihood that some of those will break; perhaps immediately, perhaps some indeterminate time later.
I know for a fact that there are plugins on my clients’ sites that will break when WooCommerce is updated to 2.7 unless we prepare, test, and revise them.
“Maybe don’t upgrade?” asks you, cleverly.
You can certainly put off updates but that’s not a sustainable solution. In this WooCommerce example, the planned updates, including those that are going to break things, are good and necessary changes (such as improved security measures and faster performance). You want to incorporate those changes because it will make future code programmers like me write more consistent and easier to maintain. And that translates into fewer downtime or user experience problems and lower legacy costs.
In short, all of the pros more than outweigh the cons but you don’t want to jump in with these updates using a “let’s throw the switch and see what happens” attitude.
Here’s What You Should Do
Ideally, you have an agreement with your web service provider that stipulates a tested and measured update process. This will also help save money becasue the provider will already be familiar with your plugin environment and can test updates and implement changes in far less time.
If this is how your organization operates, you’re in good shape.
At the same time, I guarantee there are plenty of organizations out there with no maintenance contract as a cost cutting measure, they think they can do this directly, or they never had a developer offer it in the first place.
I hear from potential clients like this via panicked messages because everything is busted after a blind update and their site visitors (not to mention board members and executives) are angry. I had a non-arts client fairly recently where an e-commerce plugin update they put in place broke their site so badly it ended up costing more than $3,000 and a couple weeks of downtime to fix it, all to save a couple hundred a month in maintenance fees.
Ironically, they still don’t want a maintenance contract; but I digress.
Regardless if you have a professional maintenance agreement, here are some tips on making sure you can take advantage of update pros while mitigating many of the cons.
- Don’t activate auto-updates for any theme or plugin where you aren’t fully confident upgrades are carefully tested against a wide set of installation environments and not just a vanilla WordPress install (spoiler: this will be a very small list).
- Don’t update blindly just because the WordPress dashboard is nagging you about plugins that have updates.
- Limit how many plugins you install to only those you need. The more plugins you have, the more developers have their fingers in your site and you increase your risk of symphonic cacophony. The tendency is to just find another plugin for every little thing, but that one thing you need often comes with functionality bloat you don’t want. Over time, you end up with a slower site and more opportunities for things to break.
- Consider the source of your plugins. Generally, premium plugins aren’t very expensive, but come with support agreements and warranties. A free plugin that hasn’t been updated in three years, authored by a solo developer going to college in some other country is highly likely to introduce problems unless it’s targeting a very narrowly focused feature. If you don’t have a maintenance agreement, do your due diligence and find out how responsive the developer is to fixing conflicts.
- Maintain a staging site separate from your live site where you can install and test updates before going live. This can be done manually (with a bit of work) on pretty much any hosting, but if your site is on a host with some WordPress-optimized features, they may have automated tools to do this. WPEngine and Liquid Web are just two examples of many dedicated WordPress hosts that provide this feature.
- A support or maintenance contract with your favored web developer is at least worth a look to make sure this is covered. For example, my company offers updates for minor or patch releases included in the contract, while major releases are billed as an add-on because of how much extra testing is required. In the end, be sure to read your service agreements carefully and most importantly, ask questions using specific examples to confirm what help you receive and what might cost extra.
Now about your upcoming Jennifer Higdon performance, I think I’ll slip in some more cowbell.
