There are a number of different ways to manage a WordPress installation, everything from not actually managing it yourself (WordPress.com can take care of it for you if you like) through to manually managing things via FTP. I’m going to look at my preferred method, which I think provides a few things that other methods don’t necessarily give you.
- Control: this method puts you in charge (which also means it’s your responsibility to keep things up to date).
- Safety: if you consistently manage your WordPress install using this method, then you’re in a pretty good position to avoid a lot of problems.
- Simplicity: WordPress updates quite often (minor releases at least every month generally). This system means that you can generally update when a new version comes out in a few minutes at the absolute most.
What is this magic system you ask? In a word: Subversion.
If you’re not familiar with Subversion then here’s a definition from The SVN Book, and I suggest you go find out a little bit about working copies, repositories, checking out a working copy, the concept of tags and the “switch” command:
Subversion is a free/open-source version control system. That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.
What that means in our case is that it gives us a system to manage the actual core WordPress files, and handle the changes that happen to those files over time (as new versions are released), while giving us an easy way to go back to an older version if we need to. There are a couple of caveats I should point out right now:
- This is definitely easiest done on a new blog, or if you’re willing to do a “clean install”
- Although this method will allow you to easily revert back to an older version of the WordPress core files, it will NOT handle changing the database (if any changes were made during an upgrade) so you still may find that things are broken if you go backwards!
- You’ll need command line (SSH) access to your web server to do this (and it’ll need the SVN client installed).
The basics of what you want to do here are to set up your blog as a working copy of the WordPress code, direct from their development repository. This gives you the ability to manipulate your working copy easily, using SVN as the control mechanism. Here’s roughly how we do that.
Setting up WordPress using Subversion
The first step is to create your WordPress installation, and as I mentioned, this is most easily done for a new installation or at least in a clean location. From the command line, do something like this:
$ mkdir blog $ svn co http://svn.automattic.com/wordpress/tags/2.7 blog
This will create a new directory (which you may or may not need to do) and then “checkout” a copy of WordPress 2.7 from the official WordPress SVN repo into that directory. That copy is now your “working copy”, but you’re not really going to work with it, you’re going to use it to manage your blog. With that in place, you’ll want to set up WordPress like normal (steps 3.2, 3.3 and then 3.5 of the process described on the WordPress Codex).
At this point you should have a functioning, albeit very basic WordPress installation. You can go ahead and add plugins and themes into their appropriate directories as you normally would, or now that you’re playing with SVN, you could actually also set them all up using SVN (assuming you’re installing plugins from the official WordPress plugin directory). You can get a copy of a plugin direct from its SVN repository like so:
$ mkdir blog/wp-content/plugins/wp-super-cache $ svn co http://svn.wp-plugins.org/wp-super-cache/tags/0.8.6 blog/wp-content/plugins/wp-super-cache
The first “wp-super-cache” bit there is the name of the plugin, which is the same as the name used in the URL for the plugin in the directory (e.g. the last part of http://wordpress.org/extend/plugins/wp-super-cache/). You’ll want to check what the latest tagged version is, and then you can request that directly. You can manage plugin upgrades using the same method described below.
Handling Upgrades
So that’s all wonderful, and you’ve managed to install WordPress (and some plugins) from the command line, but it’s not all that spectacular. The really cool part is when you need to upgrade. The old method would be to go and download the latest version, unzip it and then upload the files to your server. Of course you had to be careful because if you accidentally overwrote your wp-content directory then your carefully-crafted theme and all your studiously-selected plugins were lost in an instant. No need to worry about that any more. When a new version is available, go to the WordPress Release Archive and see what the exact version number you want to upgrade to is, and then do this (from inside the base directory of your blog installation, which in my example was “blog”):
$ svn switch http://svn.automattic.com/wordpress/tags/2.7.1
And then watch SVN do its magic. You’ll see a bunch of file names fly past on the screen – that’s all the files that were updated or modified in the process of changing (“switch”ing) your current working copy to match whatever is tagged as version 2.7.1 of WordPress. The beauty of this is that SVN will ignore any files that are not under version control, which means that it won’t mess with your plugins, your config file or your theme.
Once SVN has finished doing its thing, you’ll want to go and visit /wp-admin/ on your blog, because often a database upgrade will also be required, and that will trigger that process.
With any database updates done, you’re finished with the entire process in just a few minutes. Wasn’t that better than using FTP?