entity-command
entity-command copied to clipboard
Updating a user with an invalid role should fail
The following command always succeeds. Ideally it should fail when an invalid role name is passed.
wp user update <username> --role=bananas
Thanks for the report, @johnbillion. Some follow-up questions (thinking aloud, not necessarily for you):
- Is there a valid use case for assigning an invalid role to a user?
- Would there be backwards compatibility concerns in changing the current behavior?
- Is there other prior art within WP-CLI where we've changed user input validation similarly?
Idea that addresses 1 and 2: Trigger a warning instead of erroring.
Does core error when updating a user with an invalid role?
This is an interesting but old thread, that addresses a question I had. And doesn't seem to be addressed elsewhere.
Although there are validation checks in core creating a new user, e.g. for the email address, there do not appear to be checks on role. It is entirely valid for users to have no role, but there does not seem to be any restriction about having a role that's not in the database. Removing a role from the database does not seem to remove it from the users, so conversely, one might create users with a certain role, then later create the role to grant capabilities.
Relevant code:
User https://core.trac.wordpress.org/browser/tags/5.3/src/wp-includes/user.php
WP-User https://core.trac.wordpress.org/browser/tags/5.3/src/wp-includes/class-wp-user.php
Roles https://core.trac.wordpress.org/browser/tags/5.3/src/wp-includes/class-wp-roles.php
@johnbillion Still think we should implement this? If so, I'm good with it.
It is unusual (or not?) that WP core doesn't validate the role, but I think there's value in doing so in WP-CLI. +1 for accepting the role but triggering a warning, which means if you're creating a user interactively and you typo the role then at least you'll see a warning.
Right now entering the invalid URL will give a warning than a success message and in the WordPress dashboard the role will be changed to none