WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #40922, comment 10


Ignore:
Timestamp:
07/12/2017 12:15:09 AM (4 years ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #40922, comment 10

    initial v1  
    22> 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`?
    33
    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`.
     4Yeah, 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`.
    55
    66But 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.