WPMU Blues

After a couple of days (or hours, effectively) of experimenting with WordPress MU, the insights I gained about it are sobering at best. Here is my preliminary summary about WPMU.

For one, WPMU enforces an up-front decision about sub-domain vs. sub-directory. This means, you’d have to decide whether all your blogs are accessed through something like http://example.com/blog-x/ (sub-directories) or something like http://blog-x.example.com/ (sub-domains). Why on earth can’t I decide for each blog individually?

This brings me to the next thing: There is no support for multi-domains out of the box. The main reason to have a multi-blog platform is to run several blogs on different domains. If I wanted to have a blog about laptops, I’d have a choice between http://laptops.hackadelic.com and http://hackadelic.com/laptops, but not http://hackadeliclaptops.com.

Sure, there is a plugin called Multi-Site Manager, but it is far from sophisticated. On my local test server it crashed repeatedly, and following the instructions for single log-on1 led to a completely unstable system. (It was weirdly “comforting” to find out that a whole bunch of people seem to have continuous trouble with this.)

Not that these things wouldn’t be technically feasible; Drupal and Habari demonstrate they are: They both support any combination of domains, sub-domains and sub-directories, even ports.

Behind the scenes, WPMU was disappointing as well. I’ve already written elsewhere that WPMU is driven by the needs of wordpress.com, and it’s approach to data storage (i.e. its database schema) is a major consequence of this. What WPMU does is to effectively clone all relevant database tables for each blog – an approach known as sharded database architecture. Such an architecture may be well suited for lots (zillions) of unrelated sites, but not too well when the sites are related. (And it is in the nature of things that sites are at least partially related if they are run by the same person or organization.)

There exists a fork of WP called Lyceum which addresses this issue, but it is unclear whether the project will be continued at all. (Personally, I’d find it a pity if not.)

Another headache I have with WPMU is performance. There are some disconcerting reports on the amount of resources WPMU consumes per page load. For wordpress.com this is not an issue, since they run their blog farm on dedicated servers (and a lot of them at that). But I, for my part, would like to stick with an inexpensive hosting plan for as long as I can get away with. (As I see it, the only valid reason to upgrade to a more expensive hosting plan should be increased traffic to your site, not the resource greed of the software you use.)

Also, there are numerous reports on instability of a WPMU installation in different contexts. My main worry here is that WPMU may work for a while, but then bug out with an unlucky combination of themes and plugins in a moment when switching to another concept would be very difficult, or even infeasible.

Essentially, after messing around with WPMU for a while, I started asking myself if Drupal (my other favorite) wouldn’t have been the better choice on the long term.2

Fortunately, there are other ways to run multiple blogs from a single wordpress installation. The most promising one IMO is Virtual Multiblog. The thing I like most about it is that it is based on standard WP. WP is both, less resource-hungry than WPMU (and hence has the better performance), and less buggy (as WP versions, including bug and security fixes, are released sooner than equivalent WPMU versions). The thing I like least about Virtual Multiblog is that it makes upgrades tricky, and automatic upgrades impossible. (On the other hand, WP users have come a long long way w/o automatic upgrades, so it shouldn’t be that much of an issue.) Stephen, the author of Virtual Multiblog, pointed out that WP auto-upgrades run well with it. I haven’t checked it out yet, but I assume that code upgrades can be run from any blog, and database upgrades must be run once for each blog. (Stephen, correct me on this if I’m wrong.)

Anyway, it’ll take some more experimentation before I make up my mind on the matter, and I’ll certainly enjoy every bit of insight I get during this journey. So stay tuned, there’s more to come.

1. i.e. commenting the line “define('DOMAIN_CURRENT_SITE', 'current_site_domain');” in wp-config-php [↩]
2. My decision to build my blog on WP was based on the reasoning that I can start blogging sooner, and spend more time blogging than administering the blog, or trying to find out how things work. These arguments still stand for a single blog. History will tell if they are true for multiple blogs, too. [↩]

6 Comments

• 
  Hiram October 26, 2010 at 7:13 pm

  I’ve been playing around with WPMU and found some theme issues. Although the official line is that all WP themes will work with WPMU, I’ve found this not to be the case – especially in those cases where the theme makes calls to timthumb.php in order to crop images.

  If your theme requires you to insert the URL of a post image as a custom field (which sucks), then you’re probably OK. However, if your theme crops images into thumbnails automatically, there’s a good chance the theme won’t display thumbnails correctly in WPMU.

  Just another FYI…

  Hiram
• 
  Dgold August 2, 2009 at 1:35 pm

  I’m getting back into Virtual Multi-blog after scarcely maintaining my old-school VMB WP set-up for the last few months. That is, I’ve performed Virtual Multiblog following Stephen’s site a long time ago, and recommended it to other folks early on, near when he first described his method on the Nerdaphernalia blog. My first VMB sites still exist, but I understand he’s advanced the technique, so I’m looking around for the latest 2009 infos, and whether to upgrade or start over on mine. Happy to see this blog confirming that VMB is still the best technique.
• 
  Kyle April 23, 2009 at 10:48 pm

  Wow the timing of this series couldn’t be better.

  Im going through the same comparison / decision between, Drupal, WPMU, and the VM for the last week.

  By the way, your plugins are nice!

  Regards,
  Kyle
• 
  Stephen R April 23, 2009 at 3:01 pm

  The main part of the the upgrade is that WordPress downloads the new install and replaces the actual files with the new files. That part works just fine with VM.

  As you surmise, yes you must then run the database upgrade for each blog. Some people (so I’ve heard) do this via local shell script, or via PHP using something like cURL. I just login to each blog, but then I don’t run large numbers of blogs.
• 
  Stephen R April 19, 2009 at 10:48 pm

  Hi — thanks for the nice metion of Virtual Multiblog. 🙂

  Just to clarify something: Updating Virtual Multiblog itself is not automated, but when running WordPress on VMB, the **WordPress** auto-update runs jut fine. Plugin updates also run well.
  • 
    Hackadelic April 19, 2009 at 11:10 pm

    Stephen, wow, WP auto-upgrade works with VM? I wouldn’t have expected that, particularly in conjunction with database upgrades. But if it does – Coolness! You just made my day. 🙂

    I’m going to update my post right away. Many thanks for the hint.