Updating plugins in WordPress is as simple as clicking a link. When WordPress updates go bad, however, things can get “interesting” in a hurry! Plugins that fail to update properly fall under the heading of “stupid plugin tricks” because typically the developer did something stupid that causes the update to fail.
Being a long-time software developer, I’ve perpetrated my share of stupid programmer tricks so I’m sensitive to the need for testing software to make sure it does what it’s supposed to do. In the context of a WordPress plugin, if the plugin is already installed and working, the update should not cause it to stop working!
Plugins and Settings
Most plugins have settings that we use to tell it how we want it to affect our site in terms of its intended function. For example, the various Google Analytics plugins all want at least the Google Analytics site ID to be entered and saved so that the plugin can communicate with Google Analytics and report site visits and other data. Very often, there are multiple settings. All these settings are typically stored in the WordPress Options table in the database, although there are exceptions.
No matter where the settings are stored, a plugin should leave them intact when it’s updated unless there is a change to the format of the settings, settings are added or removed, etc. In that case, the plugin should be able to update the settings to the new format in such a way that the plugin continues to work as it always did.
Recent Examples of Bad Updates
There must be a “stupid virus” going around because I’ve seen several plugins cause problems with updates in the past couple of weeks. In all cases, there is no reason why the update shouldn’t have been seamless, but in all three cases, the update broke something.
Fatal Errors
One plugin seemed to update fine, but after the update the first time the Spam folder was cleared, fatal errors appeared on the screen. Fortunately, clicking the Back button in the browser was sufficient to recover from the errors, but then it was necessary to go in to the plugin’s settings and refresh them to straighten things out. Several sites continued to show weird behavior so I ended up turning the plugin off on those sites
This was a major version update for this plugin so obviously the developer had rewritten and added a lot of code. Equally obviously, the plugin wasn’t sufficiently tested before releasing the shiny new version.
Broken Connections
Another plugin which had been connected to the client’s Dropbox account via the normal authorization process “forgot” it was connected after the latest major update. Again, the developer made a lot of changes, one of which was apparently to the authorization process for Dropbox
To his credit the developer did specify in the update notes that the connections to various cloud services would need to be redone. What he didn’t specify was that the plugin wouldn’t work correctly after it was updated. His spiffy new version has some rather egregious bugs in it that cause it to be worse than useless.
Settings? What Settings?
The latest offender is a very simple plugin that assigns Google Fonts to various elements of the WordPress site. As some of you know, Google has a collection of over 600 fonts (and counting) that it makes available free to web developers. This plugin makes it simple to choose one of these fonts and have it used for headings, body text, or any number of other elements.
The plugin settings specify which fonts are attached to which elements and even provide custom CSS for unusual circumstances. This could all be done by hand in the theme settings or CSS stylesheet, but the plugin makes it simple for those who aren’t code jockeys.
So, the latest update of this particular plugin wiped out all the settings leaving the previously styled elements displayed with their default styling! There is simply no excuse for this one. As a result of careless programming, a number of web developers and/or their clients will be losing considerable time and money restoring the previous settings.
Who’s Responsible For Testing?
We could make a compelling argument that the programmers are responsible for properly testing their plugins and, of course, they are, technically speaking. The rub is that relying on them is obviously a disaster waiting to happen, so it falls on us to allow for the fact that updates can and will break things.
This means backing up the site prior to any updates, checking the site thoroughly after updates, and making note of settings prior to updates so that if something like that last case happens, the settings can be relatively easily restored without having to resort to a backup.
The moral of the story is this: just because it’s push-button easy doesn’t mean it’s not potentially dangerous! Be careful with all updates of plugins, themes and WordPress itself. Having a good backup is your first line of defense. Our WordPress Backup Guide will help you get that set up.
Like this post? Sign up below to be notified when new posts are published:
Protected by WebARX
Hmm. Kinda like the one showing up on my websites… “The Wordfence Live Traffic feature has been disabled because you have W3 Total Cache active which is not compatible with Wordfence Live Traffic. If you want to reenable Wordfence Live Traffic, you need to deactivate W3 Total Cache and then go to the Wordfence options page and reenable Live Traffic there. Wordfence does work with W3 Total Cache, however Live Traffic will be disabled and the Wordfence firewall will also count less hits per visitor because of the W3 Total Cache caching function. All other functions should work correctly.”
Yep. That would be another stupid plug-in trick. Ya gotta laugh or some days you’d be pulling your hair out.
Thanks for the informative post, John!
Hi, Suzanne,
Actually, the problem I have with that message is that it only shows up once! A client reported it to me when she first saw it, but then when I went to her site to check on it, it was gone. I had to go find another site that had both WordFence and W3 Total Cache active to read the entire message. Messages like that one need to be persistent until they’re dismissed because of their importance.
The real stupidity there is the behavior of W3 Total Cache which happens to be one of the three I mentioned in my post. Remember the “hidden” posts problem we fixed last week? 🙂
Thanks,
John