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
Describe your use case and the problem you are facing
The context and the problem is defined directly in the commit: a8308bb.
Usually, if you want to use a custom default value for an argument like that, the way to do itis via a wp-cli.yml config file. See https://make.wordpress.org/cli/handbook/references/config/ for an example of how to set default values.
wp-cli.yml is not an option, it requires unnecessary operations, creating the file, deleting the file...
@ton31337 This is just one of many places where directly passing sensitive information can be leaked into the process list or similar, so adding environment variables for these is not really scalable.
As @danielbachhuber mentioned, WP-CLI supports file-based approaches to solve this in a more generic way:
You can put the sensitive information into a configuration file. The file would be a YAML file with the following structure:
core install:
admin_password: 123456
You can then point your WP-CLI execution to a custom location for that file if you generate it dynamically:
You can let WP-CLI require an additional PHP file that gets executed from within the context of WP-CLI. This way, you have full control of the entire execution. You can for example hook into the random_password filter to control what the generated password will be:
<?php// Hook into the WP-CLI process to act when the `wp core install` command is being triggered.WP_CLI::add_hook( 'before_invoke:core install', staticfunction() {
// Compute the admin password in whatever way you want.// This can come from a file, be queried via an API, etc...$admin_password = '123456';
// Hook into the `random_password` filter to return the computed password.WP_CLI::add_wp_hook( 'random_password', staticfunction() use ( $admin_password ) {
return$admin_password;
} );
} );
This can be used via the --require=<path-to-script.php> flag:
wp core install --require=<path/to/script.php>
You can combine approaches and have a custom config (from wherever it comes) to add the --require=<path-to-script.php> to the WP-CLI binary.
The config file would then look like this:
Feature Request
Describe your use case and the problem you are facing
The context and the problem is defined directly in the commit: a8308bb.
wp-cli.yml
is not an option, it requires unnecessary operations, creating the file, deleting the file...Describe the solution you'd like
The solution to the current issue is #261.
The text was updated successfully, but these errors were encountered: