Making WordPress more complicated than it was previously, they added the Multisite functionality into the 3.0 release. For the majority of Wordpress users this is, or should be, irrelevant, but for those with more than one site it's appealing to have everything in one place. Besides if you successfully switch to Multisite you get to be a 'Super Admin', which is clearly better than an ordinary 'Admin', although it may not mean much to anyone else and I probably won't be adding it to my résumé.
Now this is not the simplest WordPress manoeuvre. I've been managing my own installations for a couple of years now, so have learnt enough to attempt this, and given that I've been successful, now feel qualified to at least recount what I did and the links I found useful, because information is currently a bit thin on the ground, what with it being a new feature.
Here's a summary of where I was and where I am with this now, so you can see whether or not to read on.
How it was before:
I had one WP installation at a top-level domain, another separate installation with it's own theme and plugins in a subdirectory, and they were both running from their own separate MySQL 4 databases on the server.
What I have now:
One WP3.0 Multisite installation with the same main site and subdirectory site, along with two new top-level domain sites (so four WP blogs in total) each running their own separate theme and plugins, and all running from one MySQL 5 database (yes, I thought it would be a great time to upgrade from 4 to 5 as well, as if this wasn't challenging enough).
So if any of that matches your site status, something here might be useful.
What I did
- Upgraded both installations to WP3.0
- Backed everything up
- Made a note of site settings
- Made a note of plugins used by each site and their settings
- Made an OLD folder on the webroot and bunged everything in there
- Made a new MySQL 5 database on the server
- Downloaded and installed a new copy of WP3.0 in the root
- Enabled the multisite function and created a network, using sub-directories as opposed to sub-domains
- Made a new site entry for each of the sites I planned to import or start from scratch
- A bit of tidying
- Imported the old sites into the appropriate new ones
- Domain mapping
- Fiddled around endlessly with settings (this is still going on)
Things I did not do but probably should have
- Check that themes and plugins on the old sites were compatible with a WP3.0 Multisite installation
- Deactivate plugins on the old sites before I started moving things around
- Consideration around migration of multiple users - I skipped this because the only user was me on the old sites. Apparently this is the tool for exporting user data: http://wordpress.org/extend/plugins/cimy-user-manager/
- Anything with Real DNS Records because it all seemed to work without further faffing around with DNS, beyond pointing the domain names to my usual host
- Succeed the first time round and not have to delete everything, reinstate the old sites (the OLD folder is really important), and spend a day feeling stupid and demoralised before drinking lots of coffee and trying again
If you're in a similar boat, here are the details
1. Upgrade to 3.0
I had done this a few weeks ago, so whilst necessary, didn't happen at the same time as the ensuing nightmare. Everything was working fine having done that. It was not broke, and did not need fixing, but could I just leave it all alone? Apparently not…
2. Backing up
There are two parts to this, one being the actual WordPress structure itself (themes, plugins and uploads) and the other being the contents of the database. Also bear in mind if you're using any plugins that store content elsewhere you want to grab them too. A YAPB photo folder, for example, does not reside in either the normal uploads folder or in the database, but in its own directory.
Before you back up, run WP-Optimize on each installation to tidy up the database.
For backing up WordPress I used Wordpress Backup (by BTE). This exports themes.zip, plugins.zip and uploads.zip to wherever you tell it to. So that saves all your customised templates and anything you've uploaded.
For the database you could use a database backup plugin, such as WP-DBManager, in much the same way, although I hadn't found that until later so I did an export via phpMyAdmin, following these instructions from the Codex. (WP-DBManager also does scheduled optimisation, so makes WP-Optimize redundant)
Repeat for each site, saving all exports to separate folders because file names end up being the same and misery will ensue if you forget which goes where.
3. Exporting each site
This is simply going to Tools > Export > Download Export File. I left all the dropdown menus in the default settings, as this gives the most comprehensive export. Save these to their appropriate folders where the backups are sitting, one for each WordPress site that you're migrating.
4. & 5. Making notes of site settings and plugin settings
I wrote down anything I was going to forget on bits of paper. There may be a more 2010 way of accomplishing this, but just presume that the plugins will all need setting up again from scratch when you reactivate them in the new installation.
6. Make a folder on the server called 'OLD' or something similar, and move your entire current installation into it
7. Create a new MySQL 5 database on your server
Make a note of the login details for the new wp-config.php file that you'll be uploading in a minute. All subsequent WordPress sites are going to sit in this database, as opposed to a separate database for each one, which was how I had it set up previously.
8. Download a new copy of WP3.0 and install it in the now empty root of the server
Go through the usual installation steps to get it running, linking it to the new MySQL 5 database. So now you have a normal empty blog.
9. Enable Multisite function
In wp-config.php paste this line just above /* That's all, stop editing! Happy blogging. */
Now when you log back into WordPress you can create a network via Tools > Network. At this point you have to make an irreversible choice between using sub-directories and sub-domains. My host said they did not support wildcard sub-domains so that made the choice for me. A few days later they got back to me and said now they did, but by then I had set everything up and it was working as I wanted it to with sub-directories, so it actually doesn't seem to be too important which you choose, if you're going to use domain mapping. If not, then the choice is how you want your URL's to look for additional sites:
10. Create sites
After that's decided you can make a site in Super Admin > Sites for each blog that's going to exist in the network. Whichever was the main one before will still be the main one, i.e. there's always one blog that sits at the root level the same as with a single installation. All the others exist in sub-folders, with a sub-directory based network at least. That doesn't mean they can't still be top-level domains, as you will see later. Mine is set up like this:
mainsite.com - Path is just / because it's the root site
mainsite.com/subsite - path is /subsite/
site2.com - path is /site2/
site3.com - path is /site3/
So whether each separate blog is going to appear in its URL as being in a subfolder or as a completely separate domain, you just tell WordPress that they're all going to subfolders and then map them later.
11. Tidying new mess
As if this process wasn't laborious enough, you now have to tediously go through each new site and delete the Hello World! post, the About page and all the Links. And that wretched Hello Dolly plugin. Access the Dashboard for each via Super Admin > Sites and then hover over each path location to get the links to appear below: Backed is Dashboard. Also go through the Setting options and set everything up as it was before. Of course you can do all this one site at a time, so delete all the junk, set the settings and then import the old site, then repeat for the other sites. They do all function entirely separately in this regard.
Start with the main site. From the backup files extract the Themes.zip and copy the contents into wp-content/themes/ and do the same for Plugins.zip into wp-content/plugins. This is the same as on a single installation. If you have Uploads.zip for the main site then that can be extracted to wp-content/uploads/ as well. For all other sites uploads will go to a new folder wp-content/blogs.dir/[ID number of site]. Each site gets an ID number when you set it up in the Super Admin > Sites section. This number denotes the table_prefix, which is the set of database tables that relate to that particular blog. This is how all the different blogs can sit in the same database.
Where was I? Themes and plugins. After copying in the themes they have to activated to be available to the sites on the network. Go to Super Admin > Themes and enable them. This is more relevant to the sites you'll import subsequent to the main one, but if you've already copied in a bunch of themes that you're going to use on different sites, then enable them here. If you ever add a theme in the future you have to go back here to enable it.
Now import the actual posts, comments and all related information that was previously exported as an xml file. Go to Tools > Import and select WordPress which will install a plugin to do this. When you've imported everything you can delete this plugin.
This should import everything as it was before, so then just make sure the original theme is activated and go and activate the appropriate plugins. Any that are going to be used for every site can be Network Activated, but bear in mind many plugins may not be compatible with this yet. I've been just clicking it anyway and things generally seem to be working, but that's not really a good reference because no two plugins are the same. So activate them as needed and check the settings are as they were before. Now you should be able to view the site and it'll look the same.
Duplicate the necessary steps for any other old sites that are being transferred. Where plugins are only used on one site, then just copy them to the usual wp-conten/plugins/ and do Activate, as opposed to Network Activate. As Super Admin you'll be able to see all plugins in all the Backend > Plugins pages.
13. Domain mapping
The last step is to get the URL's working as required. I have three separate top-level domains, so they were all set up and I had changed the DNS servers to point to my host. This is worth doing a day before because it can take 24 hours to propagate and start working properly.
For this I followed this process, with a couple of differences. It all worked fine, except when I went to the backend of the sites that had top-level domains mapped I would lose the Super Admin controls, and exist only as a normal Admin, so there were separate log-ins for each site, and skipping back and forth was a pain. To maintain Super Admin status switch on both 'Remote Login' and 'Redirect administration pages to blog's original domain' checkboxes under Super Admin > Domain Mapping - Domain Options. The tutorial says this is a bit iffy, but so far it's worked fine for me.
Now any top-level domains should resolve correctly to the new site you've set up.
I think that's all I did. As the learning curve for me was almost vertical everything was a bit convoluted with false starts, tangents and periods of despair, but I got there in the end and it's all surprisingly stable now. One of the best resources detailing this process, in a somewhat more technically competent manner, is here, which is basically what I followed with variations where appropriate. Also if you get stuck the chap who runs that site is ridiculously helpful, sending detailed emails. And if you get completely overwhelmed he'll do it all for you, for a very reasonable fee.
One of my main concerns was the multiple MySQL 4 to single MySQL 5 database transition, and I couldn't find much understandable information about this, but it seems to have been handled fine by WordPress. The domain mapping plugin also seems to have meant no manual .htaccess rewriting, which was another thing I was only dimly comprehending. All-in-all, another horrific website-related timesink, but well worth it if it works in the end. And of course it's hard explaining to people what you're doing for so long, when the end result is that the front end of your site should look exactly the same as it did before you started.