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

WordPress Trac noreply at wordpress.org
Wed Jul 12 00:14:39 UTC 2017


#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    |     Focuses:
-------------------------+------------------

Comment (by westonruter):

 Replying to [comment:9 dlh]:
 > While I'm not opposed to trying that approach, it seems like we would
 run into the same issue you raised in comment:6, if I'm following. The
 `user_has_cap` filter outlined in ticket:28605#comment:8 checks the
 capability string passed to `current_user_can()`, and in the snippet,
 wouldn't `$cap` be `edit_post` or similar, not `customize`?

 Yeah, I think you're right that the
 `allow_users_who_can_edit_posts_to_customize` for the `user_has_cap`
 filter then would not work anymore. Maybe it would be possible to add
 another `user_has_cap` filter that could do a `call_user_func_array(
 'current_user_can', array_merge( array( 'customize', array_slice( $args, 1
 ) ) ) )` ''somewhere'' when the mapped cap was `customize`.

 But in the end, if it is the ''right'' change to make, then we can do an
 education push and identify plugins in the repo that could be affected by
 this. The number of plugins that do filter this I suspect could be counted
 on a pair of hands, but I could be very wrong.

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


More information about the wp-trac mailing list