René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Normalise `--rich_editing` and `--syntax_highlighting` on `user update` as `user create` does","articleBody":"Follow-up to #637 (merged as 9408392). That PR made `user create --rich_editing` store what core compares against: `src/User_Command.php:445-446` runs the value through `FILTER_VALIDATE_BOOLEAN` and writes `'true'` or `'false'`. `user update` still hands the raw string to `wp_update_user()` (`src/User_Command.php:601-629`, `parent::_update()` at `:629`), and core stores it as given (`wp-includes/user.php:2514`, `:2516`).\n\nCore reads the two options as string literals:\n\n- `user_can_richedit()` enables the editor only when the stored value is exactly `'true'` (`wp-includes/general-template.php:4200`). So `wp user update 5 --rich_editing=1` disables the visual editor for that user.\n- The code editor is switched off only when the stored value is exactly `'false'` (`general-template.php:4317`). So `wp user update 5 --syntax_highlighting=0` leaves syntax highlighting on.\n\nBoth flags report `Success:` either way. The docblocks at `src/User_Command.php:546-552` say \"'true' or 'false' as a string literal, not boolean\", which is accurate, but a flag that accepts `1` and `0` on `create` and silently inverts or ignores them on `update` is a trap.\n\nDone looks like: `update()` normalises `rich_editing` and `syntax_highlighting` the way `create()` does before calling `parent::_update()`, the two docblocks say the same as the `create` one (`'true'`/`'false'` or `1`/`0`), and `features/user.feature` has a scenario for each flag on `user update` with a numeric value. Same handling for `syntax_highlighting` on `create` while at it, since `create` does not touch it today.","author":{"url":"https://github.com/schlessera","@type":"Person","name":"schlessera"},"datePublished":"2026-09-14T19:06:36Z","url":"https://github.com/wp-cli/entity-command/issues/656"}