Breaking Up Multisite

This is by no means the be-all and end-all of how to break up a Multisite. These are, however, methods I’ve used to move Multisites around into brand new places. As always, if you have another method, feel free to explain in the comments, and link back to your own tutorials!

You see, Multisite is great at some things, but breaking up is crazy hard to do. If you want to just disable multisite, it’s not too bad, four steps, and the hardest is to delete the right tables. And if you want to move a whole multisite, it’s not terrible either.

But. What happens when you want to move only one site on the network?

Usually I see this happen when someone is developing a site for someone else, and thinks it’ll be ‘easier’ to do it on their Multisite. After all, the site will be ‘visible’ but clearly a development site, and remote clients can take a look all they want. The minority of people I see doing this for just themselves, knowing the site won’t ever need to be on a Multisite, but taking the ‘easy’ way out. And to them I suggest developing locally, as domain.dev, and then a blanket search/replace on ‘domain.dev’ for ‘domain.com’ when you’re ready to move. Then there is a small group of people who have a multisite installed on localhost for development, which … no. Don’t. It’s localhost. Spin up a new instance of WordPress.

And still, while I lament the shortsighted nature of these things, there are clear-cut use-cases for this that people just can’t predict. Like the day you wake up and realize that Ennis and Jack can stay on brokebackblog.com, but maybe you should move the Hulk.(Ang Lee directed both movies.) Now you have a dilemma. Do you rebrand brokebackblog.com as angleefilms.com? Maybe you just domain map brokebackblog.com/hulk to hulksmashblog.com or maybe, maybe, you don’t want to run the Hulk blogs at all, but your friend Eric does. Certainly there are always options to splitting up a Multisite, yet for the sake of this post, you have decided that Eric (who has bought hulksmashblog.com) should have the whole site, all the posts and users, and you don’t want it on your server at all!

Now what?

Uber Easy: Export and Import

This is straightforward. Install your new stand-alone WordPress instance, export the posts from brokebackblog.com/hulk, import them into hulksmashblog.com, customize the theme and plugins, done. If you don’t have a lot of users, this is the best bet. Yes, you’ll lose a lot of time resetting all the plugins and theme configs, but you probably had to do some of this anyway. All your comments come with, all your images too, so it’s going to be straightforward.

A couple more things to keep in mind. User passwords will need to be reset, which is trivial in my experience, and a good idea anyway if you want to enforce good passwords. Many new themes are getting great at allowing you to export theme settings, so that may ease the pain as well. The plugin settings really are the biggest hassle to me, but in the long run, I’ve found that having to reset them isn’t horrible since the new home usually is a little different from the old one.

Finally, you’ll probably need to search/replace your posts to compensate for the new image location. I prefer Velvet Blues Update URLs, but sometimes I use .htaccess to redirect instead. If you’re moving from an older Multisite, your images will all point to /files/, but newer ones are in /wp-content/uploads/sites/#/ instead. Of course, wp-cli make it even easier, and I use it all the time when moving people at work.

$ wp search-replace brokebackblog.com/hulk hulksmashblog.com

That’s right now my favorite command. It updated everything, with serialization handled safely, and I was done. If I can’t use that, I’ll grab the interconnectit search/replace tool (not just for WordPress) and run that instead, but for me, I install WP-CLI pretty much everywhere now. It’s just so easy!

Ugly Complex: Database Dancing

When you’ve got a more complex situation, like a heavily customized and themed site, with lots of users and content, then you may have to do this the hard way. As before, make your new stand-alone instance of WordPress. Copy down all the plugins and the theme from your multisite, same as before. Instead of importing the content via an XML file, though, we’re going to import the following database tables as well as all the media images. Remember, no import, no media import, so you must SFTP them all over.

Then the DB Tables you need are as follows:

wp_x_*
wp_user
wp_usermeta

This means you need to know your site number (not too hard, you know how to make them show up, right?), but don’t think it stops here! Now you have to rename tables. There are two directions to go. One is to rename all the wp_x_ tables to wp_, and the other is to rename the other two tables to wp_x_user and wp_x_usermeta instead.

Either way you get to fuss even more. And don’t forget what I talked about in Recovering Your Cape: If your tables are named wp_x_ then you MUST have a field called wp_x_user_roles in wp_x_options, or no one will have any permissions at all. This almost makes it easier to think “Well I should just add in _x right?” You’d think, but then you’re stuck with this funny prefix you have to account for in your wp-config.php file, and you also have to consider what if hulksmashblog.com later wants to make itself a multisite. Be nice to the next guy. I would rename the tables, and then run a search/replace for wp_x_ and wp_ using wp-cli or that script.

Now you’re still not done though. You actually moved over all of your users. That means you have a bunch that don’t have any posts. Go to the /users.php screen and sort by number of posts. Nuke everyone who doesn’t have any posts. Of course… what if they had comments and you want to keep that? Sadly that’s not listed. The comments table isn’t tied in to the users table in a easy to calculate way. But remember, deleting a user won’t delete the comment.

Finally, remember you changed the domain name? Do that again, like you did with an import export.

To The Pain: Moving Your Main Site

Ow. Ow. Okay, Jake, here’s where we get messy. There are just too many options to consider, so let’s look at them briefly.

First, if you want to keep the main site at its current location (domain etc), then you want to actually move all the other sites and then disable multisite.

However, if you want to keep the domain as a multisite and give the main site it’s own, new, home, you’ll want to switch out the main site for a subsite (detailed in WordPress Multisite 110 – around page 80), and then move it per one of the other ways… except remember the site number stays as ‘1’ which is to say ‘none’ so you’ll be moving wp_* and only the ones for the site, not the network (which you can’t delete unless you feel like breaking everything).

Finally, and this one boggles my mind, you want to keep the multisite, and all the sites, but separately. You can see there’s no quick fix for this. Move ’em all manually, and have a beer when you’re done, cause it ain’t fast.

Worse….

There’s more? Just a little bit. Keep in mind that any network settings won’t copy over, so W3TC and WordPress SEO, just to name two popular plugins, have network wide settings. Those don’t magically come with, you’ll have to re-build all of that. With W3TC, you should be able to export the settings, but maybe not. Other plugins too may prove problematic. What about BuddyPress? That would pretty much have to be a table-copy over. At least bbPress should be easier, as it’s all CPTs.

Obviously the more layers you get into with this, the messier it gets. Me? I try to do the age old export/import whenever possible.

Ipstenu (Mika Epstein)

I’m Mika (aka Ipstenu) and I’m complicated. I’ve been on the net since the days of dedicated terminals and Novation CAT modems and solved Missionaries and Cannibals (or Goats and Cabbages) before I was six, and blog about WordPress and technical/computer things at Half Elf on Tech.

See Full Bio