WordPress, the online blogging and CMS solution for many web practitioners, released automatic updates as part of its feature set for the 3.0 branch. But is giving a script access to change itself really such a good thing?
I’ve used WordPress for a couple of years now. It’s slowly becoming less focused on blog posts, and becoming more of a content management system/framework. I’ve heard many web developers using WordPress with client sites, and have also had clients requesting WordPress as their system backend.
One hassle of web applications is installing, and keeping them up-to-date. Self hosted Web Applications like WordPress aren’t as easy to update like you would with your anti-virus definitions. It’s not like you can just click one button, and have the newest WordPress update installed onto your server.
WordPress 3.0 released with this features, called Automatic Updates. In the WordPress Dashboard, you can choose to update WordPress to the latest stable release automatically. No FTPing into your server, no more downloading ZIP files from wordpress.org. This is a massive time saver for bloggers, and any webmaster who uses WordPress as their CMS. But surely this must be too good to be true?
Well the fact is, yes it is too good to be true. This feature is a great time saver, and also allows clients with little website development/maintenance skills to automatically upgrade their website to protect against the latest security issues (Which some firms would charge a mint to upgrade your WordPress install for you). But what if it all goes wrong? What if something goes pear shaped? That’s where the issues of the automatic update feature come in.
If you’re a good web developer, you’ll know to take regular backups, store them properly, and generally have a contingency if something goes wrong. With WordPress updates being issued several times a month, it’s imperative that these backups are taken as regularly as possible. But what could go wrong?
Tonight attempting to use the automatic update feature of WordPress, I was told my upgrade was successful. No error messages, nothing to say anything had failed. But it had.
When WordPress does its automatic upgrade thingy, it overrides any PHP/system files that are newer. Any changes your developer may have had to make in these files will be lost. So there’s one risk already. But what happened to me was WordPress overwrote the files, but didn’t complete the job properly. What was left was several files with no content what-so-ever. No PHP code inside them, with a zero byte size. The entire system was rendered useless, with both the administrative backend and website frontend crippled with the PHP errors
Call to undefined function get_option() in ./wp-admin/admin.php on <strong>line 22</strong>
Call to undefined function wp() in ./wp-blog-header.php on <strong>line 14
This leaves you with no interface to roll-back the upgrade. If you’re a developer like me, who’s taken backups of his website, it’s an easy FTP/SSH in and restore your backup. But what if you’ve installed WordPress for a customer, and they’ve done the upgrade themselves, and now they’ve got this error. They’re going to come running to you, and you’re the one that’s going to have to fix it, and quick smart.
WordPress should really have an isolated upgrade system, that allows the reversal of an attempted upgrade if things go wrong. Until that becomes an option, I would recommend that the ability to automatically upgrade WordPress, and all upgrade prompts should be disabled on a client install. If the client wants the latest version of WordPress, then they should come to a professional to install it, and make sure that if something does go wrong, he can fix it.