You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Passing a role name to wp user remove-cap should probably return an error #98
At the user level, WordPress internally treats roles and capabilities the same. They're all stored in the wp_capabilities user meta field. This is unfortunate.
This means that wp user remove-cap <user> <role> works, which can have unexpected consequences if, for example, a script blindly loops over capabilities in order to remove them from a user and one of the capabilities is a role name.
I think if an attempt is made to remove a capability from a user that matches a role name, it should return an error along with recommending that wp user remove-role is used instead.
It's worth noting that WP_User::remove_cap( <role> ) also suffers from the same problem. I'm not sure on WP-CLI's policy of improving upon core's APIs in this way.
It's worth noting that WP_User::remove_cap( <role> ) also suffers from the same problem. I'm not sure on WP-CLI's policy of improving upon core's APIs in this way.
I'm in support of WP-CLI improving upon core's APIs, as long as it's not in opposition to, or diverge too much from, core behavior.
Activity
johnbillion commentedon Oct 6, 2017
It's worth noting that
WP_User::remove_cap( <role> )also suffers from the same problem. I'm not sure on WP-CLI's policy of improving upon core's APIs in this way.danielbachhuber commentedon Oct 6, 2017
I'm in support of WP-CLI improving upon core's APIs, as long as it's not in opposition to, or diverge too much from, core behavior.
schlessera commentedon Oct 27, 2017
I think it might make sense to skip mismatches with a warning, with a
--forceflag to just execute indiscriminately.However, that would be a BC break...
Issue wp-cli#98 - Added error message when we try to remove capabilit…