This was something that was bothering me for a while – Several of my clients’ WordPress blogs were hosted on my server, all with slightly different versions and modifications. This creates a mess of files across all your DocumentRoots – nearly identical but just different enough to become tedious and cluttered. These instructions provide a possible solution: Running wp-mu centrally across any number of top level domains.

These instructions assume a basic knowledge of the command line and MySQL, and that you have at least a VPS or a dedicated server. Shared hosting users do not dispair, as some hosting companies can be awesome and help if you call tech support. Some hosting companies.

I can’t tell you exactly what file to put the Apache directives since every operating system and every version of apache has a number of different places where you can do so, but I would be happy to include different information on where to put these directives for all the different distros and whatnot, I just need people to send them to me!

I’d be curious to hear other people’s takes on this stuff. Please let me know what you think of these methods and if you’ve had any similar experiences.

Initial Setup.

1. Download the wordpress core code with svn. I chose to put it into a directory called /opt/wordpress-mu:

   cd /opt
   svn http://svn.automattic.com/wordpress-mu/tags/2.8.2/ wordpress-mu

   This way, if you want to update later all you need to do is replace [new-version] with the new version number:

   cd /opt/wordpress-mu
   svn switch http://svn.automattic.com/wordpress-mu/tags/[new-version]/

2. Edit your virtualhost file to include the following directives. This is the minimum of what you’ll need to make sure to include:

   <VirtualHost *:80>
     ServerName www.oneofmanyblogs.com
     ServerAlias oneofmanyblogs.com *.oneofmanyblogs.com
     DocumentRoot /opt/wordpress-mu
   </VirtualHost>

3. Restart Apache, navigate your browser to your blog url, and perform the standard wordpress-mu installation process (start at step 4).
4. So what we have now is no different than the standard wordpress-mu install except we’ve decided to install it in /opt instead of a more standard Apache directory like, say, /var/www. Here’s where the magic begins. I have to give a shout out to Reverend over at http://bavatuesdays.com for his excellent post on wordpress-mu’s ability to handle multiple domains, since it led me to the WPMU multiple sites plugin. So let’s continue with this plugin in mind:

   cd /opt/wordpress-mu/wp-content/mu-plugins
   wget http://wpmudev.org/download/1193384369_njsl-sites-009.php

5. Finally, we get to the browser. Navigate to /wp-admin. Since the plug-ins in this folder are automatically activated, you will now see a “Sites” submenu of Site Admin. Click to there and the next bit of awesomeness begins.

Adding Fresh Blogs and Domains

1. Add your new site to the control panel accessible via the “Sites” submenu item of Site Admin. I usually enter the url twice, “/” as the path, and the name of the site as you’d like it to appear in the header of the page. Then, click Create Site.
2. Lets say we’re adding yetanotherblog.com. Go back to your virtualhosts file and edit the ServerAlias line like so:

   ServerAlias oneofmanyblogs.com *.oneofmanyblogs.com yetanotherblog.com www.yetanotherblog.com *.yetanotherblog.com

3. Restart apache again and your new blog should be up and running! It’s as easy as that. Notice that your admin login you created for oneofmanyblogs.com works here as well. Enjoy your new blog. What if you have an existing blog you want to transfer over? Well… that’s a slightly different endeavor.

Migrating an Existing Blog to your new WordPress-MU blog system (ninjas only)

1. Before we begin, do all the steps in the “Adding Fresh Blogs and Domains” section to create a new Site with the domain name of the blog you’re transitioning over.
2. In order to migrate over, you’re going to need a two things: a copy of your original blogs wp-content folder, and a MySQL dump of your original blog’s database. However you choose to get these things to where you need them is up to you. Let’s just assume that you have them. First, merge the files from wp-content/plugins, wp-content/uploads, and wp-content/themes into the central wordpress-mu/wp-content folder.
3. Then, you need to alter your sql dump file a bit. The way WP-MU names the tables is wp_1_[tablename] for the first blog, and wp_2_[tablename] for the second and so on and so forth. Since we’ve already created this blog as a fresh blog, the tables already exist, prefixed, let’s say, by wp_3_. What we’ll want to do is rename every table in your old sites sql dump from wp_[tablename] to wp_3_[tablename], then transfer every table from your old blog over except the wp-options table, the wp_users table, and the wp_usermeta table. (Trust me, including these table will really mess up your chi.)

   mysql -u [user] -p[password] [database-name]
   > RENAME TABLE wp_3_options TO _wp_3_options;
   > exit;
   sed 's/wp_/wp_3_/g' sqldump.sql > sqldump_3.sql
   mysql -u [user] -p[password] [database-name] < sqldump_3.sql
   mysql -u [user] -p[password] [database-name]
   > DROP TABLE wp_3_options, wp_3_users, wp_3_usermeta;
   > RENAME TABLE _wp_3_options TO wp_3_options

4. There, all the heavy lifting is over and now you can log back in as admin, install the plugins, activate the theme, and do all the normal WP-MU admin panel stuff that is not covered in the scope of this tutorial. Not too too bad, right?

Advantages of This System

1. First, from an administrative standpoint, it’s easier to maintain. Installs are done via svn up and you only need to do it once for all the sites. There is a concern about database overhead once you get up into dozens or even hundreds of sites, but for now this works as a solution.
2. Content can more easily shared among the blogs, now that they know about each other a little more and share a database.
3. Each blog can now have a ton of different blogs too. So not only is each domain its own blog, but each domain can have multiple subdomains, all blogs, all running from a central WP install.