[wp-trac] [WordPress Trac] #31518: WP_User::has_cap and 'map_meta_cap' filter

[WordPress Trac]

#31518: WP_User::has_cap and 'map_meta_cap' filter
------------------------------------------+-----------------------------
 Reporter:  dugi digitaly                 |       Owner:  johnbillion
     Type:  defect (bug)                  |      Status:  reviewing
 Priority:  normal                        |   Milestone:  Future Release
Component:  Role/Capability               |     Version:  2.0
 Severity:  normal                        |  Resolution:
 Keywords:  needs-unit-tests needs-patch  |     Focuses:
------------------------------------------+-----------------------------
Changes (by johnbillion):

 * keywords:  has-patch needs-unit-tests dev-feedback => needs-unit-tests
     needs-patch


Comment:

 Replying to [comment:1 swissspidy]:
 > There must be a reason `WP_User::has_cap` returns `true` by default
 though...
 Turns out there is. [attachment:31518.diff] breaks
 `Tests_User_Capabilities::test_multisite_user_can_edit_self()`. The reason
 for this is [https://github.com/WordPress/WordPress/blob/4.3/wp-
 includes/capabilities.php#L1134-L1136 this logic in map_meta_cap()] which
 does not add a primitive capability to the `$caps` array, resulting in it
 being empty, which results in `WP_User::has_cap()` now returning false
 instead of true.

 `exist` is probably the most appropriate capability to require here.

 It looks like there are two further conditions inside `map_meta_cap()`
 which can result in the `$caps` array being empty (when a `break`
 statement occurs when `$caps` hasn't been populated):

  * `(delete|edit)_(post|page}` on your own trashed post which was never
 published.
  * `(edit|delete|add)_post_meta` when an `auth_post_meta_{$meta_key}`
 filter is in place.

 These will all need fixes and/or unit test coverage before this can go in.

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