[wp-trac] [WordPress Trac] #40922: Use finer-grained capabilities with `customize_changeset` post type

[WordPress Trac]

#40922: Use finer-grained capabilities with `customize_changeset` post type
----------------------------------------+------------------
 Reporter:  dlh                         |       Owner:
     Type:  enhancement                 |      Status:  new
 Priority:  normal                      |   Milestone:  4.9
Component:  Customize                   |     Version:  4.7
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------

Comment (by dlh):

 @flixos90 The reasoning for trying to use `user_has_cap` to grant would-
 have-been-primitives instead of `map_meta_cap` makes sense to me.

 Currently, developers can currently control access to the Customizer by
 filtering `map_meta_cap` to remap `customize`. However, if I'm reading
 correctly, those existing filters would no longer work as expected under
 [attachment:40922.6.diff] or [attachment:40922.7.diff].

 For example, the two `current_user_can()` calls in this block are
 currently equivalent to `current_user_can( 'customize' )`:
 https://github.com/WordPress/wordpress-
 develop/blob/c1694b35d424b8fbc4abaff94e607c8d52111b11/src/wp-includes
 /class-wp-customize-manager.php#L2081-L2087.

 As such, any `map_meta_cap` filters that remap `customize` have an effect
 today on those `current_user_can()` calls and other similar calls, but I
 don't think they would have an effect on those calls under 6.diff or
 7.diff.

 Most of the effort in [attachment:40922.4.diff] and
 [attachment:40922.5.diff] has gone into preserving compatibility with any
 existing `map_meta_cap` filters that remap `customize`. But do you think
 that preserving that compatibility might not be required?

 Also, about this point:

 > The reason I like this approach is that it's simpler than yet another
 clause in map_meta_cap(), and it's much easier to adjust. If I want to
 give users this capability directly (as a primitive cap) in my custom
 setup, all I need to do is remove the filter hook. If it happens in
 map_meta_cap(), I need to use the filter there to override the default way
 with custom logic, which is much more involved.

 Just noting that [attachment:40922.4.diff] uses a filter too because
 adding clauses for changesets to `map_meta_cap()` potentially comes with
 other backwards-compatibility problems (see comment:15).

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