WordPress multisite: the worst feature of wordpress

Wordpress multisite
WordPress logo. Credit: wordpress.org

Lately I’ve started a major overhaul of all of my sites, re-making them based on new and modern technology. First out is gsmblog.net, which I intended to base on WordPress multisite. A longer post about this process will be available soon, bust first I want to talk a little bit about WordPress, and it’s multisite feature.

The reason I chose Wordpress is fairly simple. Previously I’ve based a lot of sites on Drupal, even though I really hate PHP. Unfortunately, PHP seems to be the de facto standard for small calibre CMSs. Personally I really would like to see a very good small calibre CMS in Java. Not because Java is great, but I work with Java every day, and the universe of APIs and libraries is immense compared to most other modern languages. In a perfect world the leading small calibre CMSs would be written in python or some other nice language. Lots of great alternatives exist, both written in Python, Java, and other languages, but the ecosystem surrounding them are generally to small, and in the case of Java, they generally are quite dated and still look something like the original CMSs from way back when.

“Why not Liferay?”, you might ask? Liferay 6.2 is a huge improvement. Liferay gave 6.2 a huge makeover, bringing Liferay into the sphere of the modern web. 6.2 is a great product, and I love working with it. As part of my major overhaul some of the more complex sites are going to move to Liferay 6.2. But let’s face it, Liferay is a portal with basic CMS functionality, it’s not a full breed CMS, and it’s definitely not small calibre. Creating sites like this blog in Liferay is a complete overkill.

WordPress is great, multisite not so much

I moved to wordpress since I simply no longer have the time to stay up to date with regards to Drupal, and I want to use a small calibre CMS that’s fairly simple to use on some of my own sites. I need the knowledge for when asked to help roll out simple sites by friends and family. WordPress itself is great. I really wish it was written in something other than PHP. It’s simple and intuitive to use, and the plug in universe is immense (though that naturally results in a lot of crap plug ins as well). WordPress multisite however is simply not up to par.

I really loved the multisite feature in Drupal 6. It was easy and intuitive to use. It allowed me to have a single code base to maintain. I could very easily maintain a set of plug ins and themes common for all sites, and at the same time maintain individual plug ins and themes for single site when necessary. I could even override the shared themes and plug ins on individual sites when needed. All in a simple, intuitive fashion. And it just worked. It didn’t introduce bugs, it didn’t slow down my sites, and it didn’t require me to do things differently than when running a single site. WordPress multisite on the other hand, gives me none of this.

Why WordPress multisite is bad

I spent lot’s of time trying to use the multiste feature in WordPress, time wasted that should have been spent on something more sensible. Had I known then what I know now, I wouldn’t have bothered. I would have just used single installs with all of the disadvantages that entails from the very start.

Of all of the advantages I mentioned in regards to Drupal, multisite only gave me one: a shared code base. Sure, most of the other things were possible. But they were not easy, and certainly not intuitive and trivial to use the way they are in Drupal. But it’s worse, a lot worse. Why would I have to activate multisite specifically? In Drupal it’s just there, and you use it if you want to. And why would I have to read and follow a long tutorial to use the feature? In Drupal, I just followed a few easy steps, documented right there in the readme.txt. I didn’t have to follow a long boring tutorial, and I certainly didn’t experience the whole system exploding, potentially in a non revertible way by getting a single small step wrong.

So it’s hard to set up, but once you get it running it just works, right? Wrong. Once you get it running, you are in for a huge headache. The feature introduces bugs galore. Things that previously worked, don’t. Plug ins break, and break bad. Some plug ins go from being plug and play to quirky and fiddly. Random Ajax calls and POSTs in the control panel simply stop working. That one is really strange, and I never actually managed to figure out what was going on there.

And in what universe did it make sense to make sub folders the de facto standard for multisite, and allow sub domains as the other option? If you want to use multiple, actual, domains, like any sensible human being probably would then you’re really in for a treat: You have to install a really quirky plug in that tries it’s best to get you so frustrated that you through your machine out the window and give up using it. Yet again you have to follow long tutorials, and the method used is simply insane. Set up multisite using sub domains. Create all your sub domains so they work. Add domains mapping to the sub domains and the system will redirect from one to the other when needed. Oh, and you get to choose between having a common log on system for all sites and remote access, or log on on each individual site and no remote access.

The feeling I got was basically of a really bad hack, on top of a bad hack, on top of a hack. It’s frustrating, and to be perfectly honest, whomever designed this should be really ashamed. WordPress multisite is a case study in how not to create software.

You would think that that was it. But it’s not. WordPress multisite is slow. Extremely slow. Granted, running anything on PHP requires having a well configured web cache such as Varnish, or a good caching reverse proxy in front of it to be at all usable. This mitigates some of the performance issues multisite introduces. But the performance issues are going to hit you in the head as soon as you log on to the site, since you can’t introduces caching to the control panel or the authoring interface. (Though probably you should still be caching CSS, Javascript and images).

Who should use WordPress multisite?

The answer is probably nobody. I wrote this out of frustration, because I really wish somebody had written this before me, so I could have avoided all of the wasted time, grey hairs and frustration trying to get multisite working. So if you are reading this, and wondering if you should use multisite, I highly recommend you don’t. If you, like me, want to the great multisite features known from Drupal, you are out of luck. You are better off simply using multiple installs, and if you want to get advanced write some scripts and perhaps include some git magic to maintain your sites, or use something like Saltstack. The latter is on my todo-list, but knowing how my todo-list works, that is probably something saved for a rainy day. In 2025.

If you need to, as a service provider, need to provide your users with wordpress on a large scale, you might want to investigate multisite. But let me tell you, you are way better of investigating some of the commercial alternatives out there. Most likely you will end up wanting to roll out your on proprietary system, because basing anything commercial on WordPress multisite is a very bad idea.

3

Responses

  1. Arne

    Have you considered Ghost (https://ghost.org/)?

    It’s a simple blogging-platform written in JavaScript (run by Node), and there seems possible to handle multiple blogs from one codebase (https://www.digitalocean.com/community/articles/how-to-serve-multiple-ghost-blogs-on-one-vps-using-nginx-server-blocks).

    Reply
    • Brendan Johan Lee

      Interesting. Now I have yet a new technology to add to my for ever growing todo-list 😉

      Reply
  2. Mitch

    Agree COMPLETELY. After working on a few multi-site installs built by others, I refuse to believe this system solves anything close to the number of problems it creates. If someone is telling you “multi-site is the way to go” chances are they have never used it.

    Reply

Leave a Reply