Behind The Blog

What do you do if your company has multiple blog sites that you want to maintain as separate distinct sites with their own domains? You could, of course, install a separate instance of WordPress for each domain and run them on separate servers, etc. But if you have your nice shiny WordPress MU running, why couldn’t you just run the different sites on the single instance of WPMU?

The answer of course is that you can very easily do this courtesy of the Domain Mapping Plugin for WordPress MU.

Astute observers of this Voxeo blog site might have already noticed that if you view our blog portal at “blogs.voxeo.com” you might see (depending upon when you visit the site) blog posts from the Tropo blog, as in this image:

When you click on that link, though, you are taken to a site with a different look and feel:

and, in fact, the domain name is different. While the portal and most of the other blogs are off of the “blogs.voxeo.com” domain, this Tropo post is off of “blog.tropo.com“.

Both sites, though, are running on the identical WordPress MU server.

Here’s what I did:

STEP 1: INSTALL THE DOMAIN MAPPING PLUGIN

First I downloaded the Domain Mapping plugin code from the plugin page at the WordPress.org Plugin Directory. I then followed the installation instructions with regard to putting the files in the appropriate places and making necessary edits:

1. Copy sunrise.php into wp-content/. If there is a sunrise.php there already, you'll just have to merge them as best you can.
2. Copy domain_mapping.php into wp-content/mu-plugins/.
3. Edit wp-config.php and uncomment the SUNRISE definition line: define( 'SUNRISE', 'on' );

STEP 2: CONFIGURE THE SITE ADMIN SETTINGS

With the plugin installed, I had a new menu choice under “Site Admin” called “Domain Mapping” where I simply entered the IP address of the blog server and the host name to use for CNAME records (and yes, I crossed out IP address in the image):

STEP 3: CONFIGURE APACHE TO HANDLE NEW DOMAINS

In order for this to work, your webserver has to be able to know that it should be answering HTTP requests for a domain name and what content it should serve up for that domain. In our case, we use Apache and so I edited httpd.conf and added a “VirtualHost” directive pointing blog.tropo.com to my WordPressMU installation (not the real IP address, obviously):

<VirtualHost 1.2.3.4:80>
        ServerName blog.tropo.com
        DocumentRoot /var/www/html/wpmu
</VirtualHost>

Now, I do understand that I actually didn’t need to specifically create a separate VirtualHost entry for blog.tropo.com because I already had an entry for blogs.voxeo.com and because that entry is listed first it would be the default entry for unspecified domains. However, for my own sanity and ease of administration, I like creating separate VirtualHost directives for each domain so that I can easily see in the Apache config what domains it is answering for. More info about using the VirtualHost directive can be found in the Apache documentation. Obviously if you are hosting a zillion domains, you may not want to do this… but in my case I’m only hosting a few.

A quick restart of the Apache server and it’s now ready to answer for that domain.

STEP 4: CONFIGURE DNS TO POINT DOMAIN TO YOUR SERVER

At this point, you need configure your DNS records to actually point to your WPMU server. In my case, I requested our network operations team to add a CNAME record pointing blog.tropo.com to blogs.voxeo.com. In DNS-speak, the record looks like this:

blog.tropo.com.         120     IN      CNAME   blogs.voxeo.com.

For good measure, we also had them point “blogs.tropo.com” over to blogs.voxeo.com in case someone mistyped “blogs” instead of “blog”.

STEP 5: CONFIGURE THE BLOG SETTINGS

With DNS now pointing to your WPMU server, the final step is to configure your blog to respond to this new domain. In the WPMU dashboard for your blog, under the “Tools” menu, there is now a new “Domain Mapping” menu choice as shown in the screen capture on the right side.

This screen lets you add domains to the blog and also configure which domain you want to be the primary domain. Here is a shot of what the page looked like during the setup process after I had added blog.tropo.com to the blog setup:

Once you save the settings and choose the primary domain, your blog now answers with that domain name. If you look at blog.tropo.com you will see that it is its own site and has no sign of being hosted on the “blogs.voxeo.com” server.

[NOTE: The visual difference is because we created a separate WordPress theme for the Tropo blog. It could, of course, have continued to use our standard theme but just started answering from the new domain.]

One note about adding domains…. the box to add a new domain already has “www.” at the beginning, but you do in fact enter the entire domain name into that box, even if you will never use “www.” on the domain. For instance, here I added “blogs.tropo.com”:

I am guessing that the creators of the plugin added “www.” to the beginning of the field so that novices to DNS wouldn’t enter in “www.example.com” if they really wanted “example.com”. I don’t really know why they did it… the key point is that you enter into that box the domain name you want to point to this specific blog.

With the new domain added, here is what the page now looks like – note the link to delete a secondary domain if I wanted to:

That’s it… with these five steps you are done. Your blog will now answer to a different domain name and, with a different theme, can appear to be a completely different site.

DOMAIN MAPPING AND WPMU SITE-WIDE FEATURES

There is one caveat to all this… if you go back to the beginning of this post, I suggested you go to the blogs.voxeo.com portal and click on a Tropo link, which brought you over to a blog.tropo.com post with a different look and feel. There is also one big gotcha here:

There is no way to get back to the Voxeo blog portal from the Tropo blog.

There you are, on the Voxeo blog portal… as you go through the posts for the various (non-Tropo) blogs, they all have the same look and feel and you can easily navigate back to the blog portal or to other Voxeo blogs. Then you click on a Tropo blog link and… ta da… you’re on some other site with no way to get back.

Now this was a deliberate design choice on our part. We want the Tropo blog to be a completely separate site. That’s our choice. And yes, we’ve thought of adding a link to “Other Voxeo blogs” and we may well do that… but for the moment the sites are separate.

My point is that the “blogs.voxeo.com” portal page uses a plugin to display the last 5 entries across ALL blogs hosted on the site.

That plugin doesn’t differentiate between “blogs hosted on the site that answer to ‘blogs.voxeo.com’” and “blogs hosted on the site that answer to other domains“. It just displays the last five posts across ALL hosted blogs.

In our case, I’m okay with it displaying all posts. I want the portal to be an aggregation of all Voxeo content posted out to the web. I’m okay with the user experience of dropping someone into a different site and requiring them to use the Back button on their browser to return to the blog portal.

I’m personally okay with that – but you may not be when you do your own domain mapping…

You need to think about how “site-wide” features will interact with blogs hosted on different domains. If you have a “portal page” like we do that displays the last X posts, will you have it include those from other domains (as I do)? If you use the “site-wide tags” plugin, will you include all posts from all blogs in those lists?

If you do NOT want to include posts from those other domains, you’ll have to muck around with your site-wide plugins to figure out how to constrain the blogs that are included in those plugins. I don’t have any answers here on how easy or not it is to do. I can imagine what I would probably have to do with the site-wide listing I use for our portal page… but again, I don’t have an issue with the current setup. Anyway, you need to think about this.

WHY AM I DOING ALL THIS?

You may be wondering why I went through all this with the domain mapping. The answer is really this:

I want to simplify the amount of system administration we have to do.

With separate WordPress installs, you have to administer each one individually. Separate WordPress upgrades… separate plugin upgrades… separate backups… etc., etc., etc.

I don’t want that. I want to run our sites on one server that I can then centrally administer, backup, etc. I can also easily add or change plugins and make those new features rapidly available across our blogs. If it’s easy to administer, it’s also easy to backup and restore… and I’d rather be writing content than doing sysadmin.

From the Voxeo perspective, setting up “blog.tropo.com” was the first step. We also just moved “labs.voxeo.com” from a static site to one based on the blog server. In the future we’re going to look at moving blog.imified.com over onto this server and maybe even the VoiceObjects developer portal (we’ll see on that one). We also have some older sites like RocketSource.org that we may bring over to host on the site and give them an update in the process.

All in all this ability to do domain mapping is just another example of the power that WordPress gives you to create a blog site for your company or organization.

I hope this post helps with setting this up… feel free to leave comments or questions, although I will say that I have no affiliation with the domain mapping plugin beyond simply using it, so while I can answer questions about what we did, I may or may not be able to answer broader questions about the plugin.