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 WordPress.com. 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.
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?
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.