WordPress.org

Make WordPress Core


Ignore:
Timestamp:
02/04/2020 10:13:15 PM (21 months 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:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/src/wp-includes/capabilities.php

    r47122 r47178  
    242242
    243243            $status_obj = get_post_status_object( $post->post_status );
     244            if ( ! $status_obj ) {
     245                /* translators: 1: Post status, 2: Capability name. */
     246                _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' );
     247                $caps[] = 'edit_others_posts';
     248                break;
     249            }
     250
    244251            if ( $status_obj->public ) {
    245252                $caps[] = $post_type->cap->read;
Note: See TracChangeset for help on using the changeset viewer.