In my previous post Version controlling WordPress, I discussed my strategy to organize WordPress-based projects using version control (Subversion in my case). The idea was to make WordPress and plugin upgrades easy enough especially when you are running multiple WordPress based projects. I believe upgrading each WP project individually is a waste of time and is inefficient. Not to mention, that I prefer using subversion to control all changes.
In my post, I suggested a solution to have a copy of WordPress and all the common plugins at a single shared location, this way you would only have to upgrade one true copy and it will magically propagate to all other projects. I would recommend reading the post if you haven’t done so already. As of today, I have six projects following the pattern.
WordPress released their latest version 3.1.1 the other day and there were a couple of plugin updates available as well. I decided to put my strategy to test and see if it was really worth the effort.
I deprecated the existing version of WordPress by deleting it on my SVN repository and then recreating it with the latest version. This is basically a quick way to do the upgrade as I don’t really care about the diffs:
$ svn co https://asims-repository/trunk/$ svn del wordpress-core $ svn commit --message="Deprecating previous version of WordPress" $ wget http://wordpress.org/latest.tar.gz $ tar -xvf latest.tar.gz $ mv wordpress wordpress-core $ svn add wordpress-core $ svn commit --message="Upgrading to 3.1.1"
This resulted in re-creating the wordpress-core folder with the latest version.
Directly pull in from WordPress repository
The above method works absolutely fine but is a bit painful. The reason its painful is because you have to recreate the versioned directory every time you wish to upgrade. That’s not ideal and if you know how subversion works it will store all copies regardless, which will eventually end up hogging your disk space.
There’s an alternate way where you can directly pull in wordpress from their repository. The trick here is not to use the trunk but rather use tags instead. When you wish to upgrade all you have to do is bump up the tag to point to the latest version. This is so much nicer. Here’s WordPress tagged repository:
http://core.svn.wordpress.org/tags/
This is what you need to do to make it work:
# Removing my old wordpress-core project $ svn co https://asims-repository/trunk/$ cd trunk$ svn del wordpress-core$ svn commit --message="Deprecating previous version of WordPress"
# Using the new nicer tag based repository
$ svn propedit svn:externals .
wordpress-core http://core.svn.wordpress.org/tags/3.1.1/
$ svn commit --message="Upgrading to WordPress 3.1.1 (using repo directly)"
$ svn upThis fetches the project from WordPress’ repository which is super cool.
Upgrading plugins
The process to upgrade plugins is very similar. You can either keep clones of plugins in your own repository or pull them out directly from their respective repositories. I prefer the former in this case normally because I usually end up making modifications in some standard plugins.
Deploying projects
Now, all I had to do was to rebuild and deploy projects, which is as simple as running:
$ depro.pl--project=FuzedBulb--default --rebuild
The way it works is that it looks up a config file for project FuzedBulb and checks out all the sources (typically my repository’s trunk). It then copies specific project files defined in the config to the destination folder (www-accessible folder e.g. /var/www/FuzedBulb.com/).
When it completed, FuzedBulb was on the latest version. Awesome isn’t it?!
