The RedMonk IT Report: Automated WordPress Updating

Echoing comments that I’ve seen elsewhere, Frédéric Wenzel makes the case for an improved WordPress upgrade experience. The objection is fair, I suppose, because the upgrade process for WordPress isn’t exactly seamless, although neither is it terribly difficult.

On the recommendation of and with help from Alex, who you may have seen listed on the default WordPress blogroll, we’re actually updating our various WordPress properties nightly. Now I don’t have to worry about keeping our various WordPress instances up to date, in case I’ve either missed an important update or am simply out of the office. This is more than a bit important, as all of our blogs run on WordPress and within a week or so www.redmonk.com will too.

What follows is a quick HowTo for setting that up. A couple of caveats: first, I’m assuming you have Subversion installed – if not, do that now (apt-get install subversion on debian/ubuntu). Second, there are lots of different ways to install and configure WordPress; this is oriented to our setup, and thus may or may not work for you. Last, the following steps involve destroying directories and so on; in other words, you can do a lot of damage – even unintentionally. Proceed at your own risk, as I can’t be responsible if something goes wrong. Anyway, on to the HowTo.

With the caveat that your WordPress setup may be different and that I can’t be held responsible if borq your instance, here’s how we set that up (suggested improvements are welcomed):

1. Initial Backup:
   Given that I’m going to have you blow away your existing WordPress directory, a backup is non-optional here. You must back up the directory in question. And besides, it’s easy: a simple cp -r yourwordpressdir yourwordpressdirbackup suffices for the directory. As for the MySQL DB, I just dump the database with an easy mysqldump -u root -p wpdbname > wpdbname_date.sql (with any luck, you won’t need this, but do it anyway). At this point, you should have everything you need to recreate your WP instance backed up in the directory should worst come to worst.
2. Remove the Old WordPress Directory:
   For the following svn steps to work, you need to remove your existing WordPress directory. Do this ONLY if you’re sure that you have a complete backup; if you’re at all unsure, do not proceed. If you are positive that you have a backup – or two – remove the directory with a rm -r yourwordpressdir. If you’re a high traffic site, you’ll want to do this off hours (or more likely, not do it at all), since this will temporarily knock out your site.
3. Lay Down a Fresh WordPress Instance:
   Assuming that you have Subversion installed, this is trivial. Change to the parent directory – your webroot, most likely – and checkout the latest stable version of WordPress. You can accomplish that via the following: svn co http://svn.automattic.com/wordpress/branches/2.1/ yourwordpressdir

. This tells Subversion to checkout the latest good version of WordPress to ‘yourwordpressdir’ – whether that’s ‘wordpress’ or ‘blog’ or whatever.

4. Reset Your WordPress Directory:
   Right now if you were to hit your WordPress instance, it would very likely tell you that it wasn’t configured yet; that’s because it’s not. First, you need to reach into yourwordpressdirbackup directory for the wp-config.php file which tells WordPress where the database is and how to access it. To do this, you do – from the parent directory – a cp yourwordpressdirbackup/wp-config.php yourwordpressdir. This will give WordPress what it needs to hit the existing database, which we’ve backed up but otherwise not touched (and won’t, unless it’s necessary).

   But while your new WordPress instance has what it needs to access the database, it doesn’t have any of the plugins or themes you may have accumulated. To get those over, cd to the parent directory and do a cp -r yourwordpressdirbackup/wp-content/themes/* yourwordpressdir/wp-content/themes and a cp -r yourwordpressdirbackup/wp-content/plugins/* yourwordpressdir/wp-content/plugins. That should ensure that the plugins and themes you were using are available in the new instance.

5. Verify Installation Success:
   First, hit the admin interface for your WP instance – it should be at yourdomain.com/yourwordpressdir/wp-admin. If you’re upgrading from an earlier point version – say, from 2.0 to 2.1 – you may be asked to upgrade the database. If not, everything should appear as normal. Browse over to the plugins and themes to make sure they’re all present and accounted for, and in particular that that correct theme is still selected. If they’re not, revisit the step above and recopy the content over to the wp-content/themes and wp-content/plugins directories. If the wrong theme is activated, simply click on the appropriate one.
6. Check That Subversion Update Works:
   Assuming that you a.) have Subversion, b.) pulled from it appropriately, and c.) haven’t messed with the directory structure, you should be able to do a svn update from the parent directory and watch it verify that you are, in fact, running the latest and greatest version.
7. Automating the Update:
   By now you’re probably wondering where the automation bit comes in – that’s this step. Now that you have a working instance of WordPress whose directory is governed by Subversion, you can simply do a regular svn update and be assured that you’re current. Here’s how I did it, although I’m sure there are better ways.

   First, create a simple bash script called wordpresssvn.sh or whatever you’d like to call it, and insert the following:

   #!/bin/bash
# script to svn update wordpress
cd /path/to/your/parentdir
svn update

   Next, you need to ensure that the script has permission to run – do a chmod 755 wordpresssvn.sh. Then trigger that script: ./wordpresssvn.sh. If all goes well, you should see something like

   Fetching external item into ‘wp-content/plugins/akismet’
   External at revision 8135.

   At revision 4973.

   This means that you’ve successfully cut your WordPress instance over to one that’s Subversion controlled, and written a script that will do the svn update for you. Now you just need to trigger that update automagically. For that, type crontab -e and insert something like the following 30 3 * * * /path/to/your/svnscript/wordpresssvn.sh. That’ll trigger the script – which, in turn, triggers an SVN update – every morning at 3:30 AM.

8. Enjoy:
   Watch to make sure that everything’s working properly, but you should be golden. Once you’re absolutely sure that everything is working as it should be, you can remove both the database dump and the temporary backup directory.

Let me note also that I have our script running at 3:30 AM for a reason; that reason being that it’s after our nightly web directory and MySQL database backups. In a worst case scenario, then, if the SVN Update does something horrible, I’ll be able to revert to the previously nightly backups just in case.

Anyhow, I’m sure that most of the folks who could follow this already know how to do it, and it’s not applicable to the majority of you who are non-technical. I thought it worth sharing, however, for the folks that might not quite not know how to put all the pieces together, or the folks that might not have thought about doing this before. Oh, and of course in case anyone has corrections.

Hope it’s helpful.