Something’s got to give with the WordPress cycle.
Just three months ago, back in September, WordPress issued version 3.6.1 of their content management and blogging platform. Last week they issued 3.8. In between there was 3.7 and 3.7.1, the later release raising eyebrows when it included an automatic “minor point” upgrade feature that can’t be easily disabled.
That’s an average of one release per month, a burden for someone trying to keep sites safe from exploitation by the black hats. By quickening the pace of releases, WordPress may be inadvertently forcing webmasters into remaining with older versions, a potential security risk. Just as the enterprise balked at too much “release often” pressure from their vendors, folks who administer WordPress sites would be justified in complaining and pushing for a solution to this aspect of the WordPress development process.
The problems encountered in a WordPress upgrade mostly center around plug-ins, those apps and applets which not only add functionality to a site but which are a key component of its look and feel and become part of the website’s design. The “compatible up to” release rating of most plugins tends to lag behind a WordPress release date by at least a month or so. Most will work anyway, however, they just haven’t been tested. Others will be badly broken.
In one website I recently saw, out of a dozen plug-ins only two were certified 3.8 ready, and they were plugins officially associated with the WordPress business. Of the remaining plugins, only one was ready for 3.7. The rest were rated for 3.6.1, which had been the latest and greatest only three months ago. The odd thing about this? Some of the plugins had upgraded twice since 3.6 without upgrading their release rating.
In addition to plugins, themes can sometimes pose a problem when upgrading a WordPress site if one of the themes that ships with the WordPress install isn’t being used. Rarely is this a major issue, though it can be.
To avoid issues with a live site, a test install before upgrading is a necessity. At the very least, this will involve installing a database and a version of WordPress’ latest release, along with all the plugins currently being used. It’s recommended that the additional step be taken of cloning the site and then upgrading the cloned test site to the latest version.
The number of plugins that won’t work will vary from release to release. With luck, they’ll all work. Often one or more will be obviously broken. Maybe more likely, certainly more problematic, one or more will seem to be playing nicely, but will be waiting for the right set of circumstances before wrecking havoc. For good reason, WordPress has been tightening its rules and forcing plugins to be compliant, which sometimes causes plugins to behave erratically if an expected connection to an illegal shortcut has been removed.
A broken plugin means a scramble to find a replacement, unless there’s enough money laying around to enable the hiring of a hacker to fix the app for the new install. If plugin use has been judicious, then all plugins on the site are necessary. Finding a replacement can be a long and drawn out ordeal. Since it’s doubtful that an exact replacement will be found, it will be necessary to download and activate several plugins to find one that can comfortably be incorporated into the site without causing drastic change.
That’s a lot of work. WordPress wants this done every month on each and every site using the platform.
To paraphrase Mick Jagger: I don’t have that much jam.
When much development effort is being put into a project, as there certainly is with WordPress, then there is a need for a quick release cycle. However, there is also a need for releases that offer long term support, complete with security and bug fixes, for users requiring stability.
WordPress is a great platform and it’s good to see so much activity around its development. They just need to slow down the pace a little bit so we can keep up.