At the University of Mary Washington, we use a multi-network installation of WordPress. For those of you that haven’t heard of multi-network before, or that might like to learn a little more about it, you can check out the slides from one of my recent presentations on the subject.
In addition to running a multi-network install, we also have three separate servers. We run a development server, a staging server and a production server. We use the development server to perform volatile development work, such as adding wholesale new features and developing complicated new plugins; we use the staging server to test new plugin installations, minor theme modifications, etc.; and we use the production server for our live website (natch).
One of the complications we face on a regular basis is how to keep these three servers in sync with each other. If we were simply using a standard WordPress install, or even a standard multisite install, we could simply use a plugin like BackupBuddy to migrate from one server to another. However, the multi-network aspect makes things a little more difficult.
We actually use a hybrid process to backup one site and restore it on a different server.
To begin with, we backup the entire database using BackupBuddy. Once that’s complete, we backup the files of our Web server. We could conceivably use BackupBuddy to perform the file backup as well, but we started running into compatibility issues once our file system got to a certain size. In fact, we discovered that the ZIP interface on *nix systems (not sure if it’s the same way on Windows systems or not) only works on files smaller than 2 gigabytes. Our file backups are regularly around 10 gigabytes, so that’s a no-go for us. Instead, we create a g-zipped tarball of our Web folders through the command line.
At that point, we move the backup file into a public directory accessible through the Web, then we run wget on the alternative server to pull the backup file across the wires (we could download the backup file, then upload it to the alternative server; but with a file ~10 gigabytes, that would take a much longer time, especially over a VPN connection). After the file transfer is complete, we delete the backup file from the original server.
Once that backup file is in place on the new server, we remove all of the contents of the Web directory on that server, untar the backup file and move the files into place. Then, we use BackupBuddy’s “ImportBuddy” interface to perform the initial database import and migration.
If you’re using a regular multisite install, you should be done once you reach this point. However, since multi-network uses multiple “sites”, and ImportBuddy only replaces the URLs from the root site, there is still some work to be done.
In an ideal world, you could run a fairly simple search and replace on the entire database to find all of your old URLs and replace them with the new addresses. In fact, if your development, staging and production servers all use URLs with the same number of characters, you can do that and finish up.
In our case, though, our development, staging and production servers all use different-length URLs, so we have to dig a little deeper. In order to tackle that portion of the process, I wrote a script that queries each table of the database, identifies any instances of any of your old URLs, replaces them, and then updates that table.
I’ve developed the script far enough that I’d like to share it with anyone else that might be in this particular situation. It’s still far from perfect (in fact, on our installation, we have to run it in chunks because it gets to a point where it just stops running), but it’s far enough along that I’d like others to be able to use it.
It should be noted that this is not a WordPress plugin. It is a standalone script that needs to be installed alongside WordPress. To install and use the script, simply upload the multinetwork-migration directory to your public HTML folder. Then, visit /multinetwork-migration/update-imported-database.php in your browser and fill out the form. At that point, the script will start updating each table in the database individually. The script uses AJAX to perform the queries and update the status area to let you know what it’s doing.
You can visit the Subversion repository to download the current copy of the code.