Why WordPress Multisite?

WordPress Multisite is widely used to power some of the largest WordPress sites on the internet. From being the backbone for WordPress.com to serving as the foundation for many academic institutions, large enterprises and financial organizations, WordPress Multisite adds a lot of power and flexibility to what you can do with this CMS.

However, WordPress Multisite is not always the “best tool for the job” for every situation, and Pantheon offers a very similar feature – Custom Upstreams – that solve some of the types of problems that you might be inclined to use WordPress Multisite for. 

So, when is a good time to use WordPress Multisite, and when is a good time to use a Custom Upstream instead? That’s what I’m here to explore with you today!

What is WordPress Multisite?

Since WordPress 3.0 was released in June 2010, WordPress has had the ability to host many disparate sites on a single WordPress installation. Prior to that, WordPress MU (or “multi-user”) was a parallel project that forked WordPress core to add features that supported hosting multiple sites inside a single WordPress instance. That’s where the concept of “mu-plugins” comes from. Originally, they were plugins specific to WordPress MU, but now the backronym “must-use” is applied. 

This history is also where some of the idiosyncratic language issues come into play. Previously, in WordPressMU, sites were referred to as “blogs,” so the word “blog” is often used interchangeably with what’s currently known as a “site,” while a “site” might refer to the WordPress installation as a whole or a single site within a Multisite… It’s very confusing.

At the time, Multisite was quietly listed as one of several headline features that also included the first in a series of annual themes, Twenty Ten, (marking the first new default theme since Kubrick) and a new menu editor. You would be forgiven for not understanding the significance of the note: “WordPress and WordPress MU have merged – allowing the management of multiple sites (called Multisite) from one WordPress installation,” especially if you didn’t already know what WordPress MU was or why you might want it. And yet, we’ve been able to create complex networks of sites on a single WordPress installation for over 10 years – longer if you include the year or so of development that originally went into WordPress MU. Remember that when WordPress MU was merged into core, it was a fully developed feature set that had already been tested on large WordPress Multisites.

At its core, WordPress Multisite allows you to manage a bunch of different sites within a single install. Okay, I’ve said that a bunch of times, but what does it mean? It means if I have a site – let’s say dragonuniversity.com – for an academy I run to train adventurers, I might have different departments that focus on different fields of study. I might have the College of Bards, the Department of Arcane Wizardry, and an independent cooperative focusing on Ranger skills and outdoor survivalism. Each department might have its own section of the website. Because each department has its own staff who run the program, it might want independence in how to manage its own content. The alternative might include having to have access granted to specific pages (but not other pages) or other complex rules and editorial workflows if the site was managed as a single, huge WordPress site. I’ve built systems designed to restrict some users to certain types of content – or content belonging to a particular department or category – within a single site and I can tell you from experience, it’s not easy.

For this situation, dragonuniversity.com might benefit from a WordPress Multisite. The College of Bards could have its own subdomain – bards.dragonuniversity.com, and the same with the Department of Arcane Wizardry – wizards.dragonuniversity.com. Because it’s all a single Multisite, the same WordPress theme could be used on all of those sites, and each site would benefit from the same collection of plugins, which are installed into WordPress.

Isn’t That Just Custom Upstreams?

You’re not wrong. Everything I’ve described so far you could do on Pantheon with Custom Upstreams. Each site can be separate yet distinct, managed by its own internal staff or content team, and benefit from a similar template of WordPress plugins and themes. Why, then, would you want to use WordPress Multisite?

I’m glad you asked.

What is WordPress, really?

Before I answer the question of WordPress Multisite, it’s worthwhile to take a step back and look at WordPress as a whole. What is ​​WordPress really? A Content Management System, to be sure, but what does that mean? What makes a CMS special?

Many years ago, there was a project called BackPress. BackPress was the foundation for a few other WordPress-adjacent projects like bbPress (a forum), BuddyPress (a social network) and GlotPress (a translation service). All three of these have ultimately become WordPress plugins (though not without some kicking and screaming along the way), but the reason why they weren’t plugins to begin with is because a WordPress site was synonymous with a blog. Very few people would have any particular reason to also host a forum, a social networking site or a translation site on their blog.

I mention this because the point of BackPress was that it took what was essentially the guts of WordPress out of WordPress so they could be used to create other types of sites. WordPress has a lot more to it than simply content management. For one thing, it has built-in user management – a system of roles and capabilities. There is an authentication process that allows logged-in users to have a different experience from logged-out users. There’s user meta that allows data to be attached to users. There’s a system of taxonomies – terms by which content (but also other types of data objects) can be grouped and organized. It has an integrated search that allows data to be looked up based on keywords, matching content or meta. There’s logging, an options API, libraries that handle HTTP requests and a lot more. All of this is extensible through hooks sprinkled throughout the codebase that allow developers to interact with specific pieces of functionality and manipulate the default behavior such that WordPress can really power any type of site you can imagine.

WordPress is more than just a collection of plugins and themes assembled together to support the content. WordPress is an entire software framework that can really be used to do a lot more than what WordPress was originally developed for. BackPress, and the projects that it powered, made use of WordPress internals – things like how users and content were stored, as well as time-tested and hardened APIs – while redefining the focus of what a WordPress-powered site could be. Their transition into WordPress plugins just proves that WordPress itself can be used as the backbone of any kind of site you can conceive of.

So, Why Multisite?

Let’s get back to the question at hand – when would I use WordPress Multisite instead of a Custom Upstream on Pantheon, and when would a Custom Upstream actually make more sense than a WordPress Multisite?

To me, it comes down to two things: user management and a shared database. In particular, when these two things are a feature, not a bug.

Because WordPress Multisite is contained within a single ​​WordPress installation, there are a number of advantages that go along with that. The shared codebase is among them, for sure, but that’s not the most important one. If all you are doing is hosting a bunch of disparate sites in a single WordPress install, with different groups of users and admins – sure, you can do that, but I’d argue that that’s not the most efficient way of using a WordPress Multisite. Additionally, there are potential performance and maintenance implications that go along with hosting a WordPress Multisite that would be adding overhead without any real benefit for you. Those sites are probably better off as single sites.

On the other hand, imagine you have a collection of sites that would benefit from a shared user list or shared content. In other words, you have someone who logs into a single site on the network and could potentially use the same login information on any site on the network. Or, you have a complex site that uses information pulled from one site on the network and shares it with another site on the network. In these two instances, a WordPress Multisite might be the right choice.

Let’s say you wanted to try running dragonuniversity.com on Pantheon using a Custom Upstream. If you wanted users to be able to log into any dragonuniveristy.com site, you would probably need to integrate a third-party Single Sign-On (SSO) or build the functionality yourself. These pieces of technology are typically not simple and every outside integration introduces another potential point of failure in your infrastructure. If you wanted to pull content into some of the department sites, for example, important dates or deadlines, you would likely need to build out some REST API endpoints and clients on the department sites to consume that API data. Or maybe you just dump a Google Calendar embed onto a page and call it a day. In one case, you would need to spend time writing code to integrate an API that is served by the main site; in the other, you spend less time coding, but the user experience and interface probably leave much to be desired.

Another bonus of WordPress Multisite is only needing to update one site. If dragonuniversity.com has thirteen distinct departments, using single sites for each with a Custom Upstream means updating all 13 of those sites to the latest version of WordPress (or your custom upstream) individually, plus the main site. WordPress Multisite can handle this all in one go since only a single WordPress installation needs to be updated.

So, Why Not Multisite?

WordPress Multisite is great, but it’s not the best solution for every situation. In many cases, it’s the things that make Multisite powerful that also add to its challenges. Other times, misunderstanding what Multisite was really designed for can lead to overcomplicating your project when really a different solution would have been better.

Each site on a WordPress Multisite is a distinctly independent WordPress site. If you go to WordPress.com today, you have the option to sign up and create a brand-new WordPress site. Access to that site doesn’t grant you access to any other site on ​​WordPress.com, but WordPress.com does have parts of the site where content is aggregated from other sites, like a page that pulls in the latest posts from all the sites you follow on the network. If you have access to multiple WordPress.com sites, logging into WordPress.com makes it relatively easy to switch between any of those sites that you have a login to.

WordPress Multisite is the thing that powers WordPress.com, so you basically have a live demo of WordPress Multisite in WordPress.com if you’re curious. It’s a single WordPress install, with thousands of user accounts and individual sites. I might have administrator access for a handful of sites, subscriber-level access to dozens more, editor-level access to a few, but only the administrators of WordPress.com have super-admin rights on the network itself. As an individual user of the network, I can’t install plugins or themes – I can only use the plugins and themes that are pre-installed for me by the super admins of the whole network.

This is by design. Because the scale of WordPress.com is potentially so large, as a user, I shouldn’t be able to upload my own code. Any code that an individual user might upload could impact the entire network. As such, the network is set up with a collection of plugins and themes that would meet the needs of most users. If you wanted something more bespoke, or more control over what themes and plugins are available, those are specific features of WordPress.com that you would need to pay extra for. What that means from the administrative side, is that a new site would be spun up specifically for your needs, so it doesn’t impact the network. 

Pulling content from one site on a Multisite into another site in WordPress Multisite isn’t particularly easy, either. In order to do so, you need to use a function called “switch_to_blog.” It allows you to functionally switch to a different site on the network in which you could run your query. When you’re done, you run a “restore_current_blog” to set the site back to where you came from. Using switch_to_blog a lot can be very resource intensive. Multisite was built with the assumption that you could be hosting hundreds or even thousands of sites in a single install; you don’t want  to “switch” to one of those sites to pull content out of it if you don’t have to. When you do, you need to consider things like Redis object caching to ensure that those expensive requests are stored in system memory.

When thinking about Multisite administration, it’s useful to think about it in the terms of a site as large as WordPress.com, with thousands of potential users and sites. Anything you do to the network itself might impact any site on the network, and Multisite accounts for this. It doesn’t make sense, then, to install a plugin if it’s only going to be used on a single site. It doesn’t make sense to use Multisite if you just want a special, one-pager to advertise a particular product or service. It does make sense that the users of one site on the network do not necessarily have access to another site on the network, but that those users could be shared if desired. It makes sense that it’s possible to pull content from one site to another, but this process should be handled with care. It doesn’t make sense to use a site on a Multisite to just produce a certain type of content unless you really want to have a single site that’s just dedicated to that content (a better solution would be to use a custom post type instead).

Developer, speaker and former WordPress.org plugin review team lead, Mika Epstein, has a great – still relevant – talk about when you might not want to use WordPress Multisite from WordCamp San Francisco 2013.

Conclusion

I’m a big fan of WordPress Multisite. I’ve used it personally and professionally since pretty much its inception. Multisite certainly adds complexity to a WordPress installation, but it also reduces complexity and maintenance if used in the right circumstances. The best rules of thumb for choosing WordPress Multisite to power your site are for instances where having a network of interconnected sites is explicitly what you are looking for, and in which a shared database of users is desired or beneficial, rather than something you would need to work around or avoid. Those sites and site owners should have independence over their content, but cannot make changes at the site level that would affect the whole network.

Like any powerful tool in your toolbox, it’s important to consider whether it is, in fact, the best tool for the job, especially when Pantheon has another tool that can solve some of the same problems. Many of the things that make WordPress Multisite powerful are the same things that may make it limiting, difficult to work with, or frustrating, so it’s important to fully evaluate the needs of the project and the ideal architecture. The best times to use a Custom Upstream instead of a Multisite are when you want each site to be completely self-governing, with no crossover of users (or an acceptable amount of duplication), and when you want to ensure that a single, high-traffic site does not negatively impact other sites in your network.

I’m never going to say that you shouldn’t use Multisite if that’s what you want to do, and I’ve personally published a course that discusses how to use Multisite because I like it so much. The decision is not one to take lightly, but I’m always happy to discuss the pros and cons of each online!