`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.
git-svn-id: https://develop.svn.wordpress.org/trunk@41661 602fd350-edb4-49c9-b593-d223f7449a82
Prior to this change, when passing another site than the current one to `wp_get_users_with_no_role()` through its `$site_id` parameter, the function still used the roles available on the current site, which would cause users with other roles that possibly exist on the other site to show up as users without a role. Switching the site before retrieving the available rules fixes the issue.
Fixes#42015.
git-svn-id: https://develop.svn.wordpress.org/trunk@41654 602fd350-edb4-49c9-b593-d223f7449a82
The `time` strategy in `count_users()` queries users by role. However, the roles queried for were not affected by passing another site than the current one through the `$site_id` parameter, causing users having roles that were not queried for to appear as users without a role. This changeset fixes the issue by switching the site before retrieving the roles to query for.
Fixes#42014.
git-svn-id: https://develop.svn.wordpress.org/trunk@41653 602fd350-edb4-49c9-b593-d223f7449a82
These two tests assume a certain level of indentation in code which does not conform to core's coding
standards and will hopefully be corrected at some point in #41057.
See #41057
git-svn-id: https://develop.svn.wordpress.org/trunk@41635 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@41625 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@41624 602fd350-edb4-49c9-b593-d223f7449a82
This introduces the following meta capabilities:
* `activate_plugin`
* `deactivate_plugin`
* `deactivate_plugins`
The singular `activate_plugin` and `deactivate_plugin` capabilities are used along with the corresponding plugin name when
determining whether or not a user can activate or deactivate an individual plugin.
The plural `deactivate_plugins` capability is used in place of the existing `activate_plugins` capability when determining
whether a user can deactivate plugins.
Each of these new meta capabilities map to the existing `activate_plugins` primitive capability, which means there is no
change in existing behaviour, but plugins can now filter the capabilities required to activate and deactivate individual
plugins.
Fixes#38652
git-svn-id: https://develop.svn.wordpress.org/trunk@41290 602fd350-edb4-49c9-b593-d223f7449a82
The new meta capabilities are called `install_languages` and `update_languages`. Prior to this change, there were no proper capability checks applied. Instead only the filesystem and related constants were checked, and for actual permissions a rather vague fallback was used where a user needed to have at least one of the other updating capabilities. In addition to being generally more verbose, the new capabilities make it possible for example to allow a user to update languages, but nothing else. By default they fall back to the original way of how they were handled.
Props johnbillion, flixos90.
Fixes#39677.
git-svn-id: https://develop.svn.wordpress.org/trunk@41268 602fd350-edb4-49c9-b593-d223f7449a82
Under certain circumstances, it can be necessary that a user should not be added to a site, beyond the restrictions that WordPress core applies. With the new `can_add_user_to_blog` filter, plugin developers can run custom checks and return an error in case of a failure, that will prevent the user from being added.
The user-facing parts and the REST API route that interact with `add_user_to_blog()` have been adjusted accordingly to provide appropriate error feedback when a user could not be added to a site. Furthermore, two existing error feedback messages in the site admin's "New User" screen have been adjusted to properly show inside an error notice instead of a success notice.
Props jmdodd.
Fixes#41101.
git-svn-id: https://develop.svn.wordpress.org/trunk@41225 602fd350-edb4-49c9-b593-d223f7449a82
This ensures that users who are a member of a site but have no role are correctly listed on the Users screen and can be filtered from the 'None' role filter.
Props tobi823, flixos90, scottlee
Fixes#36196
git-svn-id: https://develop.svn.wordpress.org/trunk@41138 602fd350-edb4-49c9-b593-d223f7449a82
Previously, checks like `current_user_can( 'edit_term_meta', $term_id )`
returned the proper value, but generated a PHP notice due to the fact
that `get_term( $term_id )` could, in certain instances, return
`WP_Error` objects.
Props caercam.
Fixes#40891.
git-svn-id: https://develop.svn.wordpress.org/trunk@40999 602fd350-edb4-49c9-b593-d223f7449a82
Meta capabilities use the capability `do_not_allow` to indicate a user should be blocked from performing a particular action. This ensures users can not have the capability as it would cause unexpected behaviour.
Props johnbillion.
Fixes#41059.
git-svn-id: https://develop.svn.wordpress.org/trunk@40993 602fd350-edb4-49c9-b593-d223f7449a82
This removes the need to manually call `$this->skipWithMultisite()` and `$this->skipWithoutMultisite()` from within the test when the test only runs without Multisite or only runs on Multisite, respectively.
Props jdgrimes for the suggestion.
Fixes#40531
git-svn-id: https://develop.svn.wordpress.org/trunk@40564 602fd350-edb4-49c9-b593-d223f7449a82
This has a slight performance impact on sites with a large number of users when the `time` strategy is used for counting users. Hopefully this impact will be negated by enhancements proposed in #38741.
Props psoluch, dots, boonebgorges, ptbello, tharsheblows
Fixes#29785
git-svn-id: https://develop.svn.wordpress.org/trunk@40560 602fd350-edb4-49c9-b593-d223f7449a82
This brings much needed uniformity to test skipping when a test requires Multisite or when a test should be excluded from running when Multisite is enabled.
Used in conjunction with the `@group ms-required` and `@group ms-excluded` notation, this removes a significant number of skipped tests from the default test suite run.
Fixes#40531
git-svn-id: https://develop.svn.wordpress.org/trunk@40543 602fd350-edb4-49c9-b593-d223f7449a82
If any of these constants are set during testing, they should cause the tests to fail, not to be skipped, otherwise we have a situation where failure conditions are never seen.
See #40533
git-svn-id: https://develop.svn.wordpress.org/trunk@40525 602fd350-edb4-49c9-b593-d223f7449a82
Tests in the `ms-excluded` group are now excluded when running tests with multisite enabled, and tests in the `ms-required` group are excluded when running tests without multisite enabled. The end result is a significantly reduced number of skipped tests polluting PHPUnit's output, which means verbose mode can be used to more easily see which tests are skipped or incomplete, and why.
See #40531
git-svn-id: https://develop.svn.wordpress.org/trunk@40520 602fd350-edb4-49c9-b593-d223f7449a82
Prior to this change, a mix of `is_super_admin()` calls and `manage_network` capability checks was used to determine whether the current user could upgrade the network. With this changeset a dedicated capability is introduced that allows more granular handling.
Props dhanendran for the original patch.
Fixes#39205. See #37616.
git-svn-id: https://develop.svn.wordpress.org/trunk@40404 602fd350-edb4-49c9-b593-d223f7449a82
`setup_network` is a new meta capability that brings more granular control over the permissions to setup a multisite environment. In a non-multisite environment it falls back to `manage_options` while in a multisite it falls back to `manage_network_options`. The introduction of this capability furthermore allows replacing an `is_super_admin()` check.
Props ashokkumar24 for the original patch.
Fixes#39206. See #37616.
git-svn-id: https://develop.svn.wordpress.org/trunk@40390 602fd350-edb4-49c9-b593-d223f7449a82
The `$user_total` member of `WP_User_Query`, and corresponding `get_total()` method, have always been documented as returning an `int`. `$user_total`, however, is populated by `$wpdb->get_var()`, which returns
a string (containing an integer value). Casting the return value from `get_var()` as an `int` rectifies this discrepency.
Props runciters.
Fixes#39297.
git-svn-id: https://develop.svn.wordpress.org/trunk@39915 602fd350-edb4-49c9-b593-d223f7449a82
Site administrators should not be able to remove themselves from a site. This moves the enforcement of this rule from `wp-admin/users.php` to `remove_user_from_blog()` via the `remove_user` capability, which furthermore allows us to get rid of two additional clauses and their `is_super_admin()` checks in `wp-admin/users.php`. A unit test for the new behavior has been added.
Fixes#39063. See #37616.
git-svn-id: https://develop.svn.wordpress.org/trunk@39588 602fd350-edb4-49c9-b593-d223f7449a82
This capability is not relevant on single site installs; it only applies to deleting a site on a multisite installation.
Fixes#38326
git-svn-id: https://develop.svn.wordpress.org/trunk@39494 602fd350-edb4-49c9-b593-d223f7449a82
Additionally, use these meta-caps in the REST API endpoints.
Previously, register_meta()'s auth_callback had no effect for non-post meta. This introduces `{add,edit,delete}_{comment,term,user}_meta` meta-caps to match the existing post meta capabilities. These are currently only used in the REST API.
Props tharsheblows, boonebgorges.
Fixes#38303, fixes#38412.
git-svn-id: https://develop.svn.wordpress.org/trunk@39179 602fd350-edb4-49c9-b593-d223f7449a82
The now deprecated `WP_Roles::reinit()` method was trying to call `__deprecated_function()`, instead of `_deprecated_function()`.
See 23016.
git-svn-id: https://develop.svn.wordpress.org/trunk@39088 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@39082 602fd350-edb4-49c9-b593-d223f7449a82
All users can edit their own profile, as this ability is not linked to an explicit capability. Technically, it should map to the `exist` capability, which will be addressed at a later date.
See #31518
git-svn-id: https://develop.svn.wordpress.org/trunk@38860 602fd350-edb4-49c9-b593-d223f7449a82
* Custom CSS is associated with a given theme and is displayed in an inline `style` element at the `wp_head` hook after the `wp_print_styles` is called so that it overrides any enqueued stylesheets.
* A `wp_get_custom_css()` function is used for accessing the CSS associated with the current theme (or another theme) and a `wp_get_custom_css` filter for manipulating it.
* CSS is managed in customizer via a new "Additional CSS" section with a single `textarea` control.
* `WP_Customize_Section::$description_hidden` is introduced for hiding extended descriptions in customizer sections behind a help toggle as done with panels.
* CSS is stored in a `custom_css` post type with the theme (stylesheet) slug as the `post_name`.
* `WP_Customize_Custom_CSS_Setting` is introduced to handle validation of CSS, previewing, and persisting the CSS to the `custom_css` post type.
* The `custom_css` setting is tied to a new `unfiltered_css` capability which maps to `unfiltered_html` by default.
* Escaping the message in the notification template is removed to allow markup (`code` tags) to be rendered.
See https://make.wordpress.org/core/2016/10/11/feature-proposal-better-theme-customizations-via-custom-css-with-live-previews/
Props johnregan3, celloexpressions, folletto, westonruter.
Fixes#35395.
git-svn-id: https://develop.svn.wordpress.org/trunk@38829 602fd350-edb4-49c9-b593-d223f7449a82
