This roadmap contains plans for the multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site focus in the near future.
In addition to the common terms “users” and “roles”, the terms “sites”, “networks” and “global” are used in this roadmap. Here is what each of them means:
- Sites: A multisite setup has one or more sites that are connected to each other by being part of one setup and allowing several easy interactions and a common user base across. You manage a site through the regular site administration panel, with access to the respective areas determined by the role you have as a user.
- Networks: When setting up a multisite, you are essentially setting up a network (versus site, blog). A network consists of one or more sites that belong together, one of which is its “main site”. You manage a network through the network administration panel, however only if you are set as a network administrator (also called “Super Admin (and super admin)”).
- Global: While it’s only possible to have one network given the UI User interface that WordPress exposes, it also supports having multiple networks so that sites can be grouped together under distinct networks. When this is the case, a higher level in the hierarchy is required, for example to manage networks. This concept is rather abstract outside of multi-network, but global context means just that.
While this roadmap clearly states the main multisite objectives for the next several releases, it is by no means exclusive. Bugs and small enhancements can be addressed as needed. Larger efforts and features should be discussed during weekly office hours and may be added to the roadmap. All tickets which are part of the roadmap can easily be looked up by using the keyword ms-roadmap.
REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. Support
Users
The REST API has a wp/v2/users endpoint for managing users, however its implementation for multisite is incomplete. The users endpoint should be improved so that everything currently supported in the admin UI can be accomplished through the REST API.
Applications consuming the REST API should expect the same response from single site and multisite for objects that exist in both configurations.
A finished endpoint should provide the following:
GET wp/v2/users – List users of the current siteGET wp/v2/users?global=true – List all global usersGET wp/v2/users/<id> – List a single user of the current siteGET wp/v2/users/<id>?global=true – List a single global userPOST wp/v2/users – Create a global user and add them to the current sitePOST wp/v2/users?global=true – Create a global user, do not add to a sitePOST wp/v2/users?existing=true – Add an existing user to the current sitePOST/PUT/PATCH wp/v2/users/<id> – Update site user data on current sitePOST/PUT/PATCH wp/v2/users/<id>?global=true – Update global user dataDELETE wp/v2/users/<id> – Remove a single user from current siteDELETE wp/v2/users/<id>?global=true – Delete a global user
In the examples above, a new global parameter is introduced. When called without a global parameter, only user data associated with the current site (the site through which the REST API is accessed) can be changed. REST requests for users that are not associated with the current site should receive a 404 response if global=true is not included in the request. Only network administrators will have access to using the global parameter initially.
Related ticket Created for both bug reports and feature development on the bug tracker.: #39544
Sites
A new sites endpoint should exist primarily to manage site data in the wp_blogs table. It should manage this data in a global context, while the site’s settings should be managed through its own wp/v2/settings endpoint.
A finished endpoint should provide the following:
GET wp/v2/sites – List all sitesGET wp/v2/sites/<id> – List a single sitePOST wp/v2/sites – Create a sitePOST/PUT/PATCH wp/v2/sites/<id> – Update a siteDELETE wp/v2/sites/<id> – Delete a site
As there is no current method to discover all public sites on a network, any listing of all sites should require the manage_sites capability by default, with a new filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. provided which allows changing that behavior.
It should however be possible to generate a list of a user’s sites separately from a listing based on the manage_sites capability. This will require get_blogs_of_user() or something similar and may need an additional parameter like ?user_id=<id> to identify context.
Related ticket: #40365
Networks
While managing networks has never been part of core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s UI, there should be a basic networks endpoint to manage network data in the wp_site table. Since there are several plugins and custom solutions around for managing networks, this endpoint must not be opinionated. It should be a simple interface to the database table, to provide a common foundation for plugins implementing multi-network.
A finished endpoint should provide the following:
GET wp/v2/networks – List all networksGET wp/v2/networks/<id> – List a single networkPOST wp/v2/networks – Create a networkPOST/PUT/PATCH wp/v2/networks/<id> – Update a networkDELETE wp/v2/networks/<id> – Delete a network
Related ticket: #41459
Internal APIs
Sites
The internal sites API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. should be revamped to support the wp/v2/sites endpoint work and other site-related development. Better equivalents should be introduced for the inconsistent functions that create, update, and delete site datain the wp_blogs table:
insert_blog() should be replaced with wp_insert_site()update_blog_details() should be replaced with wp_update_site()- a new
wp_delete_site() should be responsible for deleting a wp_blogs row
This completes a full CRUD Create, read, update and delete, the four basic functions of storing data. (More on Wikipedia.) API, together with the existing get_site() and get_sites().
Related ticket: #40364
In addition to a basic CRUD API, a new get_site_by() function should be introduced as an improved version of get_blog_details().
Related tickets: #40180, #40228
The installation and uninstallation of a site’s database tables, including initial data, should happen in dedicated functions as well:
install_blog() should be replaced with wp_install_site() which will call wp_install_defaults() to handle the entire site installation process- A new
wp_uninstall_site() should handle dropping the site database tables, removing media etc., all of which is currently part of wpmu_delete_blog()
Related ticket: #41333
wp_insert_site(), wp_update_site() and wp_delete_site() will all include a hook of the same name. The wp_install_site() function will be hooked into wp_insert_site by default, and wp_uninstall_site() will be hooked into wp_delete_site.
Note that the future of the old functions will be discussed at a later point. It will need to be determined individually whether they should remain as is, wrap new functionality and/or be deprecated. The only thing that is for sure is that they need to remain backward-compatible, as always.
Site Metadata
In addition to the wp_blogs table, there is a regular need for site-related data that should be part of the global context. For example, to extend the new wp/v2/sites endpoint, list the additional data in a performant way or query by it. Therefore a new database table wp_blogmeta should be introduced (that name is required for legacy reasons), alongside with the common metadata CRUD functions:
get_site_meta()add_site_meta()update_site_meta()delete_site_meta()
This meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. query functionality should also be added to WP_Site_Query.
The addition of the new database table must be carefully prepared, since core has never before introduced a new global table.
Related tickets: #37923, #40229
Networks
Similar to the planned wp/v2/networks endpoint, a basic unopinionated CRUD API for managing networks in the wp_site table should be available. It should follow a similar approach to the CRUD API for sites, with the following new functions:
wp_insert_network() for adding a new table rowwp_update_network() for updating the table rowwp_delete_network() for deleting the table row
This completes a full CRUD API, together with the existing get_network() and get_networks().
Related ticket: #29411
Network Metadata
Network settings are currently stored in a wp_sitemeta table, which is actually a table for metadata. While there is a dedicated API for network options, the metadata API is more performant and generally more regularly improved as it affects so many areas of WordPress. Therefore the *_network_option() functions should be changed to use the metadata API internally.
Related ticket: #37181
File Organization
Two new files wp-includes/ms-site.php and wp-includes/ms-network.php will be added, and all functions related to the current version of the site and network CRUD APIs, including metadata functions, will be moved to these files respectively. This will provide a better overview and make it apparent where a certain multisite function is located.
The second change in the file organization is that the metadata API files wp-includes/meta.php, wp-includes/class-wp-meta-query.php and wp-includes/class-wp-metadata-lazyloader.php will be loaded earlier in the bootstrapping process. This is necessary in order for the site and network meta APIs to work when accessed early, for example in a custom sunrise.php script.
Related tickets: #40647, #40948
Administration
Users
There are significant improvements to be made in how users are managed on networks and sites. User administration in the dashboard should be updated to use REST API endpoints once they are feature complete.
This portion of the roadmap should be developed to include design and user testing once endpoints are ready.
Sites
Site administration in the dashboard should be updated to use REST API endpoints once they are feature complete.
This portion of the roadmap should be developed to include design and user testing once endpoints are ready.
Networks
Multisite provides a data structure for networks that is open to interpretation. Because of this, networks can be (and are) managed in widely different ways. Rather than make decisions on how networks should be managed, WordPress should embrace the current state and leave the management of networks to plugins and other custom code.
As mentioned before, WordPress core should provide methods for managing the data in the wp_site and wp_sitemeta tables so that code built on top of WordPress has a reliable and testable base.
Efforts for a “default” multi-network UI however should be focused on the WP Multi Network plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, which has closely followed developments of multisite over the years and is the de facto standard for administrators looking to start with multiple networks.
Bootstrapping and testing Multisite
The stability and testability of the multisite bootstrap process should continue to improve.
Core unit tests currently run with SUBDOMAIN_INSTALL set to false by default. Full support for subdomains should be reflected in testing and CI configurations.
Related tickets: #42093, #40646.
Global Context Improvements
While global context enhancements have a lower priority than other tasks on the roadmap, it is important to think about related requirements and keep them in mind for future changes.
While core will likely never include a dedicated user interface for global data similarly like it will not include a UI for managing multiple networks, a storage for globally stored values would be a valuable enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. Currently, only users are truly stored globally, but there are other pieces of data that would benefit from a global storage, such as the network settings user_count, global_terms_enabled and ms_files_rewriting or the transients for available core, plugin and theme updates. All of these are currently stored on the network level although they are supposed to have the same value everywhere. Current ideas to fix that revolve around either having a new table such as global_options, or alternatively use the network options table sitemeta with an ID of 0 to address global scope.
Another issue related to the mixture between global and network scope is that users are global, but are currently exposed on the network level through the UI. This is once again fine in an environment that consists of only a single network, but in a multi-network there is currently no way to determine users of a particular network as there is no association between a user and their network. Fixing this would either involve a complex data migration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. path or it could alternatively be something that would only be enabled for new setups (which would then be something else that could be stored as a global setting).
Last but not least, there are also no global roles. Currently a “super admin” is a user that usually interpreted as a network administrator, but there is no level above that. Furthermore there is complexity in terminology in that term as it is often unclear whether the super admin user should have all capabilities or whether they should only have all capabilities in their specific network. For example, super admins are stored in a network setting, but they can be overridden by a global variable that would essentially make them global administrators. As super admins are only stored in a setting, a dedicated network level role system inspired by the existing site level role system could be the right direction to resolve this problem in the future, requiring a migration of existing super admins to a “Network Administrator” role. A simpler, but potentially not as efficient alternative could be a global setting similar to the super admins network setting.