[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:  (none)
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Customize                     |     Version:  4.7
 Severity:  normal                        |  Resolution:
 Keywords:  needs-unit-tests needs-patch  |     Focuses:
------------------------------------------+-----------------------------
Changes (by dlh):

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


Comment:

 @ocean90 Tentatively, I'm not sure any of the patches here would be
 appropriate for #50128. As I see it, the sticking point is that backwards
 compatibility is lost unless developers are given the opportunity to remap
 `customize` in the `map_meta_cap` filter. Using `edit_post`, etc. directly
 means that `edit_post` is the filtered `$cap`, and the previous patches
 don't handle that case very well as currently written.

 [attachment:"40922.4.diff"] kinda provided this compatibility by calling
 `map_meta_cap( 'customize' )` again in a filter, but it required setting
 the post type to `map_meta_cap => false`, which might not be ideal.

 The only other idea that comes to mind right now that's not expressed in a
 patch would be to change the post type `capabilities` to
 `edit_theme_options`, then hardcode exceptions within `map_meta_cap()` for
 `read_post`, etc. to change the `$cap` back to `customize` (or variations
 on this, which all come back to hardcoding something in `map_meta_cap()`).

 I'll be interested to hear your thoughts.

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