Should I Use WordPress Multisite? Why Not?

WordPress Multisite ( a.k.a WPMU )  has been alluring ever since it was introduced. Sweet! Now I can start my own blog network like, next stop global domination!

Ah, were it that easy I would be an enormous fan. But global domination doesn’t come without hard work unfortunately and if you’re not ready for that then WordPress Multisite can be a curse rather than a blessing.

First let’s establish what is awesome about WordPress Multisite and when you should use it. As a developer you always get talked into building sites for friends and family. To save myself time I have a multisite install I use to host these charity sites. It makes it super convenient for me. Less maintenance. Less setup time. Add the WordPress Domain Mapping plugin and I’m rockin’. WordPress MU is great for this.

It’s also great if you really do need a “network” of blogs. In some cases this is exactly your goal and WP Multisite is the only tool that’ll get you there. Great! Use it!

But it’s the improper use that irks me. Too often development agencies see it a as a shortcut to hosting their client sites or, worse, someone who is not a server admin thinks they will make a quick buck throwing up a multisite on someone else’s servers and selling hosting.

So before using multisite there are a few things to know about it:

  1. It can be a bitch to scale. Each blog instance on your multisite creates it’s own set of 11 tables … no big deal for 50 sites. But once you hit 100 – 200 sites you’re going to start getting some headaches on shared hosting, and just 250 – 500 sites is enough to crater an entire VPS.
  2. Maintenance Costs Grow Exponentially. The cost to maintain your first 50 WPMU sites is relatively cheap. You definitely make some money up front. But the bloating database starts getting expensive to maintain when it has to have it’s own database server, and then even more when it has to be shared across several. Moreover, development slows down since you spend more time on performance issues … that cross site feed that worked fine for 50 sites is really dragging at 250. Also, try creating a dev environment for a network, not as easy as you think.
  3. Bugs Get More Dangerous. The cost of a mistake also grows. Now you have all your customers connected to one WordPress Multisite code base and database. But your growing customer base requires you to bring on some new developers. And guess what? One of them isn’t that great and commits some bad PHP to the code base. Now all of your customers are pissed, instead of just the one he/she was working on.

WordPress MU is appealing and sexy. It’s like magic. No more updating 100 installs manually, one and done, Woot! But it’s really just deferring costs until later. If you’re prepared for them, maybe it’s still worth the trade off, but in most cases it’s not. There are plenty of other services that will manage your code upgrades for you without having to use WordPress MU and that’s really the main benefit.

Other Reading

Obfuscate Your Code at Your Own Risk

Looks like ZippyKid no longer supports WishList Member. I think it raises a good point about obfuscating code. Hiding your code behind some sort of encryption like Base64 may prevent your code from being ripped off, but it also prevents it from being improved and supported. If WLM made it’s code transparent it could share the burden of support and innovation with other services and developers. ZippyKid/WP Engine/WPMU/ and on and on. But the obfuscation instead guarantees this vast community of resources can be of no benefit to WLM at all. I hope it’s worth it.