Changes between Initial Version and Version 1 of Ticket #40922, comment 10
- Timestamp:
- 07/12/2017 12:15:09 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #40922, comment 10
initial v1 2 2 > 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`? 3 3 4 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`.4 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`. 5 5 6 6 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.