There is a bug where the attributes panel is not shown in custom post types. This is caused because each post type can define a capability_type, which by default is post, so the logic to map the capabilities wasn't correct and it was returning false.
Props santosguillamot, cbravobernal.
Fixes#62226.
Built from https://develop.svn.wordpress.org/trunk@59239
git-svn-id: http://core.svn.wordpress.org/trunk@58631 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `current_user_can_for_site()` function is a replacement for `current_user_can_for_blog()` which is now deprecated. `user_can_for_site()` is a renaming of the `user_can_for_blog()` function which was introduced in [59123]. The intention of this change is to prevent the introduction of a new function which uses the old "blog" naming structure.
Props swissspidy, spacedmonkey, flixos90, johnjamesjacoby
Fixes#45197
Built from https://develop.svn.wordpress.org/trunk@59198
git-svn-id: http://core.svn.wordpress.org/trunk@58593 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a `canUpdateBlockBindings` editor setting that allows to decide if the user is able to create and modify bindings through the UI. By default, only admin users can do it, but it can be overridden with `block_editor_settings_all` filter.
Props santosguillamot, gziolo, jorbin, noisysocks, matveb, cbravobernal, youknowriad, mamaduka, timothyblynjacobs, peterwilsoncc, drivingralle.
Fixes#61945.
Built from https://develop.svn.wordpress.org/trunk@59122
git-svn-id: http://core.svn.wordpress.org/trunk@58518 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After some further discussion, it is apparent that the added clarity was subjective, and the `_screen` suffix may not always be appropriate, e.g. in Ajax context. To address any confusion with the existing names, the documentation for these functions can be updated instead.
Additionally, the `is_super_admin_user()` alias for `is_super_admin()` is reverted as well, which may be reconsidered in the future.
Follow-up to [54259].
Props azaozz, jrf, johnbillion, manfcarlo, Clorith.
See #56400.
Built from https://develop.svn.wordpress.org/trunk@54332
git-svn-id: http://core.svn.wordpress.org/trunk@53891 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Following the introduction of `is_login_screen()` in [53884], it is time to reconsider the `is_*_admin()` functions:
* `is_admin()`: Determines whether the current request is for an administrative interface page.
* `is_blog_admin()`: Whether the current request is for a site's administrative interface, e.g. `/wp-admin/`.
* `is_network_admin()`: Whether the current request is for the network administrative interface, e.g. `/wp-admin/network/`.
* `is_user_admin()`: Whether the current request is for a user admin screen, e.g. `/wp-admin/user/`.
For someone new to WordPress, these names can be quite confusing, especially the last one. When using these functions, one always needs to remember that they don't actually check if the current user is a site administrator.
To complicate things further, there is one more similarly named function that does exactly the latter:
* `is_super_admin()`: Determines whether user is a site admin.
With the above in mind, this commit introduces aliases that better match the functionality and allow for more descriptive code:
* `is_admin()` → `is_admin_screen()`
* `is_blog_admin()` → `is_site_admin_screen()`
* `is_network_admin()` → `is_network_admin_screen()`
* `is_user_admin()` → `is_user_admin_screen()`
Additionally, `is_super_admin_user()` is introduced as an alias for `is_super_admin()`:
* `is_super_admin()` → `is_super_admin_user()`
Plugins and themes are encouraged to start using the newer function names to make code self-descriptive and bring more clarity. The older names are not deprecated at this time, though it may be up for discussion in the future.
Follow-up to [2481], [6412], [12393], [12732], [15558], [15481], [15746], [53884].
Props jrf, tobifjellner, SergeyBiryukov.
See #56400.
Built from https://develop.svn.wordpress.org/trunk@54259
git-svn-id: http://core.svn.wordpress.org/trunk@53818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Until now, changing a user's role involved deleting a user's role then re-adding. This change creates a new `update_role` function and associated method in `WP_Roles` to consolidate this process.
This commit also introduces new unit tests around `update_role` and adds additional "unhappy path" tests for roles and capabilities in general.
Props maksimkuzmin, peterwilsoncc, NomNom99, costdev, SergeyBiryukov.
Fixes#54572.
Built from https://develop.svn.wordpress.org/trunk@54213
git-svn-id: http://core.svn.wordpress.org/trunk@53772 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids an `Undefined array key 0` PHP warning for `current_user_can()` capability checks that require a specific object to check against but an object ID was not passed.
A `_doing_it_wrong()` notice is also added, so that developers and site administrators are aware that the capability mapping is failing in the absence of the required object ID.
The list of mapped capabilities that require an object ID:
* `delete_post` / `delete_page`
* `edit_post` / `edit_page`
* `read_post` / `read_page`
* `publish_post`
* `edit_(post|comment|term|user)_meta` / `delete_*_meta` / `add_*_meta`
* `edit_comment`
* `edit_term` / `delete_term` / `assign_term`
Follow-up to [34091], [34113], [47178].
Props jeherve, peterwilsoncc, henry.wright, johnbillion, mattheweppelsheimer, hellofromTonya, JeffPaul, azouamauriac, Ninos Ego, TobiasBg, wpsmith, GaryJ, nacin, johnstonphilip, azaozz, SergeyBiryukov.
Fixes#44591.
Built from https://develop.svn.wordpress.org/trunk@53408
git-svn-id: http://core.svn.wordpress.org/trunk@52997 1a063a9b-81f0-0310-95a4-ce76da25c4cd
On multisite, when checking if a user has a certain capability WordPress makes an additional check to see if the user is a super admin. The `is_super_admin()` function contained a call to `wp_get_current_user()` so as the global current user object could be used if it matched the queried user id.
This would cause an infinite loop if a hook attached to the `determine_current_user` filter was itself making a permission check. For example when limiting who can use the Application Passwords feature based on their capabilities.
Since [50790] the `WP_User` instance for the current user is shared between `wp_get_current_user()` and `get_userdata()`. This means we can remove the `wp_get_current_user` call from `is_super_admin()` while still retaining the same behavior.
Props chrisvanpatten, peterwilsoncc.
Fixes#53386.
Built from https://develop.svn.wordpress.org/trunk@52157
git-svn-id: http://core.svn.wordpress.org/trunk@51749 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensure `current_user_can()` and `user_can()` return the same results for logged out users. For core capabilities this changes `user_can( 0, 'exist' )` to return `true` rather than `false` in line with `current_user_can( 'exist' )` for logged out users.
Convert `current_user_can()` and `current_user_can_for_blog()` to wrapper functions ultimately calling `user_can()`.
Add anonymous user to primitive capability checks as appropriate. Convert `Tests_User_Capabilities::test_other_caps_for_all_roles()` to use a data provider and add tests to check whether user exists in the database (`WP_User::exists()`) as that intentionally differs from the `exist` capability.
Props jjj, johnbillion, peterwilsoncc, SergeyBiryukov, TimothyBlynJacobs.
Fixes#52076.
Built from https://develop.svn.wordpress.org/trunk@50490
git-svn-id: http://core.svn.wordpress.org/trunk@50103 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add check to `redirect_canonical()` to ensure private posts only redirect for logged in users.
Modifies the `read_post` mata capability to user `get_post_status()` rather than the post's `post_status` property to allow attachments to redirect based on the inherited post status.
Introduces `wp_force_ugly_post_permalink()` to unify the check to determine if an ugly link should be displayed in each of the functions used for determining permalinks: `get_permalink()`, `get_post_permalink()`, `_get_page_link()` and `get_attachment_link()`.
Improves logic of `get_attachment_link()` to validate parent post and resolution of inherited post status. This is an incomplete fix of #52373 to prevent the function returning links resulting in a file not found error. Required to unblock this ticket.
Props peterwilsoncc, TimothyBlynJacobs.
See #52373.
Fixes#5272.
Built from https://develop.svn.wordpress.org/trunk@50132
git-svn-id: http://core.svn.wordpress.org/trunk@49811 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Switching a WordPress site from HTTP to HTTPS has historically been a tedious task. While on the surface the Site Address and WordPress Address have to be updated, existing content still remains using HTTP URLs where hard-coded in the database. Furthermore, updating _two_ URLs to migrate to HTTPS is still a fairly unintuitive step which is not clearly explained.
This changeset simplifies migration from HTTP to HTTPS and, where possible, makes it a one-click interaction.
* Automatically replace insecure versions of the Site Address (`home_url()`) with its HTTPS counterpart on the fly if the site has been migrated from HTTP to HTTPS. This is accomplished by introducing a `https_migration_required` option and enabling it when the `home_url()` is accordingly changed.
* A new `wp_replace_insecure_home_url()` function is hooked into various pieces of content to replace URLs accordingly.
* The migration only kicks in when the Site Address (`home_url()`) and WordPress Address (`site_url()`) match, which is the widely common case. Configurations where these differ are often maintained by more advanced users, where this migration routine would be less essential - something to potentially iterate on in the future though.
* The migration does not actually update content in the database. More savvy users that prefer to do that can prevent the migration logic from running by either deleting the `https_migration_required` option or using the new `wp_should_replace_insecure_home_url` filter.
* For fresh sites that do not have any content yet at the point of changing the URLs to HTTPS, the migration will also be skipped since it would not be relevant.
* Expose a primary action in the Site Health recommendation, if HTTPS is already supported by the environment, built on top of the HTTPS detection mechanism from [49904]. When clicked, the default behavior is to update `home_url()` and `site_url()` in one go to their HTTPS counterpart.
* A new `wp_update_urls_to_https()` function takes care of the update routine.
* A new `update_https` meta capability is introduced to control access.
* If the site's URLs are controlled by constants, this update is not automatically possible, so in these scenarios the user is informed about that in the HTTPS status check in Site Health.
* Allow hosting providers to modify the URLs linked to in the HTTPS status check in Site Health, similar to how that is possible for the URLs around updating the PHP version.
* A `WP_UPDATE_HTTPS_URL` environment variable or `wp_update_https_url` filter can be used to provide a custom URL with guidance about updating the site to use HTTPS.
* A `WP_DIRECT_UPDATE_HTTPS_URL` environment variable or `wp_direct_update_https_url` filter can be used to provide a custom URL for the primary CTA to update the site to use HTTPS.
Props flixos90, timothyblynjacobs.
Fixes#51437.
Built from https://develop.svn.wordpress.org/trunk@50131
git-svn-id: http://core.svn.wordpress.org/trunk@49810 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, all permission checks for using app passwords were implemented using `edit_user`. This commit introduces a series of more fine grained meta capabilities that should be used instead: `create_app_password`, `list_app_passwords`, `read_app_password`, `edit_app_password`, `delete_app_password` and `delete_app_passwords`. These capabilities all map to `edit_user` by default, but may now be customized by developers.
Props johnbillion, TimothyBlynJacobs.
Fixes#51703.
Built from https://develop.svn.wordpress.org/trunk@50114
git-svn-id: http://core.svn.wordpress.org/trunk@49793 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The new default_term argument is added to `register_taxonomy()` allowing a user to define the default term `name` and optionally `slug` and `description`.
Fixes#43517.
Props enrico.sorcinelli, SergeyBiryukov, desrosj, davidbaumwald, whyisjake.
Built from https://develop.svn.wordpress.org/trunk@48356
git-svn-id: http://core.svn.wordpress.org/trunk@48125 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a final pass to fix PHP compatibiilty issues in the codebase with code changes or adding `phpcs:ignore` comments.
With this change, all PHP compatibility warnings and errors without specific tickets have been addressed (see #49810 and #41750).
Props desrosj, johnbillion, jrf.
See #49922.
Built from https://develop.svn.wordpress.org/trunk@47902
git-svn-id: http://core.svn.wordpress.org/trunk@47676 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `erase_others_personal_data`
* `export_others_personal_data`
* `manage_privacy_options`
Previously mapped to `manage_options` or `manage_network` (on Multisite), these are now added to the Administrator role separately.
Additionally, `manage_privacy_options` is added to the Editor role.
Props garrett-eclipse, xkon, pbiron, desrosj, johnbillion, flixos90, juliobox, lakenh, Ov3rfly, ianatkins.
Fixes#44176.
Built from https://develop.svn.wordpress.org/trunk@47269
git-svn-id: http://core.svn.wordpress.org/trunk@47069 1a063a9b-81f0-0310-95a4-ce76da25c4cd
With `map_meta_cap` enabled for a post type, the `read_post` capability for posts with a public status is supposed to be mapped to the post type's `read` capability.
When a post is left in the database after the post status is no longer present, and WP does a `read_post` check against it, a PHP notice was thrown, and the cap check always failed.
As a more graceful fallback, the cap is now mapped onto `edit_others_posts`, which allows highly privileged users to be able to access orphaned content.
A `_doing_it_wrong()` notice is also added, so that developers and site administrators are aware that the cap mapping is failing in the absence of the registered post status.
Follow-up to [34091], which introduced a similar approach to checking mapped caps against an unregistered post type.
Props roytanck, SergeyBiryukov.
Fixes#48653.
Built from https://develop.svn.wordpress.org/trunk@47178
git-svn-id: http://core.svn.wordpress.org/trunk@46978 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Allowing the client to delete revisions breaks the "audit trail" functionality. This is not allowed in WordPress and shouldn't be allowed through the API.
While not recommended, a plugin may opt-in to the previous behavior by setting a custom 'delete_post' capability for the revisions post type.
Props dlh, danielbachhuber, TimothyBlynJacobs, azaozz, kadamwhite.
Fixes#43709.
Built from https://develop.svn.wordpress.org/trunk@45812
git-svn-id: http://core.svn.wordpress.org/trunk@45623 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces the faux primitive capability `view_site_health_checks` available to single site admins and multisite super-admin to view the site health page within the admin.
The capability is mapped to the `install_plugins` capability without being dependent on the file system being writable. This fixes a bug where the feature couldn't be used by sites unable to write to the file system or managed through version control.
The capability is granted on the `user_has_cap` filter.
Props birgire, Clorith, palmiak, peterwilsoncc, spacedmonkey.
Fixes#46957.
Built from https://develop.svn.wordpress.org/trunk@45507
git-svn-id: http://core.svn.wordpress.org/trunk@45318 1a063a9b-81f0-0310-95a4-ce76da25c4cd
