Jon Simpson

Managing Wordpress installs with Subversion

28 Dec 2005 — wordpress, subversion

Having had multiple copies of Wordpress installed on my server since the 1.2 version, I’d grown increasingly sick of the upgrade process (mostly involving removing every single non-customized file, replacing it with its new equivalent, then trying to merge the changes gracefully).

For a weblog or two, that procedure might be acceptable, but when the numbers top 10 it takes an unacceptably long amount of time to upgrade on each release. Getting lazy and skipping patches didn’t seem like a good idea, and 1.5 did little to ease the pain (except moving the themes and plugins out of the main codebase).

Into this messy and complicated process, enter public access to Wordpress’s subversion repository over at Armed with shell access to your webserver and 10-15 minutes, you can link your installed copy of Wordpress to a specific release version or branch and have one command updates of your copy of Wordpress. (I’ll save the Subversion evangelism for a later date)

For example, If I wanted to install a new copy of Wordpress on my server using this method. I simply issue the following command in the directory i want the install in:

svn co .

Then at any time afterwards, if I want to bring the code back into line with the version in the repository, i can simply issue a svn up command, to get the latest changes. This works really well for minor point releases with security fixes and the like.

I’ve been using this method since the 1.5 branch, and its worked well. However, transitioning existing installs over to this method isn’t quite as painless as I’d like. The cleanest way I’ve found is to back up the files necessary for your own customisations and check out a clean copy, then merge the two.

My own particular method of doing this is to copy the directory containing wordpress with the existing install to a safe place, to act as a buffer against anything going wrong (say public_html_old), then doing the following…

Warning: Don’t run these commands unless you totally want to remove all traces of a Wordpress install. They remove all Wordpress scripts, plugins, themes, potentially uploaded content and maybe more! Ensure you have backups before continuing…

rm wp-*
rm xmlrpc.php index.php readme.html license.txt
rm -rf wp-admin wp-includes wp-content wp-images

Now all of the files that will clash with the wordpress SVN checkout are gone, and we can grab the copy as before.

svn co .

With the new copy in place, we can copy back the wp-config.php and any custom themes or plugins the blogs were running from wp-content/themes/ & wp-content/plugins respectively in our public_html_old backup.

Another interesting point is shifting between revisions. As I found, if you want to change an install thats sync-ed to a different version tag, you’ll need to switch the location of your repository. This can be done with the command:

svn switch

Or whatever other tag you might want to sync your installed copy to. This is a really great way of installing & maintaining Wordpress that takes most of the effort out of staying up to date. (and given the issues that can arise from out of date versions of popular web applications software, that can only be a good thing).

As for Wordpress 2.0 itself, I’m saving my verdict for a future post.