Multisite Focused Changes in 4.6

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.

Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.

Other questions? Here is a detailed handbook for contributors, complete with tutorials.

The 4.6 release cycle has been a productive one! Several major and a few minor updates are described in detail below. If you’d like even more detail, here is a full list of multisitemultisite 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 focused changes for 4.6.

Introduce WP_Site_Query and WP_Network_Query

WordPress 4.6 introduces WP_Site_Query and WP_Network_Query as well as their companion functions, get_sites() and get_networks().

WP_Site_Query

With WP_Site_Query (or get_sites()), sites can now be queried from the $wpdb->blogs table in a flexible way by id, domain, path, and more. For a full list of supported arguments, see the documentation attached to the __construct() method.

New filters and actions associated with this change include parse_site_query, pre_get_sites, the_sites, site_search_columns, sites_clauses, and found_sites_query.

Query results are cached as part of the global sites group. This will provide a performance boost for sites using a persistent object cache.

The introduction of this class helped resolve several long standing issues with WP_MS_Sites_List_Table. Expect to see a faster and more relevant search when browsing through a networknetwork (versus site, blog)’s sites. See #36675.

For the background discussion around these changes, see #35791.

WP_Network_Query

With WP_Network_Query (or get_networks()), networks can now be queried from the $wpdb->site table by id, domain, and path. Query results are cached as part of the global networks group. For a full list of supported arguments, see the documentation attached to the __construct() method.

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not provide a UIUI User interface for managing multiple networks, but any sites using a pluginPlugin 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 to do this will start to see a benefit from having this available.

New filters and actions associated with this change include parse_network_query, pre_get_networks, the_networks, networks_clauses, and found_networks_query.

For the background discussion around these changes, see #32504.

Enhancements to WP_Site and WP_Network

New utility methods

New functions get_site() and get_network() have been introduced to retrieve a specific site or network respectively. They both accept either an ID, database object or class instance as the first parameter. If that parameter is omitted, the current site / network is returned.

Property changes on WP_Site and WP_Network

The WP_Site and WP_Network objects now support access to their respective ID properties through property names which match current naming conventions. Furthermore, by accessing the properties with the new names, it is ensured that these are returned as integers rather than strings. The old properties are still accessible and valid, but these changes should encourage developers to use the new property names.

The following is the list of property improvements:

$site->id is the site’s ID. (previously $site->blog_id)
$site->network_id is the site’s parent network ID. (previously $site->site_id)
$network->id is now an integer instead of a string.
$network->site_id is the network’s main site ID. (previously $network->blog_id)

For background discussion around these changes, see #36717 and #37050.

Lazy-loading extended properties

Additional properties of a site object normally accessed with get_blog_details() are now automatically lazy-loaded when requested. This allows developers to use get_site() as a replacement for get_blog_details() which is likely to be deprecated in a future release. See #36935.

New Actions and Filters

Several new actions and filters were added as part of the WP_Site_Query and WP_Network_Query changes. Here are some others of note:

ms_loaded fires at the end of the multisite bootstrap process in ms-settings.php. At this point the current site and network are available in the global scope. See #37235.
pre_get_blogs_of_user allows developers to alter or short-circuit the results of get_blogs_of_user(), which can be an expensive function to run on configurations with many users. See #36707.
clean_site_cache fires after cache has been cleared with clear_blog_cache(). This can be useful for clearing any custom cache keys associated with a site record. See #36203.
network_edit_site_nav_links filters the list of links displayed at the top of Edit Site views as a “tabbed” interface. See #15800.
ms_sites_list_table_query_args filters the arguments passed to WP_Site_Query when building the MS Sites List Table. See #26580.

Other enhancements of note

Introduce get_current_network_id() as a helper function to find the current network’s ID. See #33900.

The MULTISITE and SUBDOMAIN_INSTALL constants can now be overridden in a project’s wp-config.php when running unit tests. See #36567.

Deprecated Functions

wp_get_sites() has been deprecated and get_sites() should be used instead. Please note when making code changes that get_sites() returns an array of WP_Site objects where wp_get_sites() returned an array of arrays.

WP Multi Network compatibility

The introduction of get_networks() in 4.6 conflicts with the function of the same name in WP Multi Network, a plugin commonly used to provide multiple networks on a multisite installation. A fix for this is already in the master branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of the plugin, and will be included in the next release. In the same change, many other functions were wrapped in function_exists() calls to prevent similar conflicts in the future. If you are using WP Multi Network, please be sure to update accordingly.

#4-6, #dev-notes, #multisite, #network-sites

David Naber 8:14 am on July 9, 2016

wp_get_sites() has been deprecated and get_sites() should be used instead.

…

The introduction of get_networks() in 4.6 conflicts with the function of the same name …

Am I the only one who spots the problem here? Why gets prefixed functions deprecated in favor to use unprefixed ones and even unprefixed functions gets introduced today?
- Jeremy Felt 8:39 pm on July 9, 2016
  
  Thanks David, you aren’t the only one. 🙂 We deliberated on this before going forward. In addition to conversations during the weekly multisitemultisite 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 chats, we brought this up for discussion in the weekly coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dev chat – https://wordpress.slack.com/archives/core/p1462395264003378.
  
  In general, it was agreed that for the benefit of developer experience, having `get_site(s)` and `get_network(s)` match the existing experience for posts, users, comments, etc… made sense here.
  
  We did some due diligence and searched the plugins directory for any usages, knowing in advance that WP Multi Networknetwork (versus site, blog) would conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.. There are no other obvious conflicts and WPMN has been a good example multiple times where a function there makes sense in WordPress core.
  
  The deprecation of `wp_get_sites()` is a benefit of making this decision as it also broke with developer experience and returned an array of arrays rather than `WP_Site` objects as one would expect. A similar change has happened with `wp_get_network()`, though it has not yet been deprecated.
  - David Naber 4:47 pm on July 10, 2016
    
    With «developer experience» you mean the weekend hours to workaround naming collisions when using WordPress together with other code bases, for example?
    
    Prefixing is something fundamental when not using namespaces. Why not just the other way around and deprecate everything non-prefixed and introduce a prefixed version of it?
    - Ipstenu (Mika Epstein) 9:27 pm on July 10, 2016
      
      Currently we enforce plugins hosted on .org to use namespaces or prefixes, to prevent these kinds of issues. When we introduce new functions, we are highly aware of the potential for conflicts. As the ‘parent’ project, WordPress’ use of function prefixes is less of a requirement than for the children of themes and plugins.
      
      We’ve had as many issues with wp_ or wordpress_ as prefixes, compared to nothing as a prefix. It’s simply the bane of project management when you have an ecosystem this large.
      
      In general we search for all plugins in the repository and attempt to find any potential conflicts.
Martin Stehle 12:11 pm on July 22, 2016

Can you please confirm that code will be correct:
// get registered site IDs
$site_ids = array();
if ( version_compare( get_bloginfo( ‘version’ ), ‘4.6.0’, ‘>=’ ) ) {
$sites = get_sites();
foreach ( $sites as $site ) {
$site_ids[] = $site->id;
}
} else {
$sites = wp_get_sites();
foreach ( $sites as $site ) {
$site_ids[] = $site[ ‘blog_id’ ];
}
}

Thank you.
- Felix Arntz 7:01 pm on July 27, 2016
  
  Hi Martin, yes that code is correct and works in a backward compatible way. A minor improvement: In the first clause you could use the following code:
  
  $site_ids = get_sites( array( ‘fields’ => ‘ids’ ) );
  
  By using that code, you don’t need to query the entire site objects and thus can get rid of the foreach loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop.. Note that this only works for the first clause (4.6 version).
tazo todua 5:13 pm on September 1, 2016

get_site() doesnt contains these values, what we should do ?

`public ‘blogname’ => string ”`
`public ‘siteurl’ => string ‘http://127.0.0.1/mysub’`
`public ‘post_count’ => boolean false`
`public ‘home’ => string ‘http://127.0.0.1/mysub’`
- Jeremy Felt 5:35 pm on September 1, 2016
  
  @tazo todua The `WP_Site` object returned by `get_site()` should lazy load those properties once they are requested.
  - tazo todua 8:39 am on September 2, 2016
    
    can you explain what’s lazy-load means? I called `get_site(3)` and it returned the values correclty (like `get_blog_details()`), but the above properties were missing.
    - Jeremy Felt 4:18 pm on September 2, 2016
      
      Of course! Sorry for the bad description. 🙂
      
      If you do something like `$site = get_site( 3 ); var_dump( $site );`, you’ll get a WP_Site object that has default properties, but none of those listed in your first comment. As soon as you request one of those properties, say via `$site->post_count;`, then they will populate.
      
      This saves some processing until the properties are actually needed.
      - tazo todua 5:16 pm on September 2, 2016
        
        thanks! now i understand.
      - tazo todua 5:18 pm on September 2, 2016
        
        what is the way, to know, what lazy-load properties does any OBJECT has? how to predict what properties may be available?
        
        (thanks for your answers to my questions, that will be helpful to many others like me).