[wp-trac] [WordPress Trac] #30991: Post type object capability 'delete_posts' is referenced in the posts list table but does not exist unless 'map_meta_cap' is set to true for post type

WordPress Trac noreply at wordpress.org
Tue May 10 18:18:56 UTC 2016


#30991: Post type object capability 'delete_posts' is referenced in the posts list
table but does not exist unless 'map_meta_cap' is set to true for post type
------------------------------------+-----------------------------
 Reporter:  bamadesigner            |       Owner:  SergeyBiryukov
     Type:  defect (bug)            |      Status:  reviewing
 Priority:  normal                  |   Milestone:  Future Release
Component:  Posts, Post Types       |     Version:  4.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  administration
------------------------------------+-----------------------------

Comment (by johnjamesjacoby):

 Replying to [comment:13 dipesh.kakadiya]:
 > @SergeyBiryukov @dd32
 >
 > Added "delete_posts" as default_capabilities in
 get_post_type_capabilities function
 >
 > Is this right solution?

 As far as I can tell, this is the correct solution.

 [29757] set the precedent that the `delete_posts` capability is assumed to
 exist in the `cap` array of a post type. `map_meta_cap` also assumes this
 capability with exist, but the conditions of that assumption are much more
 strict (editing your own trashed post, that was previously published or
 future dated) so we're less likely to see that debug notice than in
 `get_bulk_actions()` where it's prominently displayed.

 Also, this bug only really manifests itself when registering a post type
 using `capability_type` without `capabilities`. In this case, you end up
 with caps that look like:

 {{{
 object(stdClass)[77]
   public 'edit_post' => string 'edit_event' (length=10)
   public 'read_post' => string 'read_event' (length=10)
   public 'delete_post' => string 'delete_event' (length=12)
   public 'edit_posts' => string 'edit_events' (length=11)
   public 'edit_others_posts' => string 'edit_others_events' (length=18)
   public 'publish_posts' => string 'publish_events' (length=14)
   public 'read_private_posts' => string 'read_private_events' (length=19)
   public 'create_posts' => string 'edit_events' (length=11)
 }}}

 To me, it looks like `delete_posts` is unintentionally being used as a
 primitive cap outside of `map_meta_cap`.

 ----

 The only other fix I can imagine, is to stop looking for:

 {{{
 $post_type_object->caps->delete_posts
 }}}

 and instead use

 {{{
 current_user_can( "delete_{$post_type}" )
 }}}

 but this won't take into account the literal capabilities that might be
 passed in when registering post types and passing in caps with the
 `capabilities` argument.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30991#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list