Changeset 47178 for trunk/src/wp-includes/capabilities.php

Timestamp:

02/04/2020 10:13:15 PM (5 years ago)

Author:

SergeyBiryukov

Message:

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.

File:

• trunk/src/wp-includes/capabilities.php (modified) (1 diff)

trunk/src/wp-includes/capabilities.php

@@ -242 +242 @@
 
             $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;