Here’s an overview of the developer facing changes made in 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 for the 4.9 cycle. If you’re interested in more detail, checkout the full list of tickets.
clean_blog_cache() replaces refresh_blog_details()
refresh_blog_details(), which accepts a site ID, has been a wrapper of the
clean_blog_cache() function, which requires a site object.
In WordPress 4.9,
clean_blog_cache() has been adjusted to also accept a site ID and to invalidate caches for a deleted site in the same way. From now on
clean_blog_cache() should be used instead of
refresh_blog_details() which will be deprecated in a future release.
More importantly, the
refresh_blog_details action has been deprecated in favor of the
clean_site_cache action. See #40201.
New function get_main_site_id()
WP_Network class has historically contained a
$blog_id property indicating the ID of the main site of that network (versus site, blog). However, since this property was never part of the
wp_site database table, it is set manually in the multisite bootstrapping process. This results in it only being set for the current network. For any other network, code like
get_network( $id )->blog_id would return 0.
get_main_site_id() function introduced in 4.9 provides the site ID of any network in an easy way. The function accepts an optional
$network_id parameter, which defaults to the current network. Furthermore the magic property logic in
WP_Network has been adjusted so that the
$blog_id property (and its magic
$site_id equivalent) is automatically set when requested. This ensures
get_network( $id )->blog_id will always return a meaningful value. See #29684.
Refactored user capability and role switching
Switching the available roles and the current user’s capabilities no longer happens in
restore_current_blog(). Instead it has been moved to a new function,
wp_switch_roles_and_user(), which is hooked into the site switching process. This provides a performance improvement by temporarily unhooking the function in cases where roles and capabilities do not need to be switched.
In addition, the available user roles are now correctly switched when switching sites, with refactored behavior in the
WP_Roles classes making this possible. These changes are more closely explained in the 4.9 post about role and capability improvements. For related tickets, see #36961 and #38645.
Site administrators can edit user roles through the 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/.
While site administrators cannot edit user details in multisite, they are able to modify a user’s roles. In WordPress 4.9 this can now be achieved through the REST API by making a request such as
PUT wp/v2/users/<id> and passing only the
roles argument in the request body. No other arguments must be given as those would require the current user to have network administrator capabilities. See #40263.
- The new
can_add_user_to_blog 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. can be used to prevent a user from adding specific users to a site or with a specific role. See #41101.
- The old site network admin (and super admin) email address gets notified of a change to the address. See related security improvements for 4.9 and #39117.