In `switch_to_blog()`:
* Rename `$blog_id` to `$prev_blog_id` for clarity.
* Rename `$new_blog` to `$new_blog_id` for consistency.
* Pass `$prev_blog_id` as a second parameter to `switch_blog` action, instead of the duplicated `$new_blog_id`. This only clarifies documentation and does not affect functionality, since the values are equal in the context where the DocBlock is located.
In `restore_current_blog()`:
* Rename `$blog` to `$new_blog_id` for clarity.
* Rename `$blog_id` to `$prev_blog_id` for clarity.
Props ChriCo, jeremyfelt, SergeyBiryukov.
Fixes#45594.
Built from https://develop.svn.wordpress.org/trunk@45794
git-svn-id: http://core.svn.wordpress.org/trunk@45605 1a063a9b-81f0-0310-95a4-ce76da25c4cd
By providing distinct files for the site and network APIs, a better overview is provided. Prior to this change, the `ms-blogs.php` file had grown too big, mixing site APIs, network APIs and related legacy APIs that need to be maintained. Since multisite is often used in unexpected ways, backward-compatibility is ensured by including the two new files from `ms-blogs.php`, which previously contained all functions that have been moved to the new files.
This changeset does not contain any functional changes.
Fixes#40647.
Built from https://develop.svn.wordpress.org/trunk@44472
git-svn-id: http://core.svn.wordpress.org/trunk@44303 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset makes the new CRUD API for sites introduced in [43548] usable for real-world sites. A new function `wp_initialize_site()`, which takes care of creating a site's database tables and populating them with initial values, is hooked into the site insertion process that is initiated when calling `wp_insert_site()`. Similarly, a new function `wp_uninitialize_site()`, which takes care of dropping a site's database tables, is hooked into the site deletion process that is initiated when calling `wp_delete_site()`.
A new function `wp_is_site_initialized()` completes the API, allowing to check whether a site is initialized. Since this function always makes a database request in its default behavior, it should be called with caution. Plugins that would like to use site initialization in special ways can leverage a `pre_wp_is_site_initialized` filter to alter that default behavior.
The separate handling of the site's row in the `wp_blogs` database table and the actual site setup allows for more flexibility in controlling whether or how a site's data is set up. For example, a unit test that only checks data from the site's database table row can unhook the site initialization process to improve performance. At the same time, developers consuming the new sites API only need to know about the CRUD functions, since the initialization and uninitialization processes happen internally.
With this changeset, the foundation for a sites REST API endpoint is fully available. The previously recommended functions `wpmu_create_blog()` and `wpmu_delete_blog()` now call the new respective function internally. Further follow-up work to this includes replacing calls to `wpmu_create_blog()` with `wp_insert_site()`, `update_blog_details()` with `wp_update_site()` and `wpmu_delete_blog()` with `wp_delete_blog()` throughout the codebase.
As a side-effect of this work, the `wpmu_new_blog`, `delete_blog`, and `deleted_blog` actions and the `install_blog()` function have been deprecated.
Fixes#41333. See #40364.
Built from https://develop.svn.wordpress.org/trunk@43654
git-svn-id: http://core.svn.wordpress.org/trunk@43483 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
New functions `wp_insert_site( $data )`, `wp_update_site( $id, $data )` and `wp_delete_site( $id )` are introduced to manage site rows in the `wp_blogs` table, forming the new CRUD API together with the existing `get_site()` / `get_sites()`. The new API provides various benefits over the previously existing API, fixing several cache invalidation issues and being hook-driven so that normalization and validation of the passed data can be fully customized.
New hooks introduced as part of this are the actions `wp_insert_site`, `wp_update_site`, `wp_delete_site`, `wp_validate_site_data` and the filter `wp_normalize_site_data`.
At this point, `wp_insert_site()` does not handle setting up the site's database tables, and `wp_delete_site()` does not handle dropping the site's database tables, so the two can not yet be used directly as full replacements of `wpmu_create_blog()` and `wpmu_delete_blog()`. Managing the site's database tables will be added via hooks as part of the follow-up ticket #41333.
The existing functions `wpmu_create_blog()`, `update_blog_details()`, and `wpmu_delete_blog()` make use of the respective new counterpart and will be obsolete once #41333 has been completed.
Props flixos90, jeremyfelt, spacedmonkey.
Fixes#40364.
Built from https://develop.svn.wordpress.org/trunk@43548
git-svn-id: http://core.svn.wordpress.org/trunk@43377 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
Sergey Biryukov
Felix Arntz
Gary Pendergast
John Blackbourn
Jeremy Felt
Dominik Schilling
Drew Jaynes
Pascal Birchler