Should WordPress Add Core Support for Domain Mapping?

photo credit: opensourceway via photopin cc
photo credit: opensourceway via photopin cc
The largest and most heavily trafficked WordPress sites are powered by multisite. Ensuring a strong future for the multisite feature is paramount to the long term success of the networks built on this platform. However, core improvements are often slow to be added, as multisite is used in so many different ways and therefore cannot easily be nailed into simple solutions.

Last week on the Make WordPress Core blog Andrew Nacin outlined some long term objectives for core improvements to WordPress Multisite. Core support for domain mapping is one of them.

The Subdomain/Subdirectory Paradigm

Due to the fact that subdomains and subdirectories are very limited options for site urls within a multisite network, domain mapping is commonly used to add in the option of top-level domains.

In a relatively unusual configuration of multisite, it is possible to create multiple networks. However, there is no UI to support multiple network installations and truly global settings are not currently possible across the board.

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).

Nacin proposes that we focus on adding more robust support for domain mapping in order to reduce the demand for a user interface for managing multiple networks. Multiple networks are relatively uncommon and usually not necessary, but are often set up due to the developer’s perceived inadequacy of subdomain/subdirectories. Nacin believes that the path forward is to introduce proper domain mapping into core. This will require a complete reworking of ms-settings.php.

Big changes would be required in order to make domain mapping possible as part of the core. Nacin outlines two requirements:

  • Dissolving the existing subdomain versus subdirectory paradigm, or rather downsizing it to be part of open registration networks only
  • Dissolving cross-domain “remote” logins, which are often the source of messy redirect loops

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.

These are by no means easy changes to apply, especially considering how it would strongly impact the many massive WordPress networks out there, including Nacin identifies dealing with URL conflicts as one of the greatest challenges of moving forward with domain mapping for core. However, this also brings an opportunity to vastly improve the experience of the management of open vs. closed multisite networks.

Open vs Closed Networks

A pertinent by-product of this proposal includes a discussion of how core domain mapping might affect open and closed networks as well as the signup process and administration.

photo credit: opensourceway via photopin cc
photo credit: opensourceway via photopin cc

If a WordPress multisite network allows for open registration on demand, it’s considered an “open network”. A closed network is the other very common scenario where signup is disabled and sites on the network are manually added.

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.

Removing these burdens would make life much easier for every closed multisite network super admin. In any network that I’ve ever created along these lines, most of the work is overcoming multisite’s restrictions that are placed on the network due to the core catering to open registration networks.

Nacin proposes a single option to be set on install and controllable via network settings in order to differentiate between open vs. closed networks.

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.

Nacin isn’t outlining a specific approach or timeline here, just a few long term objectives for tailoring future development towards a better multisite experience. So far, the comments have been very interesting and I would encourage you to get in on the discussion as it will mostly likely continue for awhile before a concrete plan of action surfaces.

I’m curious to know how these changes will affect current domain mapping plugins. Would it render them all obsolete? Are closed vs open network distinctions too limited in defining how WordPress might manage signup and restrictions?


6 responses to “Should WordPress Add Core Support for Domain Mapping?”

  1. Does this imply that it would be possible within the UI (if Nacin’s plan went ahead) for us to choose on an individual site basis whether to use sub-folders or sub-domains? I actually do that already on my own site as it is possible via the existing domain mapping plugins, so it should take much extra effort to get it to work within the UI (I currently manually map the sub-domains to their corresponding sub-folders.

    This actually has a distinct cost benefit for those using https on their admin panels, as it means you can use a regular SSL certificate instead of requiring a wild card when using sub-domains. This is because you can use sub-folders on the backend, whilst using mapped sub-domains on the frontend.

  2. I think that almost any core-lead ‘setting of foundations’ is a good idea. The current set up is old, complex and confusing.

    Domain mapping is at bursting point, and will end up with either no solution in the public domain, or with lots of insufficient work-arounds that will confuse newcomers even more.

    It makes sense for the WordPress Network to support domain mapping out of the box. Who doesn’t have a network with sites that want their own URL?

  3. I’d like to see domain mapping incorporated into the core. Besides the fact that the current methods/plugins to do it are clunky, there’s little point in offering multisite unless you’re going to offer a basic/expected feature like domain mapping.

    No having domain mapping in the core makes multisite unappealing and easily overlooked for many who might otherwise use it.

  4. This needs to be in core as there a couple of ways to map using free & premium plug-in solutions and can be confusing.Make setting up a MS easier is progress and a thumbs up to Multisite development. I’m also concerned about how SEO & and even linking on MS is a bit of a hinderance to fast development. Often I have to develop on the subdomain/subdirectory url then switch to a url – then check like mad that no manual or links via plug-in content is still not pointing to subdomain url links. Ok this is done to some plugins not linking via the database (and then when the root url is mapped being intact.

    if it was core it would be part of the environment and plugins & themes would be developed with this in mind. It would be great if plugins like Back up Buddy would finally come off the fence and support MS Back Up – i think it would if it was core. Hope it comes soon (ish)


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: