[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