WordPress Automatic Updates: To Protect and Serve

As I checked email before going to bed on Friday night, I found a message in my inbox indicating that my WordPress websites had been updated. A moment of panic set in. I thought I had been hacked!

After checking out my sites and satisfying myself that they had not been hacked, I browsed over to WordPress Codex and started reading about this new “feature”. I quickly learned that it had been initiated with WordPress version 3.7. At that time it didn’t seem to work very well but I guess the idea lived on because the update roll-out for version 3.8.1 was in progress and a lot of the people involved with the development of this feature were congratulating themselves.

protect_and_serveThe motivation behind a feature like this is to improve WordPress security. The assumption of those at the helm is that most users won’t update their sites, a known contributor to hacker intrusion, and the Core Developers want to make the internet a safer place.

In my years as a WordPress website developer I have encountered sites that never get updated, some of which had been hacked. So the idea behind this is not altogether a bad.  The implementation of it is what was objectionable to me.  In my professional opinion, we should have been given the option to enable this feature rather than being forced to disable it after the fact of a roll-out.

I perused the WordPress forum to learn more.  I quickly learned how I could stop this automatic background update from happening again, but it was late and I didn’t want to begin implementing the solution before getting some sleep because I knew it would take hours, due to the number of sites that I am obligated to support and the need to verify post update functionality.

I DID want to know why WordPress, without express permission, had pushed an update to privately owned websites in hosting environments over which they had no authority.  Within the WordPress forums, the Requests and Feedback topic seemed like the best place to post my concern so I started a thread, acknowledging up-front that I had not thoroughly read the release notes.  I also mentioned that I knew what I needed to do to disable the feature.

The next morning I woke up to find that others had joined the conversation. The inner circle explained that WordPress would be doing this from now on. The moderator posted a link, the one that I had already found, which explained how to fine-tune or disable this new feature. Other participants were mirroring my feelings, expressing unhappiness about the roll-out of this new feature. The consensus of member participants seemed to be building and it was clear that I was not alone in my feelings.

The forum moderator had already edited out member feedback (not mine) based on their subjective point of view. Plug-ins were being recommended to manage the feature.  Another member was thanking WordPress for giving them a chance to monetize the event with a fix that disabled the feature for their client base.  One participant said they had lost business because their client had wanted the changes explained before that developer updated the site.

I didn’t have to handle any client upsets but I could appreciate concerns about client wrath. For many of my clients, the time frame for updates must be coordinated because they have campaigns running and cannot risk any downtime. Despite the assurances of the moderator that this was a safe upgrade because it was a minor update, I had seen things go wrong with “minor” WordPress updates before.  The assurances were just words and certainly nothing that could be considered a guarantee.

Regardless, I tried to help manage the crowd that my opening comments had drawn by answering the questions that I could. Some participants were quite … passionate.  Some were more level-headed, just seeking to understand how this situation had come to pass.  It seemed clear to me that people wanted to to choose the time for any updates applied to the sites that they either owned or maintained for their clients. I couldn’t have agreed more!

The biggest complaint seemed to be that we had not been given an opportunity to back up our sites prior to the update. And that was my original point.  It has always been my practice to do a site backup just prior to updating anything so I have a fallback position if something goes wrong. Defenders of this feature kept stressing that they had thought of everything and nothing would ever break.  They insisted that a backup prior to this update was unnecessary.  That just seemed like a justification for usurping control in the name of better WordPress security.  I’d heard far too much of this sort of talk lately.

So the question is: Should we trust WordPress to make these decisions for us?

If it isn’t clear already, my conclusion is that we should not. There are too many variables in play on a website, given all of the different configurations of WordPress installations including plug-in choices, hosting choices, theme choices, etc. In defense of the decision to roll this out, members who were closer to that decision endeavored to invalidate every concern raised by those opposed to it with condescending and dismissive language indicating that they knew better what we needed than we did and they had thought of everything imaginable.

INCONCEIVABLE!

The title of the post borrows language from wording sometimes found on the doors of cars that peace officers drive in the USA. We’re supposed to trust the judgment of authorities over our own common sense, and we try to believe they know better than us but it isn’t always the case, is it?

I’ve been in and around software development for a very long time.  Years of experience have taught me that having a backup is always advised.  Those years have also taught me to never be an early adopter of a software update, especially on a mission-critical business application.  Clearly, a business website is a mission-critical application.  In the case of this weekend’s roll-out of the WordPress Automatic Update, there were no catastrophes at sites that I maintain and/or own.  I’ll not allow WordPress to roll the dice on my dime again, however.

From my first post to my closing post all that I was trying to do was communicate the idea that this could have been done differently by WordPress and that the option for these update should be defaulted to off not on. I posed three alternatives for future developments, all of which fell on seemingly deaf ears.  Not only were the defenders stressing that their implementation of this feature was above reproach, they were implying that the vast majority of WordPress users didn’t have enough common sense to decide whether or not they wanted to have their site updated automatically and this was why the decision was taken out of their hands.  That is a slippery slope, at best…

Here’s a link to the conversation at WordPress:  http://wordpress.org/support/topic/auto-updates.

So I’d like to pose the question to you readers.  Do you feel comfortable about WordPress stepping in between you and your clients by updating the software that is required to keep them running?

One thought on “WordPress Automatic Updates: To Protect and Serve

Leave a Reply

Your email address will not be published. Required fields are marked *