Fix global runtime parameters rejected as "unknown" when used with an alias#6299
Fix global runtime parameters rejected as "unknown" when used with an alias#6299
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
When an alias config defines a key (e.g. url, path, user) and the user also passes the same key as a CLI arg (e.g. --url), the old code incorrectly put the CLI arg value into $this->assoc_args (command-specific args). This caused validate_args() to reject it as "unknown". Fix: after merging alias config into $this->config, re-apply $this->runtime_config so CLI args always take precedence over alias config. This keeps global runtime params out of $this->assoc_args entirely. Update aliases.feature tests to reflect correct behavior. Agent-Logs-Url: https://github.com/wp-cli/wp-cli/sessions/ee2041b2-bb20-4641-a81c-2f228b4e9136 Co-authored-by: swissspidy <[email protected]>
There was a problem hiding this comment.
Pull request overview
Fixes WP-CLI alias handling so global runtime parameters (e.g. --url, --path, --user) are no longer rejected as “unknown” when the active alias also defines those keys.
Changes:
- Reworked
Runner::set_alias()so CLI-provided runtime args take precedence over alias-defined config, and removed mutation of command assoc args. - Updated alias Behat scenarios to assert success (and correct output) when global params are passed alongside alias-defined params.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
php/WP_CLI/Runner.php |
Adjusts alias config application order to avoid misclassifying global runtime params as command params. |
features/aliases.feature |
Updates scenarios to validate that --path, --user, and --url work correctly with aliases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Merge alias config into the current config, then re-apply CLI runtime args so they | ||
| // always take precedence over values defined in the alias. | ||
| $this->config = array_merge( $this->config, $alias_config ); | ||
| foreach ( $this->runtime_config as $key => $value ) { |
There was a problem hiding this comment.
set_alias() reapplies all $this->runtime_config keys onto $this->config. This can unintentionally clobber runtime+file merged values for multi-value runtime params (notably require): Configurator::merge_array() appends runtime --require entries onto config/env requires, but this loop would overwrite config['require'] with only the runtime value when an alias is used, causing config/env required files to be skipped. Consider only restoring runtime keys that the alias merge could have overridden (e.g. intersection of $alias_config keys with $this->runtime_config), or otherwise preserve merge semantics for multi-value keys like require.
| // Merge alias config into the current config, then re-apply CLI runtime args so they | |
| // always take precedence over values defined in the alias. | |
| $this->config = array_merge( $this->config, $alias_config ); | |
| foreach ( $this->runtime_config as $key => $value ) { | |
| // Merge alias config into the current config, then re-apply CLI runtime args only for | |
| // keys overridden by the alias so runtime values still take precedence without | |
| // clobbering merged config values for unrelated multi-value options such as `require`. | |
| $this->config = array_merge( $this->config, $alias_config ); | |
| foreach ( array_intersect_key( $this->runtime_config, $alias_config ) as $key => $value ) { |
When an alias defines a config key (e.g.
url,path,user) and the user passes the same key as a CLI flag, WP-CLI incorrectly rejects the flag as an unknown command parameter:Root cause
Runner::set_alias()had two bugs:array_merge($orig_config, $alias_config)let the alias override CLI-provided runtime values$this->assoc_args(command-specific args) — causingvalidate_args()to reject it as an unknown parameter sinceurl/path/userare global runtime params, not command paramsChanges
php/WP_CLI/Runner.php— Rewroteset_alias(): merge alias config into$this->configas before, then re-apply$this->runtime_configso CLI args always win. Removed the incorrect$this->assoc_argsmutation entirely.features/aliases.feature— Updated three scenarios that asserted the (buggy) rejection behavior:wp @foo option get home --path=foo→ now expected to succeedwp @foo eval "..." --user=admin(when alias also setsuser) → now expected to succeedwp @subsite option get siteurl --url=http://subsite.example.com→ now expected to return the siteurlWarning
Firewall rules blocked me from connecting to one or more addresses (expand for details)
I tried to connect to the following addresses, but was blocked by firewall rules:
example.com/usr/bin/php php vendor/bin/phpunit --color=always --bootstrap ./vendor/wp-cli/wp-cli-tests/tests/bootstrap.php '-d short_open_tag=Off' '-d error_reporting=E_ALL' '-n' '-l' './php/WP_CLI/Bootstrap/DefineProtesh(dns block)nosuchhost_asdf_asdf_asdf.com/usr/bin/php php vendor/bin/phpunit --color=always --bootstrap ./vendor/wp-cli/wp-cli-tests/tests/bootstrap.php '-d short_open_tag=Off' '-d error_reporting=E_ALL' '-n' '-l' './php/WP_CLI/Bootstrap/DefineProtesh(dns block)If you need me to access, download, or install something from one of these locations, you can either: