Migrating to WordPress MU

Notice some activity in my RSS feed? No, don't get too excited - I'm not actually blogging. However, I did move my blog from WordPress to WordPress MU. Here are some thoughts on why and how to do this.

WordPress MU is the multi-user version of WordPress which is used for sites like wordpress.com and edublogs.org. A single WordPress MU site can host many blogs at once. If you have more than one blog this simplifies the process of maintaining, updating, and backup because you can handle all your blogs in one hit. According to the official docs, a single box running both web server and MySQL will get you about 10-20 thousand blogs. WordPress.com currently has over 3 million blogs.

WordPress MU is similar to WordPress in structure, and shares "95-99%" of the core WordPress code. Some points of comparison:

  • MU stores all blogs in a single database. The core WordPress tables (posts, postmeta, comments, links, terms, options, etc) are duplicated once for each blog. There is a single users table; users can contribute to multiple blogs.
  • MU stores all content under "wp-content". Each blog has its own "files" directory under "wp-content/blogs.dir/N", where N is the blog id. Each blog has an upload quota, which defaults to 10Mb, but can be changed in the site preferences.
  • Most (but not all) standard WordPress plugins also work for MU. These are stored under "wp-content/plugins" and are activated in the normal way. There is a separate directory for MU-specific plugins: "wp-content/mu-plugins". These plugins act over all blogs at once and cannot be selectively enabled or disabled. Only the administrator can install plugins; the site preferences control whether plugins are available to user blogs.
  • Many (but not all) standard Wordspress themes also work for MU. These are stored under "wp-content/themes". They can be selectively enabled / disabled via the site preferences. Only the administrator can install themes; there is no theme editor like in standard WordPress. This means that users are limited to the customisation options enabled by individual themes.
  • MU can be installed in two configurations: subdomain and subdirectory. For subdomain mode, each blog has its own domain; if your root site is "domain.tld", blogs will have names like "blog.domain.tld". For subdirectory mode blogs will be named "domain.tld/blog". Subdirectory mode might seem better because it only requires one domain, but some things don't work properly in this mode. One example is the Spam Karma 2 plugin, which has a broken admin interface under subdirectory mode. This appears to be because it does not use the right kind of relative naming for its resources.
  • If you plan to use subdomain mode, you need a host that supports wild-card subdomains. Some hosting services (eg. Bluehost) don't allow this, which means that you need to manually assign sub-domains to your mu-site for each new blog. For a small number of blogs this might be OK, but it won't work if you want to allow users to create their own blogs.

In principle, the basic strategy for migration should be:

  1. Export blog from WordPress to XML.
  2. Install WordPress MU.
  3. Import blog from XML into WordPress MU.

But of course, things are never quite that simple...

As I've already mentioned, there are different ways of installing MU depending on whether you plan to use subdirectory of subdomain mode. I experimented with both before finding a setup that worked: subdomain mode with David Dean's Multi-Site Manager plugin. This plugin makes it easier to host multiple domains from the one installation. Unfortunately, the documentation is not good, but I found I could get by using some helpful tutorials by Richard Bui and Jerry Huang. WordPress MU has multi-site capability as shipped, but it doesn't allow you to just park multiple domains on your site. You can do this, but it won't behave as expected. To get things working smoothly it needs some setup per site, which is where the Multi-Site Manager helps.

Once I did an import into MU I started to notice some differences. Standard WordPress trusts the user and allows almost any vaild HTML to be used in the document text. WordPress MU is more restrictive, and actively limits the tags and attributes that you can use. For example, I found that I lost all my embedded videos under the default configuration. At first I thought this was an error, but later realised that this was actually what was intended to happen. WordPress MU includes the HTML filter "kses" which removes tags that can potentially be exploited, including OBJECT, PARAM, and EMBED, but also lots of useful attributes like class, id, and target. Fortunately, mu-plugins exist to enable specific features, like Allow Embedded Videos. However, several times I've found myself editing "wp-include/kses.php" to enable the odd attribute that is missing.

I also found that WordPress MU failed to import my tags correctly. This bug has been documented, but for some reason the fix is not in the release version, so it has to be patched by hand.

If your blog posts reference uploaded images or files, you'll need to move the uploaded files from "wp-content/uploads" to "wp-content/blogs.dir/N" (where N is the blog ID). If you're lucky the HTTP paths to the files will be the same. Otherwise, if you need to change the file paths the easiest way to do this is probably to so a search+replace on the paths in the XML version of your blog before doing the import. It may take several attempts to get it right.

On migrating my blog I took the opportunity to change my permalink structure. Originally, I used the default "?p=nn" style permalinks because at the time this was the only scheme that sanely supported relative links to files. Now it seems to work with other schemes too, so I switched to the prettier (and now default) date-and-name based links. Interestingly, the old style "?p=nn" can still be used, so with some judicious fiddling of the post IDs I actually managed to keep two different permalink styles working at once.

Aside from some of these "gotchas", I'm pretty happy with the result though I guess time will tell whether or not it was a good move. I wouldn't recommend it for everyone, but if you have a couple of blogs and want to consolidate your WordPress installations, MU is well worth a look.

4 Comments

  1. Richard Bui:

    The reason your classes and IDs are being stripped is because Donncha syncs the kses.php with WordPress.com's nightly build and WP.com is very restrictive in terms of allowed html codes.

    I would highly recommend instead of hacking the kses.php file, save yourself the headache and use this plugin from Donncha. He created a hook so that when you put this into your mu-plugins folder, whenever you upgrade to a new version, you won't have the same problem anymore.

  2. Stewart:

    Hi Richard,

    Thanks for the suggestion. I've always intended to look into the 'edit_allowedposttags' filter, which seems a better way to go. At first I was confused by the conflicting code, but on closer re-reading it looks like the first example is wrong and that its really not too complex after all.

  3. Il Passaggio a Wordpress MU - Parte 2 | Tekné:

    [...] generale, il suggerimento reperibile in rete circa il trasferimento dei dati, propone di utilizzare le funzionalità esistenti in WordPress, [...]

  4. Increase wordpress multi site quota | Hi Tech Stuff Reviews & Updates:

    [...] a different tune » Blog Archive » Migrating to WordPress MU [...]

Leave a comment