Upgrading Multiple WordPress Installations
Yesterday, I asked a local Phoenix web/design guy just how it was he was able to keep so many WordPress installs seamlessly upgraded, since I have about 30 I’m working on and HATE upgrading. He had a proprietary method that was working well, so I set out to see how hard it’d be to brew my own.
WordPress, like many other open source programs uses a source code control program called Subversion. Subversion exists to keep track of changes to source code. With one line, you can install an entire WordPress installation in just seconds. It’s super fast. With another line, you can upgrade your version of WordPress leaving all your existing themes, plugins and custom files untouched. It’s a phenomenal system. Unfortunately there is nothing secret, or particularly saucy about it. WordPress has a page soley dedicated to installing, updating, using subversion. I highly recommend you read and understand it so you’re not just blindly following my directions. Installing and Maintaining WordPress with Subverison
The “convert your existing installs to subversions” guide above works really well for a couple of installations, but I had 30 existing installations I needed to convert over to Subversion, and I was going to be damned if I was going to sit there repeating commands for each of them. So, I condensed the commands into one line, and ran them sequentially. This set of commands is meant to be run from /home/yoursite. It assumes your default WordPress install lives in /home/yoursite/public_html. Here is the command (PLEASE FOR THE LOVE OF GOD BACKUP BEFORE YOU RUN ANYTHING!):
svn co http://core.svn.wordpress.org/tags/2.9.1 blog-new; cd public_html/; cp -p wp-config.php .htaccess ../blog-new; cp -rpfu wp-content/* ../blog-new/wp-content; cd ..; mv public_html public_html-old; mv blog-new public_html
Here is what it’s doing:
Now, if a new version of WordPress comes out I simply go into that directory and type: svn sw http://core.svn.wordpress.org/tags/2.9.1/ . (Or whatever the latest version is)
However, we can do one better. To “borrow” from Rob Adler’s vocabulary we need to get into the “Automation mindset”. Since we can upgrade the whole installation with just one line, it doesn’t make sense to be cd’ing and cd ..’ing until our eyes bleed. So let’s write some pseduo bash code:
List directories in /home
su to directory/user name (Or change owners of dir later)
For each directory, change to it.
If it contains a folder called .svn and a file wp-config.php
Issue command “svn sw http://core.svn.wordpress.org/tags/2.9.1/ .”
That’s it. It will find every installation of WordPress living in /home and it will upgrade it.
Notes:
If you run anything the requires a license.txt file in / (Auction2Post, Older WFReview versions, etc) then you will need to use a slightly different command. This is the same command, but once everything is done, it copies license.txt to the new blog directory.
svn co http://core.svn.wordpress.org/tags/2.9.1 blog-new; cd public_html/; cp -p wp-config.php .htaccess ../blog-new; cp -rpfu wp-content/* ../blog-new/wp-content; cd ..; mv public_html public_html-old; mv blog-new public_html; cp public_html-old/license.txt public_html
Good stuff – I was the one that PM’d you yesterday about it… Will try to get it into action in the coming days.
This is excellent.
Is creating the new folder and then copying/renaming really necessary? In my experience, if you modify any files locally and then checkout the repository in the future, your modified files will not overwritten.
Also, the license.txt for both A2P and every version of WFR should go in the plugin’s folder. Never any need to put it in the root.
This is the method they suggest in order to create the SVN repository for an existing wordpress install. In the future, you just need to do an upgrade. I didn’t particularly love the way they did it, but it does preserve everything in case you make a boo-boo, which I am rather prone to doing.
As for A2P, If I don’t have my license.txt in the root of the website, the whole blog goes down. It cost me a lot of money during 2.9.1 when I had stuff down for a couple of days because I didn’t know this. I’ll have to try moving the license.txt to the plugin root.
This becomes an important topic if you have more than a handful of sites running wp. I went to wpmu a while ago because of the upgrade problem, but this is a better solution. Also if you use a common theme framework, you only have one main theme to upgrade. Now for those pesky plug ins ..
I considered going to MU but sometimes, on rare occasions, I have to hack apart the WordPress core. This would have been a disaster on MU, because it’s already a disaster on WP classic. Thanks for the comment.