The RedMonk IT Report: Automated WordPress Updating

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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
  4. . This tells Subversion to checkout the latest good version of WordPress to ‘yourwordpressdir’ – whether that’s ‘wordpress’ or ‘blog’ or whatever.

  5. 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.

  6. 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.
  7. 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.
  8. 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:

    # 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.

  9. 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.


  1. I was wondering if you’d care to share some of the rationale for doing this. Alex must have made a pretty convincing case for you to move your sites to the bleeding edge of WordPress.

    I’m not very familiar with the PW development model, but based on your svn commands above, it looks like you’re running off the tip of the 2.1 branch. If the nightly builds “move fairly quickly and day-to-day things break as often as they are fixed” (from http://wordpress.org/download/nightly/) what is the stability like on a branch that presumably contains everything that a committer checks in?

    Why did you do this?

  2. Dan: just pinged Alex to confirm, and the answer is that 2.1 is only getting bug fixes now – the active development is on trunk. as a result, it’s just the stable code with fixes applied, making the svn update a (relatively) safe idea.

  3. Yep! And when 2.2 comes out you can do a svn switch to upgrade your repository to the new version. 🙂

  4. Steve: I’m thinking that you’d want to use a setenv statement and create backups of the files in your WP directory by date and keep, say, the last seven days’ worth. Why? Well, what happens if you go on a trip for four days, have little time to check your WP installs, and have things horribly broken? If you had seven days’ worth of backups, you’d be great.

    Of course, if you do this, it’s then time to think about adding some gzipping to the routine, too…

    Now you have me thinking.

  5. I am not really up on who exactly is using WordPress, but does the average user (or majority or large chuck) have the computer knowledge – even though you gave examples – to pull this off or shell access on their account?

  6. […] The RedMonk IT Report: Automated WordPress Updating (tags: wordpress) […]

  7. Thanks for the explanations. Please let me (and all of us) know if this ends up causing you grief, or if the bug fix branch ends up being stable enough that you don’t feel like you’re on the ‘bleeding edge’.

    Now that I know the risk is relatively small, I’d like to find out more about the reward. Were there certain bugs that exposed security holes, or caused you enough inconvenience that auto-updating makes sense?

  8. Steve: Are you doing this on a catch-as-catch-can basis, or are you working this full process up as a CRON job? Because when I said “I’m thinking…”, I started thinking about how to beef up my existing WordPress backup script to do an svn co in the midst of it all. Then you’d have the following:

    1. A nightly backup of your WP files.
    2. A nightly backup of your WP database.
    3. A nightly SVN-committed upgrade, bug-fixed, from-stable branch of WP.

    The existing issues, in my mind, would be getting the database updates done; while this could just be done whenever you log in next, I wonder if this can be processed via wget with some kind of error logging…

  9. Matt: exactly 😉

    Geof: not sure i see that as worth the effort. as long as we’re backing up multiple versions of our MySQL DB’s – and we are – and our plugins/themes would be unaffected by Subversion – and they would – i’m not terribly concerned. worst case i can pull down a good copy, drop in our themes and plugins, and reload the database.

    plus, as it’s the version that’s just getting bug fixes, i’m not terribly concerned about it getting screwed up – let alone four days in a row.

    Dustin: no. that’s why i said “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.”

    Dan: will do – so far so good. as for vulnerabilities, yes, there have been a few – the upgrade to 2.1.1 and the further upgrade to 2.1.2 – just in the last few weeks.

    Geof: as outlined in step 7, i’m running it as a nightly cron. i also have separate scripts that do the first two things you mention – see previous versions of the RedMonk IT Report if you’re interested in how we do remote backups to S3.

  10. Check this one out:

    One other question: How do changes that require database updates work? Do you run the update.php script post svn update?

  11. Mike: interesting. looks a bit more complicated, but interesting.

    as for changes to the DB, i’m 99% sure that none of these updates will incur that penalty. i’m sure when i go to 2.2 – and invoke svn switch i’ll have to, but under this scheme that shouldn’t be necessary.

    even should that happen, however, it’s really pretty simple to hit the admin interface, click “Upgrade” and be done with it.

  12. What about the nice upgrade script at thecodecave.com?

  13. In step 4. one is good advised to restore the “wp-content/uploads” and “wp-includes/languages” directories from the backup, too. Otherwise, your newly established site will lack any images or non-english translations.

  14. Hmm…

    “…2.1 is only getting bug fixes now – the active development is on trunk. as a result, it’s just the stable code with fixes applied…”

    Does this include incremental releases like 2.1.1 and 2.1.2? I ask because 2.1.1 contained a security exploit according to the WordPress blog:

    “Long story short: If you downloaded WordPress 2.1.1 within the past 3-4 days, your files may include a security exploit that was added by a cracker, and you should upgrade all of your files to 2.1.2 immediately.”

    Of course if your process is automated you’d pick up 2.1.2 as soon as it was available, but still…

  15. […] Steve and I even agree on this one. […]

  16. […] finished setting up all the blogs I host to update wp using SVN. What a relief it is to have all those installs up-to-date and knowing I’ll never have to […]

  17. Rick, if you read the announcement carefully you’ll see that only the packaged download was corrupted, not the files in SVN. In fact, the files in SVN are much safer as lots of developers access them, review changes and receive e-mail notifications when they are updated.

  18. […] about using the technique of updating wordpress through SVN but it just dawned on me that the instructions I (and many others) used committed us to the 2.1 trunk. And since 2.2 is a few weeks away I’m […]

  19. […] Your BlogIf you have Subversion installed and you’re running WordPress on a *nix server, both Red Monk and Aaron Brazell have bash files to help you automatically update all of your WordPress […]

  20. […] here) installed and you’re running WordPress on a *nix server, check out — Red Monk and Aaron Brazell’s bash files that help you automatically update all of your […]

  21. This is very, very useful. Thank you! My WordPress and Tarski installs are running off an hourly SVN fetch now.

  22. […] with the minimum of effort. There are a bunch of tutorials out there on this subject (for example, this one). If people are interested I can write up a quick tutorial on how I keep things up to date on this […]

  23. […] Automated WordPress Updating. […]

  24. […] of you that recall that we update our WordPress instances nightly from Subversion might reasonably be wondering: how in the hell did this happen? Don’t you […]

Leave a Reply

Your email address will not be published. Required fields are marked *