Moving to Multisite

Most of my visitors stop in once, perhaps twice, but are usually arriving based on a Google search query.  They won’t have noticed the proliferation of blogs that I am managing on this server.  There are now 4 and I decided it was time to see if I could bring them into a WordPress Multisite environment.  The goal was to use the software just as does.  A multisite server can host multiple blogs but centralize network administration, including the updating of the system and plugins.

It’s not all wine and roses, however.  Some plugins won’t work in a multisite installation and there are some network administration tasks that are not obvious.  There are also some design decisions that can make the process challenging.

My first attempt was to attempt a multisite based on subdomains (www., archives., etc.).  The sites I was trying to roll together – my personal site, a nature site, one on research, and one on cloud computing – all have third-level domains so this would have worked.  Except for one tragic misstep on my part!  I committed the new environment to a third-level domain itself.  Instead of ending up with as my blog URL, I had, and so on.

The biggest difference between a single WordPress site and a multi-site is that the latter stores most of its information in the database.  Including configuration information such as the host name and site URL.  My plan had been to install the network and then edit the wp-config.php file and other database locations.  This appeared to be pretty straightforward but I could not get the sites to resolve properly once I’d rolled them down to from…

No worries.  I blasted the database and the folder containing the multi-site and started again.  I had exported the content of each of the 4 sites and they continued to respond to visitors once I put my Apache Web server back to where it was serving each blog separately.  I reinstalled WordPress, configured multisite but this time went with subfolders.  I installed the plugins I knew I’d need at the network level, added in the themes, and started importing content again.

This time I tweaked my Apache file so that pointed to the Multisite.  Then each new blog hung off that in its own folder.  Once they were imported, I edited each site’s entry in my Apache2/sites-enabled folder so that (a) the document root was now the file location of the multisite folder and (b) I used ProxyPass and ReverseProxyPass to conver the folder to a site:

ProxyPass /

ProxyPassReverse /

Since is the core of the network, I still have it out there as a separate enabled site in Apache.  I had hoped to resolve and to the same location but I’m not sure that’s a big issue.

I am looking at a couple of plugins to see if they can do this better or differently from Apache.  I feel more comfortable doing this outside of WordPress, though, so I think I may end up sticking with the ProxyPass and using Rewrite to make sure the links resolve properly.

If you are considering multisite, it is pretty straightforward to install and configure.  It is no worse than doing a single installation of WordPress.  The challenge comes in importing old sites – that was time waiting, more than anything – and dealing with other issues.  Once you’ve got the sites resolving properly, you still need to decide how you can handle analytics (site by site or by folder).  I don’t have the added challenge of dealing with users but, having now installed the system, I can see how it would be far more flexible than the current CMS we use at work.

David Whelan

I improve information access and lead information teams. My books on finding information and managing it and practicing law using cloud computing reflect my interest in information management, technology, law practice, and legal research. I've been a library director in Canada and the US, as well as directing the American Bar Association's Legal Technology Resource Center. I speak and write frequently on information, technology, law library, and law practice issues.