A new global multisite table `wp_blogmeta` is added to the database schema, and a set of `*_site_meta()` API functions are introduced.
The implementation fails gracefully when the new table is not yet available, which may happen especially shortly after the core update, before the network has been upgraded to the new database schema. The presence of the table is detected once and stored as a global setting on the main network.
Core does not yet use site metadata, but there are several use-cases to be implemented or explored in the near future, and it allows plugins to extend sites with arbitrary data, which will come in particularly handy with the upcoming REST API endpoint for sites.
Props spacedmonkey, johnjamesjacoby, jeremyfelt, flixos90.
Fixes#37923.
Built from https://develop.svn.wordpress.org/trunk@42836
git-svn-id: http://core.svn.wordpress.org/trunk@42666 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While `get_site_by()` makes sense as a more explicit and less complex replacement for `get_blog_details()`, it is not ready yet in terms of caching, where it currently falls short of the older function under specific circumstances.
See #40180, #40228.
Built from https://develop.svn.wordpress.org/trunk@41883
git-svn-id: http://core.svn.wordpress.org/trunk@41717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_site_by()` is now the preferred way to retrieve a site object by lookup for identifying data. By using a coherent structure and `get_sites()` internally, it has several advantages over the direct database queries and complex code in `get_blog_details()`. Therefore `get_blog_details()` is now a wrapper for `get_site_by()`, providing backward compatibility fixes where necessary.
Unit tests have been adjusted to account for the `blog-details` and `blog-lookup` cache groups, which are no longer needed.
Props spacedmonkey, jeremyfelt, flixos90.
Fixes#40228.
Built from https://develop.svn.wordpress.org/trunk@41719
git-svn-id: http://core.svn.wordpress.org/trunk@41553 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Going forward, `clean_blog_cache()` is recommended to be used instead of `refresh_blog_details()`. It has been adjusted to match the functionality of the latter, with the exception that it always requires a site ID or object to be passed. The `refresh_blog_details` action has been deprecated in favor of the `clean_site_cache` action. The function itself is not formally deprecated at this point, but will likely be in the near future.
Props spacedmonkey.
Fixes#40201.
Built from https://develop.svn.wordpress.org/trunk@41716
git-svn-id: http://core.svn.wordpress.org/trunk@41550 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_current_blog_id()` is more appropriate for determining the ID of the current site in most cases. This eliminates the need for the global `$wpdb` in several functions and is better than the implicit global used in admin pages.
Props bnap00, spacedmonkey.
Fixes#41684.
Built from https://develop.svn.wordpress.org/trunk@41661
git-svn-id: http://core.svn.wordpress.org/trunk@41495 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Switching the available roles and the current user's capabilities no longer happens in `switch_to_blog()` and `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 allows to improve performance by temporarily unhooking the function when roles and capabilities do not need to be switched.
This change ensures that switching available roles now works closer to switching user capabilities, particularly the changes in [41624]. A new `WP_Roles::for_site( $site_id )` method has been introduced, and the `WP_Roles::_init()` method has been deprecated. It is furthermore possible to retrieve the site ID for which the available roles are currently initialized through a new `WP_Roles::get_site_id()`.
Props johnjamesjacoby, flixos90.
Fixes#38645.
Built from https://develop.svn.wordpress.org/trunk@41625
git-svn-id: http://core.svn.wordpress.org/trunk@41460 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While it has always been possible to initialize a user's roles and capabilities for another site than the current one in a multisite, the actual roles available were not switched prior to this change, possibly causing invalid roles to show up or actually valid capabilities not being available.
In order to fix this bug in a clean way, relevant parts of the `WP_User` class have been refactored. The ID of the site for which capabilities are currently initialized are now stored in a private property `WP_User::$site_id`. The `WP_User::for_blog( $blog_id )` and `WP_User::_init_caps( $cap_key )` methods have been deprecated in favor of `WP_User::for_site( $site_id )`. In addition, a new method `WP_User::get_site_id()` has been introduced to retrieve the site ID for which the user's capabilities are currently initialized.
Props ryanduff, jeremyfelt, flixos90.
Fixes#36961.
Built from https://develop.svn.wordpress.org/trunk@41624
git-svn-id: http://core.svn.wordpress.org/trunk@41459 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously `update_blog_option()` would trigger an invalidation of that site's entire cache although these changes did not affect the content of these caches. Furthermore changes to the special options `blogname`, `siteurl` and `post_count` should not invalidate the entire cache of that site, but only their respective site details cache. The option `home` now has the same behavior as it also belongs to the site details, but did not invalidate the cache at all previously.
Several new unit tests confirm these changes work as expected.
Fixes#40063.
Built from https://develop.svn.wordpress.org/trunk@40305
git-svn-id: http://core.svn.wordpress.org/trunk@40212 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Historically, it's been difficult to extend user roles, but reasonable to work around by waiting until after `init` has fired, to add custom roles and capabilities. With the addition of Locale Switching, Core now potentially loads roles before `init` has fired, leaving a window where custom roles and capabilities are not handled.
The new filter allows plugins to add their own custom roles whenever they're initialised (on page load, or when switching sites, for example), so that they can always be obeyed.
`WP_Roles` has also been tidied up a little bit, to remove duplicate code.
Props johnjamesjacoby, pento.
Fixes#23016.
Built from https://develop.svn.wordpress.org/trunk@39082
git-svn-id: http://core.svn.wordpress.org/trunk@39024 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_site()` has replaced `get_blog_details()` throughout core and is the recommended way to retrieve a current or single site object.
The `blog_details` filter is applied when full details are requested from `get_blog_details()`.
To ensure backwards compatibility in the switch to `get_site()`, this `blog_details` filter is now applied in `WP_Site::get_details()` and marked as deprecated with a note to rely instead on the `site_details` filter introduced in 4.6.
Props flixos90.
See #37102.
Fixes#38491.
Built from https://develop.svn.wordpress.org/trunk@38936
git-svn-id: http://core.svn.wordpress.org/trunk@38879 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`get_network()` falls back to the current network when called without any arguments. Between this and `get_current_network_id()`, we can replace almost all instances of the global `$current_site` and all instances of `get_current_site()`.
This effectively deprecates `get_current_site()`, something that we'll do in a future ticket.
Props flixos90.
Fixes#37414.
Built from https://develop.svn.wordpress.org/trunk@38814
git-svn-id: http://core.svn.wordpress.org/trunk@38757 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, if a network's domain started with `www.` in a subdomain configuration, a slug lookup with `get_id_from_blogname()` would not match an existing site. A similar lookup in a subdirectory configuration would work fine.
This strips `www.` from the network's domain in a subdomain configuration during the lookup and returns the site as expected.
Adds tests which would previously fail in a subdomain configuration, but now pass in both configurations.
Props igmoweb, flixos90.
Fixes#34450.
Built from https://develop.svn.wordpress.org/trunk@38658
git-svn-id: http://core.svn.wordpress.org/trunk@38601 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the past, `get_blog_details()` has been used to retrieve the `home`, `siteurl`, `blogname`, and `post_count` options for a site. By lazy loading properties in a `WP_Site` object, we can avoid having to use `get_blog_details()` and instead provide the properties as needed.
This introduces the global `site-details` cache group in which standard objects representing the site are stored. This will one day be a replacement for the `blog-details` cache group that is currently used in `get_blog_details()`.
This relies on the `ms_loaded` action introduced in [37916] as properties are not available via `get_option()` until multisite has been fully loaded.
Props flixos90.
Fixes#36935.
Built from https://develop.svn.wordpress.org/trunk@37918
git-svn-id: http://core.svn.wordpress.org/trunk@37859 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Provides a consistent way to query `$wpdb->site` for `WP_Network` objects based on domain, path, network ID, and (main) site ID.
Introduces and uses update_network_cache() and _prime_network_caches() to maintain a cached list of WP_Network objects for use in multiple queries.
Props flixos90.
See #32504.
Built from https://develop.svn.wordpress.org/trunk@37894
git-svn-id: http://core.svn.wordpress.org/trunk@37835 1a063a9b-81f0-0310-95a4-ce76da25c4cd
