Following up on the potential roadmap for terms and taxonomy meta, here is a potential roadmap for multisite. This is based on years of discussions among core developers and other contributors, which has taken place on IRC, tickets, blog posts, comment threads, at WordCamps and contributor days, and at last October’s community summit.

The Current State of Multisite

Historically, WordPress MU was the “multi-user” version of WordPress. Any user could register their own subdomain, exactly how WordPress.com worked. Most of multisite remains centered around open registration and signups.

The difficulties of setting up a wildcard DNS led to the introduction of a subdirectory option for new sites, as a fallback. Indeed, the old constant to toggle the subdirectory/subdomain option specifically referenced virtual hosts (VHOST, defined as ‘yes’ or ‘no’, rather than boolean). Wildcard DNS is still checked on setup whenever someone is creating a network with a subdomain.

In a subdomain setup, the valid domains are quite limited. Subdomains cannot be nested and can only be common characters, and top-level domains cannot use www or ports. When creating a new site in the network admin, it still asks for an email address, and a user with that email will be created if the user doesn’t already exist.

The paradigm of subdirectories versus subdomains is very restrictive. Over time, many have sought two related but distinct concepts that would diversify the address space used for sites.

Domain Mapping and Multiple Networks

Generally, domain mapping is the concept of having a top-level domain, such as example.org, being a site inside of another network, such as example.com. Otherwise, sites on example.com would simply be subdomains or subdirectories — so, blog.example.com and photos.example.com, or example.com/blog and example.com/photos. Either way, if the goal is for example.org to be a site on the same network, something must give.

By default, WordPress MU has only one network (MU terminology was ‘site’, with sites being ‘blogs’), and constants are put in place during network creation to even avoid querying the wp_site table. Multiple networks are possible, but typically, only one network is desired. The only things “global” to entire multisite installs (rather than just a single network) are must-use plugins (“mu-plugins”) and users. Sites are assigned to a particular network; network-activated plugins and network-enabled themes are distinct only to that network; and each network has its own settings, network admin, and even super administrators (unless defined globally using $super_admins).

There is no way to even store a globally accessible option accessible by all networks. switch_to_blog() (MU terminology for a site) does not actually toggle the current network ($current_site, per MU), and thus get_site_option() can only return current network information.

WordPress stores a decent amount of “global” information as meta against a single network, which duplicates efforts. This includes plugin, theme, and core update checks; and user counts. (Site counts are per network.) Multiple networks still rely on a single installation of WordPress and a single wp-content directory.

Domain mapping should be our primary focus here. It would probably be best if the demand for better support for multiple networks (like a user interface) is reduced through robust domain mapping support.

On API and Naming

At some point, we should be able to introduce a get_network_option() function to replace get_site_option(), which could follow context switches and accept a network argument. A network ID of “0” could be used in wp_sitemeta (network meta) to store truly global cross-network options.

A larger point on API is that we should not rename API for the sake of renaming API. A lot of functions still use “blog” when they mean sites, or “site” when they mean network, and many remain prefixed with “wpmu”.

We’ve tried really hard to move toward “network” wherever possible, at the API and UI levels. We long ago stopped introducing “site” things when they mean network as it is just too damn confusing. We haven’t quite made the switch to always going with site over blog at the API level, though we have at the UI level, but that’s just because it is more difficult for “site” to mean two different things, than it is to start using “network”. Either way you, still need to figure out whether a particular reference to “site” means “blog” or “network”, so we might as well use “network” wherever possible and lessen the number of ambiguous “site” instances (especially those that refer to the old MU definition).

Not renaming these functions is actually key to the evolution of multisite. There are quite a few functions to rename, but doing so without completely replacing their internals and functionality in the process is a huge missed opportunity — it wrongly suggests things have improved while also cutting into our valuable function namespace. Three plus years later, we’re still finding oddities in old MU code, so it makes sense to bide our time and only undergo renames when they let us shed dead weight. The side effect of keeping the barrier to entry high for multisite is not necessarily a bad one — even three years after merge, the product as a whole is still very weak (which is being kind).

The Path Forward: Supporting Sites at Any URL

It should be abundantly clear that creating a second network is often overkill and not necessarily desired for many setups. WordPress.org uses them, but it is a mixed bag. Each subdomain is its own network, which are subdirectory setups. It makes a lot of sense for make.wordpress.org to be its own self-contained network, as they share similar characteristics. But other subdomains are typically just a single site.

But, because of the subdomain/subdirectory paradigm, many use multiple networks to function as domain mapping. The best way to avoid misuse of multiple networks as domain mapping (which, aside from being counter-intuitive, isn’t generally desired) is to introduce proper domain mapping into core. This requires a complete rewrite of ms-settings.php — which takes a URL and figures out which site it should be on.

Essentially, it should take the entire subdomain and at most one path segment, and query the wp_blogs table to find the associated site. Something like domain = %s AND path IN ('/', '/first-segment/'). From there, the current site can be inferred.

The reason to search only one path segment is it immediately becomes an issue of caching. We don’t know how many levels are actually supported, which means we don’t know if /2013/02/01/some-blog-post/feed/ is a site, or a post on the main site. Literally any main site URL would thus cause a hit against the blogs table. This is not ideal. Nested sites are of course going to be desired in many situations, and it should be dead-simple for these URLs to be “trapped” via sunrise.php and mapped to a particular site.

If a network is “small” (less than 10,000 sites per our wp_is_large_network() API), we could potentially query and cache SELECT blog_id, path FROM $wpdb->blogs WHERE domain = %s AND path <> '/' into a single cache key for lookup. Or we could specifically break it down into caching a shortest path, like any paths that start with ‘a’ in one cache key, any paths that start with ‘b’ in another cache key, etc. That way, we can verify that a site exists or not as long as a cache is in place. (The alternative would be to cache individual successes, but then we do a lot of DB queries if we’re unsure whether something is just uncached or isn’t a site — we’d have to cache in the negative too.)

Domain mapping in core requires two major things. A complete dissolution of the existing subdomain versus subdirectory paradigm, and cross-domain “remote” logins. Remote login requires some juggling to make sure that domain B can make a request over domain A to confirm someone is logged in, and set a cookie if so. Generally this requires that logins occur on an “unmapped” domain (think the main site in a network, typically), but there are numerous ways to set up remote logins. Unfortunately most current implementations in the wild (including on WordPress.com) are fairly messy and can cause redirect loops, race conditions, and other problems. If done poorly, security issues can result. So this must be done with care.

Dissolving the subdirectory/subdomain paradigm is actually not so bad. We need to stop thinking about a network only consisting of differing subdomains, or only consisting of differing paths. ms-settings.php would need to be rewritten. Site creation and management will need some changes.

Dealing with URL Conflicts

Perhaps the greatest change will be addressing the issue of the main site gaining a ‘/blog’ prefix. This is ostensibly to avoid top-level pages on the main site from clashing with sub-sites. With arbitrary domain support (via domain mapping primarily, and secondarily via secondary networks), any site with path ‘/’ can clash with any other site with the same domain but a different path. With multiple path segments (nested sites), any site with path ‘/X/’ can have pages that clash with site ‘/X/Y/’.

Ultimately, this requires two-way blacklisting. Before a site is created, it must be checked against top-level URLs of the possibly conflicting site. And, before a page is created, it must be checked against sub-sites that already exist. If an ‘/about/’ page already exists on example.com/, an /about/ site cannot be created. But if an example.com/blog/ site already exists, a /blog/ page cannot be created on example.com. This gets complicated quickly, and is a very strong argument for only supporting one path segment in core by default, and allowing plugins to handle these potential conflicts on their own. In most cases, simply ignoring the potential conflicts is going to be sufficient.

Registration and Open Networks

Supporting any URL opens up possible problems with registration, even after dealing with unique URLs. The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well). In the case of a closed network, the blacklisting is merely to avoid shooting oneself in the foot. In the case of an open registration network, there does still need to be the choice of what, exactly, someone can register for. Even in a world of domain mapping, it should only be expected that “open registration” still only allows for subdomains or subdirectories, just as it does now. So when I am referring to removing that paradigm, I actually mean downsizing it to being a part of open registration only.

Trusting Users in a Closed Network

Despite being the narrower use case, the concept of open registration still implicitly dictates a lot of our current situation and “roadmap.” An administrator for a single site is considered wholly untrusted. Because multisite has the concept of a super administrator, there of course some powers that should be reserved for them. I would argue that would include the use of unfiltered HTML, as well as the administration of anything “global” — editing and deleting users; and editing, installing, and updating plugins and themes.

But, when a network is not designed for “open registration,” there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.

I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively. It will then be much easier to consolidate a lot of the signup, activation, and administration funkiness in multisite under this paradigm into an “open network” concept. The “Allow new registrations” setting is roughly analogous, but would largely be superseded by whether a network is open, as well as fine-grained registration controls.

One use case we should consider is the concept of a closed network and an open network sharing one multi-network multisite installation. For example, wordpress.org may be a closed network, but meetups.wordpress.org may be an open network to enable others to create meetups. And wordcamp.org may also be an “open” network on the same installation, even if individuals can’t create sites. “Open” is thus wider than registration alone.

Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.

A strong benefit here is that functionality in a closed network starts to more closely resemble a single site rather than the inherent restrictions of an open network. By shifting these paradigms, networks will become easier to manage and more straightforward to use over time. Eventually, closed networks can and should become easier to install — even if multisite never reaches the point where it is the recommended tool for creating a second blog for your cat.

Moving Forward

There is not a specific, multiple-release plan for this roadmap. Rather, every step we take should aim to work toward outlined goals. While people may like domain mapping, it doesn’t make sense to bolt it on just yet — a plugin can do that for them perfectly well now. It would be ill-advised to implement it without making WordPress work significantly smoother for other forms of domain and URL management — subdirectory/subdomain installs, domain mapping, and multiple networks. The best approach is one that smartly and carefully balances the needs of users with our long-term objectives.

Share this:

GREAT overview of the issues related to multisite; bookmarked for much future reference. Thanks for that even though I assume that wasn’t your intention.

One thing I would add to the list of improve, if it can be done backward-compatibly of course, is to reduce the number of places that duplicate domain/subdirectory information in the database. This currently makes moving a multisite from development -> test -> staging -> production more of a challenge that moving single site can be.

And yes scripts can be written to automate but it first requires understand what much be written, which is much most complex for Multisite and most people don’t write scripts if they think they are only going to move things infrequently.

This is a great write-up, and I agree with it almost completely minus this one point:

It would probably be best if the demand for better support for multiple networks (like a user interface) is reduced through robust domain mapping support.

I think the opposite — it would probably be best if the demand for domain mapping is reduced through robust multi-network support.

I think when a typical site administrator thinks they want domain mapping, what they actually want is a secondary network, with a new domain, new available themes, new network wide plugin control, with the same username and password. The only reason want domain mapping is because it’s the popular answer, not necessarily the correct one.

We can use WordPress.org, WordCamp.org, BuddyPress.org, and bbPress.org, as great examples, but I think schools with several campuses might be a better one. They’ll all want users with super-admin access to their respective networks, with separate plugins and themes (maybe even separate wp-content directories) but with the same global users.

Another great example could be a potential WordCamp.org redux. `sf.wordcamp.org` could be a network, `milwaukee.wordcamp.org` could be another, `newyork.wordcamp.org` a third, and the next level subdomains are all sites to their respective networks. Or… we could flip it the other direction and do networks numerically by year (2013.wordcamp.org) and use cities as subdirectories (2013.wordcamp.org/newyork) which allows us to retire complete networks at the end of each calendar year, allows for planning and rethinking the plugins and themes made available each year, etc…

Conceptually, the architecture of how sites are related to their networks comes down to however themes and plugins will best serve the sites they’re grouped with.

The only technical reason (I can think of) for literal “domain mapping” to be in core is shared SSL certs and allowing `/wp-admin` URL’s to always point to the unmapped URL. Any other reason(s) why a blog address would need to be mapped, rather than just being set to what it is (like we do now via Network Admin > Edit Site?) Either way, I think we’re in agreement that more useful UI for allowing capable users to set the homeurl/domain to be agnostic to the root domain (not married to any subdomain or subdirectory structure) is ideal, as the current process is less intuitive and more complicated than it needs to be.

I don’t expect this to be the popular vote, but I’d like for WordPress’s default installation configuration to look something like this:

Multisite always, with no additional installation steps like we currently have.

Add a column to the global `wp_blogs` table for domain-mapping (though this doesn’t allow multiple domains to be mapped down to 1, or vice-versa.)

Subdomain VS Subdirectory decision eliminated completely. (Can we run an automated check to see if wildcard subdomains are supported, and provide user feedback and/or disable the creation of sites with subdomains?)

Create a UI for network management, and for moving sites between networks when it’s needed. A global setting/switch would exist to optionally allow users to create new networks the same as they can currently optionally create new sites. Imagine if a prospective WordPress.com VIP could spool up their own network of 30 sites, choose what plugins and themes they want, and assign super-admin capabilities, completely without human intervention. (Devil’s advocate could say if this was a need it, VIP would have built it already; I think that no one knows they want this yet because it currently seems more complicated than it is.

The `/users` dashboard could then use a “Networks” page in addition to the existing “Sites” page, along with matching moderation tools for leaving/deleting/delegating responsibilities/etc…

Cons are:

Introducing several new default database tables that may not ever be used

Introducing curious users to multisite UI that may not ever actually need it

I think the opposite — it would probably be best if the demand for domain mapping is reduced through robust multi-network support.

I think when a typical site administrator thinks they want domain mapping, what they actually want is a secondary network, with a new domain, new available themes, new network wide plugin control, with the same username and password. The only reason want domain mapping is because it’s the popular answer, not necessarily the correct one.

I agree with most of the points you make, and obviously you have a lot of experience in the area. But, I think multiple networks are far beyond what most use cases dictate. I think there may be some confusion based on the phrasing I was using to describe some concepts.

Your comment made me realize I need to stop calling it “domain mapping.” This wording stems from the fact that a top-level domain is “mapped” to an existing subdomain or existing subdirectory. (This is at least how it works on WordPress.com and with the popular WPMU Domain Mapping plugin.) I dislike this strongly. I think the dissolution of the subdomain/subdirectory paradigm would mean WordPress core would specifically support arbitrary domains for multisite, versus having one URL for the frontend and a different URL for the backend.

Again, we’re talking about focusing far more on closed networks, which implies greater control over the domains in use. In an open network context, mapped domains would probably still be preferred that way logins and administration are occurring over a single domain with an SSL certificate. I think this should remain plugin material.

I didn’t suggest that multiple networks shouldn’t be implemented, only that it should not be a priority. I mean, single networks are still a mess. Also, multiple networks already work pretty well right now, to be honest. It’s everything else that needs a complete rethink and rewrite, which also strikes much more at the very foundation of multisite.

Ultimately, I want to move away from the thinking that domain mapping is a hack of the subdomain/subdirectory paradigm and that the only way you get arbitrary domains is with multiple networks. We should have true arbitrary domains within a single network, and we should to it well. Then at some point better multiple network support would allow for people to logically group any sites they wanted based on whatever their needs were, based on the needs of shared plugins, super admins, settings, site registration, etc.

As long as multisite remains based on the open network paradigm, we’re stuck in a land of esoteric restrictions and gotchas. Combined with the general mess that is the multisite codebase (and in some cases UI), this is why the installation process remains deliberately complex. I did write in the post that closed network functionality starts to more closely resemble what people are used to with single sites, which I think is getting to the root of your “multisite always” suggestion.

Your comment made me realize I need to stop calling it “domain mapping.” This wording stems from the fact that a top-level domain is “mapped” to an existing subdomain or existing subdirectory. (This is at least how it works on WordPress.com and with the popular WPMU Domain Mapping plugin.) I dislike this strongly. I think the dissolution of the subdomain/subdirectory paradigm would mean WordPress core would specifically support arbitrary domains for multisite, versus having one URL for the frontend and a different URL for the backend.

Completely agree with you here, and like that we can start calling it something else asap.

I didn’t suggest that multiple networks shouldn’t be implemented, only that it should not be a priority. I mean, single networks are still a mess. Also, multiple networks already work pretty well right now, to be honest. It’s everything else that needs a complete rethink and rewrite, which also strikes much more at the very foundation of multisite.

I think what I’m suggesting (and likely failed to communicate effectively) is we should get single-network handling sorted before we try to implement arbitrary multisite domains. I have a hunch it will need to happen in that order anyhow.

Again, we’re talking about focusing far more on closed networks, which implies greater control over the domains in use. In an open network context, mapped domains would probably still be preferred that way logins and administration are occurring over a single domain with an SSL certificate. I think this should remain plugin material.

Agree that closed networks are more common, and agree that true domain mapping is a much more likely scenario in open (WordPress.com style) networks. I could see it being rolled into core’s open-network handling and enabled via a plugin (similar to how multi-network is now.) It would play nicely with our current sub-team arrangement, enabling a team to concentrate on a canonical domain mapping plugin for possible core inclusion later.

What’s the benefit of multiple networks over multiple installations that share a user table? And even sharing the same plugin and theme directories? Once we add support for arbitrary domains within a single network of sites, multiple networks essentially just makes certain things a little easier to administrate and manage.

I’m not saying there shouldn’t be or isn’t already a benefit, nor am I trying to play (much of a) devil’s advocate. I honestly want to know what the answer is, because that could help shape how we build out multiple network management in the future. There needs to be some kind of value-add, and I’m not sure we’ve discovered one that suggests we need much beyond what we already have.

What’s the benefit of multiple networks over multiple installations that share a user table? And even sharing the same plugin and theme directories?

The obvious benefits are:

One copy of WordPress in the file system VS one for each “network.”

One `wp-content` folder to run one monolithic network of sites>

That said, this may not be desirable. Similar to WordPress.org, there’s something nice about knowing if BuddyPress.org botches something, it doesn’t necessarily bleed into WordPress.org (even if system resources are shared, code is not.)

Once we add support for arbitrary domains within a single network of sites, multiple networks essentially just makes certain things a little easier to administrate and manage.

Correct. BuddyPress.org and bbPress.org are good examples for this. They run almost identical sets of plugins and themes, and they both should be multisite networks that have their own uniquely activated network wide plugins and themes.

bbPress.org could be completely under the BuddyPress.org network, but I’d like different sets of Super Admins on both networks. There’s an argument to say that if we trust someone in one place, we can trust them in another, and I do agree with that. In this case it’s less about trust and all about ownership and responsibility; limiting access is a good way to distribute that, without talking about implementing network level roles and capabilities (even though I think long-term they will also be necessary.)

Wow. That was … a really long write up. Finally understand the users who want a network of networks. Anyway, what I really would like to see is that we finally drop single site. I think we could just bring in a slightly reduced UI but still run a multisite install per default. Just my 2cents.

I agree. Perhaps an intermediate step would be the installer recognizing that wp-config.php and .htaccess have already been written for network mode, and creating tables accordingly. Right now, if wp-config.php and .htaccess are configured when wp-admin/install.php runs, values are pre-filled and the install works properly. If they are written for network mode, the installer fails.

Short – Great!
Currently is it hard to create plugins for single and multisite mode; much easier with a settings API in single and multisite mode. Also the parts to network in network is fine, use often for customer. Also a important part is the UI and the documentation on wordpress.org, maybe good topics for Contributor Days on WCs