Moving WordPress Multisite

I answer this a lot.

Edited to add: If you’re just moving to a new server and keeping your domain name, it’s exactly like moving Single Install WordPress. Just remember to make sure your new server is set up to handle wildcard domains, and your httpd.conf has ‘AllowOverride’ set to ‘All’ and you should be fine. If you’re moving to a new domain name, read on!

Edit #2: The Incerconnectit Search/Replace DB script is also perfect to use, though you still need to manually edit a couple places.

Moving a normal WordPress site is really easy. Copy over your data. Change your URLs, do a search/replace on your wp_posts table (to fix any internal links), go out for a beer. Some of you may need to edit a wp-config file, but mostly that’s it.

Then there’s Multisite, which sucks. See, unlike single installs of WordPress, you can’t change your site URLs easily. Don’t get me wrong, if you’re a Super Admin, you can easily go into WP Admin -> Network -> Sites and edit the sites. You’d have two places to edit it:

On the Info Tab

On the Settings Tab

But here’s where it starts to suck. If you’re changing tech.ipstenu.org to press.ipstenu.org for example, you do that and then you need to go to your database and look for the site posts table (in this case, it’s wp_2_posts) and search/replace tech.ipstenu with press.ipstenu.

That’s not terrible, right? It looks a lot like moving a single install of WordPress.

What if you have your site as subfloders, using ipstenu.org/tech and ipstenu.org/press though? And you want to move everything to lipstenu.org?

This is where it sucks.

See some widgets and theme settings store your data and include your URL. This is done with data serialization as well, which means the length of your URL matters. If you changed from ipstenu.org to Lpstenu.org, then you would be perfectly safe doing a total database search/replace of the domain name! But since I’ve proposed changing it to Lipstenu.org, I can’t do that. Any field that counted my domain name would be off by one, and thus invalid, and thus wipe out my settings. Oh and to make it worse? Depending on how you uploaded your media and included it in your site, your postmeta table might also be filled with this.

It’s important to understand two things here.

  1. This situation exists on a normal single site install.
  2. You don’t have to change it in those places!

And as a maybe third, I know a lot of people who do a blanket search/replace all the time and never have a single problem. But because I know enough who do have issues, I can’t safely recommend you try it unless you have a rock-solid backup of your database.

This brings us to the point. How do you move WordPress Multisite to a new domain name?

Very, very, carefully.

You’re going to have to do some work in the database, so now’s the time to get some coffee and practice not freaking out. If you have phpMyAdmin, editing your WordPress database is not terrifying, but like a cat, should be approached with caution. Remember to take a full backup of your database before you start. A good backup.

First, it’s perfectly safe to edit all wp_posts (and wp_x_posts) tables with a search/replace of your domain name. I strongly suggest using as much of the domain as you can: i.e. http://newdomain.com instead of just newdomain. This will make sure you don’t confidently change the content of your posts. The Incerconnectit Search/Replace DB script is also perfect to use here, but it won’t fix everything, which is why we have another step:

Next you need to manually go through these tables:

  • wp_site
  • wp_blogs

Those two tables are really straight forward, by the way. You’ll see what to edit right away.

Then you have to manually (again) review all the wp_x_options tables and look for THREE fields:

  • home
  • siteurl
  • fileupload_url

Only edit those. And yes, you have to do it manually in each of the options table unless you used the Incerconnectit Search/Replace DB script earlier.

Once you’ve done that, go into your wp-config.php and see if you have to change define( 'DOMAIN_CURRENT_SITE', 'ipstenu.org' ); (depending on your change, you may not).

And … that should be it.

It’s a pain, but it’s not insurmountable.

Right away, though, you can see the complications if you’re moving a site from ipstenu.org/wordpress to ipstenu.org, and while most of the changes remain similar, you need to remain vigilant and attentive with every change you make. The wp_blogs table is where it gets stickiest, as you have to add in the new subfolder (or remove it) by editing a separate field in the row.

Just pay attention, read carefully, and remember to breathe.

About these ads
StudioPress Theme of the Month

Comments

  1. Great write up and I’ve been bitten by the data serialization issue twice before. The first time is happened, I was clueless as the entire network moved fine except for about 80 widgets created by a plugin. Turns out this plugin stored data with serialization.

    At the time (and fairly recently) I’ve found the Search Replace DB script to solve the issue. It’s incredibly useful and not just for WordPress.

    And I believe that the latest Multisite version of BackupBuddy includes the ability to deal with serialized arrays as well…

    • BackupBuddy does something ‘different’ (and as I don’t use it, I don’t quite get it). I have been told that you can use BackupBudy to ‘move’ a site on a MultiSite to it’s own singlesite instance, but it’s outside my use-case so I’ve never messed with it.

      Personally, I’d rather do it manually for a small site so I know what I’m changing and can make a list of it, but that script looks like something I need to put in my bag of tricks for a larger site!

  2. It’s always good to keep the bag-o-tricks full:)

  3. Just for giggles, today I took a file and database backup of my multisite and restored it to the basement box. The host name went from 18 characters to 23 characters.

    I added DNS wildcard for that box and just did a search and replace in the .SQL file for the new host name. The sed command is my friend.

    Updated wp-config.php, uninstalled domain mapping and pulled the trigger importing the modified database backup file.

    Not surprisingly, it worked but some plugins such as Yourls and W3TC complained. See your warning about serialized data.

    I dropped the database and repeated using this tool for the search and replace. Afterwards I removed that tool per the security warning.

    It worked flawlessly. Scary flawlessly. I did a test post and Yourls sent out a tweet. All of the links and references updated and all the other sites (less the domain mapping) just worked.

    Very cool. I was pretty sure it would work as I’ve done this on regular WordPress in my sleep. But now I know that when the bad thing happens I can use my off server backups without a hitch.

Half-Elf? Try Half OFF WordPress ebooks!