Lately there has been quite a stir at my job regarding WordPress. In this we have played alot with deployment methods, including proxying it through another application to add an extra layer of features. Because of all of this I have had quite a few conversations with teammates about the easiest way to set up a new blog. As I feel I have a very quick and easy way to not only install a new WordPress installation, but also to keep it up to date, I figured I would share it here, in case that knowledge might be helpful to someone else.

A quick warning first, while nothing I am about to describe is necessarily difficult nor hazardous, all of it requires that you have some sort of direct access to your server. In the case of my explanations, I will be speaking of doing this through an SSH terminal connection. Some familiarity and access to Subversion is also needed. Mostly, this is a solution that should appeal to other developers.

Alright, on with it then.

When you first go to install WordPress, you are generally directed to download a nice zip archive of the software. This is generally accepted as an extremely easy way to install WordPress itself, however the trouble with this method comes in later on, when you need to update your installation to a newer version to combat the inevitable bugs that plague all software. While WordPress does a great job of automating most of the process, you are generally advised to back up all of your themes and plug-ins, which you will need to reapply afterward, as the update process will many times over-write some of these files.

The second issues come in from developers like myself who may or may not tweak the WordPress system itself, to perhaps change how tags are encoded. These changes generally will have to be completely redone when a new version comes out. They will be over-written by new versions of the files.

I’m a developer, so let’s start thinking like a developer.

Under the download section of the WordPress site, let’s go to the Subversion access section. Just as they assume you have Subversion installed, so will I. If not, checkout the Subversion website for information on installing it.

For the most part, we are going to follow all the instructions they have here, except for the part on which repository to use. They link to the trunk of their repository, which while generally stable, is still a development version and could have stability or performance issues. As of this writing, the current stable version of WordPress is 2.8.6, so that will be what we use in these examples. However, you can just replace the version number in the examples with whatever is current to stay up to date and avoid installing older versions.

Let’s begin.

From the command-line of the server:

That’s it, as I said, nothing difficult. The rest of the install process is just like in the Famous 5-Minute Install, only start with #2.

Now, what we have done here is basically checkout the repository as if we were going to be programming in it. Normally a developer would make changes and commit them. We definitely won’t be following that part of the life-cycle. However, we now gain all the benefits of allowing Subversion to manage when changes occur, so when we need to update, it can tell us when conflicts occur and as developers, we can manually merge them.

I still strongly suggest you keep backups of your site in case you break something really bad, however these will be for worst case scenarios, hard disk crashed or I rm -Rf /. my whole computer kind of issues.

Keeping up to date

In order to update to a new version of WordPress, now all we need to do is use the switch operation in subversion to switch the tag you have checked out.

While as of this writing that is not a valid version of WordPress, one day when it is, that will be the line I use to upgrade to it. Of course just change the version number to match whatever is current. An update from 2.8.5 to 2.8.6 yielded the following output

Were there to have been a conflict, due to changes would have otherwise been overridden by this update, there would be a ‘C’ next to the file name, instead of a ‘U’ which just means ‘update.’ In that case you would look inside that file and you’ll see both versions of the code inside there and you can then decide how to repair it. In most cases, unless you make changes to the WordPress core though, you will never see this.

This is what I consider the worlds most painless WordPress update, as when a new version comes out, I simply switch to it and the log into the /wp-admin. It will have me update the database, as it does and I am done. Takes less than a minute to update in most cases.

Anyway, hope that is helpful. While I’m sure this is a bit much for many people, at least for developers, it is fairly fluid with our normal process and is by far the ideal way to stay up to date.