This is not a new article by any stretch (WordPress has been on Subversion for quite some time), but it might help a couple of people I know that use WordPress but have a lousy time keeping it up to date. I tried to use my own experience with moving to Subversion as the basis for this tutorial.
Note: This document makes the following assumptions:
- You have access and proper permissions to a command prompt on a Unix/Linux server.
- Your Web host allows remote Subversion access.
- You understand the basics to how Subversion works.
- You will back-up everything before attempting.
- You have upgraded WordPress before and know how to troubleshoot basic problems with that.
- You understand that I cannot solve problems you might have with your hosting provider.
- You know how to restore your site back to normal if this does not work out for you.
Step 1. Back-up Everything
Using your FTP or SFTP client, download the contents of your Web site to your local machine. Alternatively, if possible, you may move the contents into another folder on your Web server. The goal is to have an empty root directory before we start working with Subversion. You will be copying files back from wherever you move them.
Step 2. Check-out the (latest?) version of WordPress
My current version is [version software='wordpress'], so I will make the assumption that it is also the most current version of WordPress. We will be working with the command prompt on your Web site. To start, let us assume that you have the following structure on your host.
/home/username/web/ -- Root folder displayed when you login.
/home/username/web/public/ -- Contents of your site are in this folder (also often called 'htdocs')
You will start by navigating into the public folder and verifying that it is empty, or at least does not contain any of the files or folders that WordPress uses. This is important, because the check-out routine will fail if it tries to download a file that already exists.
[~/web/]$ cd public
[~/web/public/]$ ls -l
After that, go up a directory right above the contents of your Web site.
[~/web/public/]$ cd ..
Now you will checkout the code from Automattic (the parent company for WordPress). They maintain the servers, and you have the ability to download the exact same codebase that they are using to develop the next version of WordPress. To be safe, we will only download "tagged" versions, because those have been run through the testing process.
[~/web/]$ svn co http://svn.automattic.com/wordpress/tags/2.6 ./public/
Remember to replace ./public/ with the name of the folder containing your site ('htdocs', 'www', etc.). If all goes well, you should see a long scrolling list as the software is downloaded from their servers and on to yours. Watching it happen will make you wonder why you ever downloaded a zip file.
To verify that everything is in working order, visit your site. If you see the 'Welcome to WordPress' message, everything is good. If you see anything else, review these steps again to make sure your files ended up in the right folder. Do not bother going through the install procedure yet.
Now, if you have been following along closely, you will notice that the command above downloaded an older version of WordPress than the one that is currently being offered. I did this to demonstrate the next feature of Subversion and why you will insist on updating all of your Web software this way if able.
You now need to copy some of the files that you backed up back into their proper folders on your Web site. I cannot begin to think of everything you might have on your site, but here are the files I know that I need when I move them around. The two most important files are the configuration file (so that you can skip setting up WordPress again) and the theme folder that you were using before you began this process.
/wp-config.php
/wp-content/themes/[yourthemefolder]/
You will also want to copy your uploads folder and your plugins along with any of the miscellaneous files you had in your root folder (sitemap.xml, robots.txt, etc.).
/wp-content/uploads/
/wp-content/plugins/[yourplugins]
Step 3. Upgrade to the Latest Version
As I said earlier, you will want [version software='wordpress'], not 2.6. I did this to demonstrate the real reason you would want to bother with Subversion in the first place. To make the switch to the new version, navigate into the root of your Web site.
[~/web/]$ cd public
WordPress does not have a 'STABLE' folder like some projects do, so you will need to know what the latest version number actually is. This will probably be fairly obvious on their Web site, but you can use Subversion to find out for yourself.
[~/web/public/]$ svn list http://svn.automattic.com/wordpress/tags/
This will show a long list of versions, dating all the way back to the 1.5 release. The latest release will be the last item on the list. To upgrade to this version, use the 'switch' command.
[~/web/public/]$ svn switch http://svn.automattic.com/wordpress/tags/[version software='wordpress']
You will again see a long list of scrolling files, but this time it is only the files that changed between 2.6 release and the [version software='wordpress'] release.
Conclusion
Once your 'wp-config.php' file, your theme folder and plugins are back in place, visit your site. You may need to login to upgrade your database (particularly if it has been a while since your last update) in order for things to display properly. You might also need new versions of your plugins or theme if there have been substantial changes in the way that all of that works.
Your dashboard will alert you to a new version of WordPress every few months or so as the developers roll out the next release. You should be able to start with "Step 3" and simply change to the latest version number, use the upgrade script and move on. What once could take the better part of an evening now takes only a matter of seconds. It also means that if a security vulnerability occurs, you can issue the fix much faster. This is really handy if you manage several WordPress installs like I do because you can bring all of your sites up to speed in a matter of minutes.
Periodically, I run the 'update' command to catch any hotfixes that the development team might have decided was not worth making a new release (broken javascript or misspelled word). To do so, I run this command on the root folder of my site.
[~/web/public/]$ svn up
If any files have changed, it will catch them up to the latest revision. I hope tutorial helps you simplify your WordPress upgardes using Subversion. If you spot any errors in the steps above, leave a comment and I will get it fixed.