How Quickly Do You Upgrade WordPress?

How Quickly Do You Upgrade WordPress?Back in April I wrote an article entitled The Great Plugin Backwards Compatibility Debate, in which I referred to some data showing that a considerable proportion of WordPress users have not installed the latest version (or even the previous latest version, or others before that).

Those figures will be somewhat skewed by inactive sites and the like, but I don’t think anyone could dispute that there are (and probably always will be) a proportion of WordPress users who choose not to upgrade to the latest version of the software.

But why? I would say that there are three common “fears” associated with upgrading:

  1. Fear of theme/plugin incompatibility
  2. Fear of potential bugs
  3. Fear of the unknown

These fears are not irrational – there certainly are a few potential downsides to upgrading. Themes and plugins can break, there can be bugs, and unexpected things can occur.

If you look at the potential downsides, you might ask yourself why you would upgrade. There are two obvious reasons:

  1. New features
  2. Security updates

The problem is that these reasons can be easily outweighed by the aforementioned fears. The benefits of new features typically pale in comparison to the risk of existing functionality breaking down, and security risks are typically only feared by those who have previously suffered from security issues.

So I am interested to know what your thinking is when it comes to upgrading. Do you upgrade immediately, wait for a period of time, or do you actually have no interest in upgrading from a particular version? And what is your reasoning? Let us know in the comments section!

Creative Commons image courtesy of Collin Anderson

14 Responses

  • I usually wait a couple of weeks or longer before I upgrade just to see if anyone is reporting any bugs with the upgrade. But I think for many it’s a case of ‘everything’s running fine, why should I do anything to risk messing it up’. This is probably coupled with the fact that they may not have a backup anyway should anything go wrong.

  • New Recruit

    I maintain about 60 different WordPress installs. Most sites use common plugins and are easy to upgrade but there are some sites with plugins I customised myself. These sites are advanced in my book and draw too many visits per day to afford any down time.

    Each upgrade requires a huge effort and a lot of time; time I don’t have because of new projects being developed. I upgrade as soon as I can, but sometimes this means skipping a few versions of WordPress.

  • We run updates in several staging environments to assess compatibility with different themes and sets of plugins. With many hundreds of WordPress sites including a dozen multisite networks with dozens to hundreds of sub sites, a failed upgrade can be, well, painful. We pretty routinely hold some updates back, particularly if they are not addressing security vulnerabilities.

  • I manage well over 300 WP sites, including several “very large” (20k+ user) multisite networks. If the WP update includes security fixes I update them ASAP – usually almost every site is updated within 4 hours of the release notification.

    In the years of doing updates for these sites I’ve only had a couple significant issues related to the WP upgrades, and they’re almost always related to issues with older themes or plugins. In a couple cases hooks that were used by the active theme or a plugin were no longer available, causing temporary problems while they were addressed (the buddypress group blog plugin, for example, works fine in 2.9.x, but in 3+ breaks the entire site). Of course, if you’ve got good backups, then the worst you’ll lose is a little time while you revert. On the other hand, if you don’t do the update and you get hacked, it could be far worse for your client or for your own reputation. I’m not willing to be that guy. ;)

    However, a couple of the sites I manage are simply not compatible with the current version of WP either due to – well, there’s only one word for it – incompetent theme designers and developers that chose to use WP then hacked the core to death to make it work for them, or sites that rely WAY too much on unmaintained and very old plugins. These would each require too much effort to make them compatible – so they’re addressed differently: more frequent backups, greater monitoring for abuse, file change notification and stuff like that.

    And of course, I pester the client repeatedly to allow me to recreate the site in an upgrade-friendly format. They each either eventually wear down, or decide the site isn’t worth it and abandon the site. In my opinion, either of these is a “win”.

    • Design Lord, Child of Thor

      Hey Shawn,

      Interesting comments – it’s intriguing to see that you update sites almost immediately because of the security-related issues. Given that those security issues were present beforehand (and probably had been for weeks), do you think that the risk is extended that much further by waiting a week or two for any teething problems to come to light?

      On the flip side, I suppose if you’ve only had a few problems over several years, the odds are with you.

      Cheers,

      Tom

      • Posting an update notification that identifies a security fix, as well as the ability to do a diff between the most recent version and the current version, either through downloaded versions or directly in the repository, enables potential attackers to learn how to exploit the vulnerability in literally seconds.

        This is perfectly natural and a desired result of FOSS – after all, WordPress is 100% open source. You WANT people to contribute their ideas and fixes. You don’t necessarily want them to hack it and exploit your entire userbase though. :(

        Let’s compare that to the initial iPhone release. The iPhone is a closed source system. If you want to exploit it, there’s a lot of theory and a lot of brute force – but you can’t simply look at the code for common errors. Nevertheless, less than 3 hours after the initial iPhone release in New York (GMT-5), before stores even opened in California (GMT-8), an exploit vector was identified and a demonstration was published online to use an infected website to take complete control over a visiting iPhone.

        If it’s that easy to exploit a closed system like iOS that had (at the time) *zero* market share, an open source platform with 40 million installations is a very, very tempting target. The most popular malware today (flashback & zeus) use infected websites to propagate. It should come as no surprise that the preferred format for this is WordPress.

        The TimThumb vulnerability was discovered more than a year and a half ago, but even today, every single day I see over 4,000 attempts to exploit various WP installs I host using the TimThumb vector. This botnet that’s currently targeting TimThumb could be refocused to target the upload vulnerabilities in WP 3.3.1 in less than an hour, then it wouldn’t be long before more than half of all WP sites out there were pushing malware.

        As I said in a previous post – it would only take about a dozen lines of PHP+JS to create a self-propagating worm using the WP 3.3.1 vulnerability to effect damage of “Code Red” proportions. And due to the way WP is written, it would be pretty easy to add a few lines to the malware to prevent the internal upgrade system from fixing the hole in infected sites. It could be very ugly.

        I’ve been very tempted to just write it myself as a demo to just how easy it would be to exploit, but that kind of thing never goes over too well. The FBI even went after the company that wrote the “antidote worm” to Code Red. Totally not worth it.

Comments are closed.