* A `WP_Site` object initially matches a row from `wp_blogs`.
* A site can be retrieved by its ID through `WP_Site::get_instance()`.
* Adds `sites` to the global cache group and captures instance lookups.
* The multisite bootstrap now ensures `$current_blog` is an instance of `WP_Site`.
Props johnjamesjacoby, jeremyfelt.
See #32450.
Built from https://develop.svn.wordpress.org/trunk@36393
git-svn-id: http://core.svn.wordpress.org/trunk@36360 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Activation of a subdomain site is done through that new site's address. This address does not exist in the `wp_blogs` table until activation is complete.
In this case we need to make sure `public` is populated to avoid a PHP notice.
Props uglyrobot.
Fixes#24760.
Built from https://develop.svn.wordpress.org/trunk@35782
git-svn-id: http://core.svn.wordpress.org/trunk@35746 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
Built from https://develop.svn.wordpress.org/trunk@34828
git-svn-id: http://core.svn.wordpress.org/trunk@34793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Move the internals of `get_network_by_path()` to `WP_Network()` and allow network objects to be retrieved by passing a requested domain and path.
Props johnjamesjacoby, jeremyfelt, drewapicture, wonderboymusic.
See #31985.
Built from https://develop.svn.wordpress.org/trunk@34099
git-svn-id: http://core.svn.wordpress.org/trunk@34067 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A `WP_Network` object initially matches a row from `wp_site` and is populated with additional properties used by WordPress core. The first iteration is used to retrieve an existing network based on data passed to the class.
* A network can be retrieved by its ID through `WP_Network::get_instance()`, following in the steps of `WP_Post` and `WP_Comment`.
* A network object can be created or completed by passing initial properties in as a standard object to `new WP_Network()`.
Using these methods, we are now able to populate the global `$current_site` during load via this class.
Props johnjamesjacoby, jeremyfelt, drewapicture, wonderboymusic.
See #31985.
Built from https://develop.svn.wordpress.org/trunk@34097
git-svn-id: http://core.svn.wordpress.org/trunk@34065 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`ms_network_not_found` fires when the global `$current_site` has not been filled and `ms_not_installed()` is about to fire. It cannot be used to populate `$current_site`, but can be used to capture the request and redirect or present a custom error.
Props rmccue.
Fixes#31702.
Built from https://develop.svn.wordpress.org/trunk@33990
git-svn-id: http://core.svn.wordpress.org/trunk@33959 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is the first big step to supporting arbitrary domains and paths. In this new approach, sites are detected first where possible, then the network is inferred. Allows filtering for arbitrary path segments, smooths out some weirdness, and removes various restrictions. A sunrise plugin could do much of its work by adding filters, if those are even needed.
see #27003.
Built from https://develop.svn.wordpress.org/trunk@27359
git-svn-id: http://core.svn.wordpress.org/trunk@27209 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Tries to get network detection under control by simplifying wpmu_current_site(). It now also pops off each subdomain to find a more general match. Adds unit tests for get_network_by_path() and a new network factory for unit tests.
Much of this is likely to change in 3.9 as more of ms-load.php and ms-settings.php gets hacked to bits.
props jeremyfelt.
see #27003.
Built from https://develop.svn.wordpress.org/trunk@27178
git-svn-id: http://core.svn.wordpress.org/trunk@27040 1a063a9b-81f0-0310-95a4-ce76da25c4cd
wp-includes/admin-bar.php:
* Replace get_admin_url() and get_home_url() with admin_url() and home_url() and place them inside a switch/restore. Likewise replace current_user_can_for_blog() with current_user_can(). This avoids doing multiple switch restores.
wp-includes/ms-blogs.php:
* Deprecate the $validate argument to switch_to_blog(). This avoids a not very necessary call to get_blog_details(), possibly saving a few queries.
* Use $_wp_switched and $_wp_switched_stack instead of $switched and $switched_stack to make it less likely these globals will be stomped.
* Use GLOBALS to access blog_id and other globals. I've preferred this style lately since it makes it obvious a global is being used and avoids global blog_id being stomped by a local variable.
* Lose some is_object() checks. wp_get_current_user() always returns an object, for example.
* Call the new WP_Roles::reinit() method.
wp-includes/class-wp-xmlrpc-server.php:
* Replace current_user_can_for_blog() with current_user_can() and move it inside the switch/restore pair. This eliminates a switch/restore.
wp-includes/capabilities.php:
* Use array_keys() instead of $role => $data since $data is unused. I *think* this is a bit faster.
* Introduce WP_Roles::reinit(). This reinitializes WP_Roles and is used after switch_to_blog() has already update the blog ID in the wpdb object. If a global roles array is being used instead of the db, reinit is skipped.
* current_user_can_for_blog() now does a switch/restore. It didn't before meaning it could be reinitializing the user with the wrong role information for the current blog.
wp-includes/ms-settings.php:
* Define $_wp_switched_stack and $_wp_switched. This way switch_to_blog() and restore_current_blog() can rely on it being set.
wp-settings.php:
* Instantiate the WP_Roles global. This was it is always defined during init. To remove the WP_Roles checks from WP_Role and WP_User this would probably have to move before plugins are loaded, which might not be a good thing.
wp-includes/functions.php:
* Update wp_upload_dir() to reference _wp_switched.
git-svn-id: http://core.svn.wordpress.org/trunk@21485 1a063a9b-81f0-0310-95a4-ce76da25c4cd
