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
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.
The text was updated successfully, but these errors were encountered:
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.
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.The text was updated successfully, but these errors were encountered: