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.
Christine Hall has been a journalist since 1971. In 2001, she began writing a weekly consumer computer column and started covering Linux and FOSS in 2002 after making the switch to GNU/Linux. Follow her on Twitter: @BrideOfLinux
Full ack. I’m also growing tired of software projects with frantic release cycles. This world is going too fast.
Good, now my WordPress will stay up to date with even more ease.
Great Work WordPress!
Well Christine in the world of Linux distros…there’s some distributions that are like this, they release frantically, and often, and then there are the “slower” distributions, the ones that still use “last year’s” version of GRUB….or have only Firefox 20 as their default browser. And while having the latest & greatest might be noce…..a lot of companies and independent contractors would rather the “stability” of the “slow” distros. Its no insult or slight to the newer stuff but the mindset behind their choice is “if it ain’t broke don’t fix it”. And for some distros this actually is a strong point (CEntOS….Debian) maybe WordPress should have a version for those who need the latest and greatest, and them they could have an LTS version that doesn’t upgrade all that much but that gets the job done?…just sayin’
The only thing they updated was the admin theme and make updates much easier. Why are you complaining? they can make a new release every week if they want if it is only minor.
Good job wordpress!
Maybe WordPress should offer Long Term Support LTS for some releases.
I agree with what seems to be the developing consensus: give us the ability to choose a slower upgrade cycle if we want. I haven’t had any bad problems with upgrades yet, but . . .
Also nice would be one button rollback option if things go bad after an upgrade.
rjb