Posts, Post Types: Fail gracefully when checking mapped cap against unregistered post status.

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
This commit is contained in:
Sergey Biryukov 2020-02-04 22:15:08 +00:00
parent 3882b3f567
commit 46951e0b17
2 changed files with 8 additions and 1 deletions

View File

@ -241,6 +241,13 @@ function map_meta_cap( $cap, $user_id, ...$args ) {
}
$status_obj = get_post_status_object( $post->post_status );
if ( ! $status_obj ) {
/* translators: 1: Post status, 2: Capability name. */
_doing_it_wrong( __FUNCTION__, sprintf( __( 'The post status %1$s is not registered, so it may not be reliable to check the capability "%2$s" against a post with that status.' ), $post->post_status, $cap ), '5.4.0' );
$caps[] = 'edit_others_posts';
break;
}
if ( $status_obj->public ) {
$caps[] = $post_type->cap->read;
break;

View File

@ -13,7 +13,7 @@
*
* @global string $wp_version
*/
$wp_version = '5.4-alpha-47177';
$wp_version = '5.4-alpha-47178';
/**
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.