Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read admin_password from the environment by default #262

Open
1 task done
ton31337 opened this issue May 31, 2024 · 1 comment
Open
1 task done

Read admin_password from the environment by default #262

ton31337 opened this issue May 31, 2024 · 1 comment

Comments

@ton31337
Copy link

ton31337 commented May 31, 2024

Feature Request

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...

Describe the solution you'd like

The solution to the current issue is #261.

@schlessera
Copy link
Member

schlessera commented Aug 7, 2024

Copied over from #261 :

@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:

  1. 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:
    WP_CLI_CONFIG_PATH=/path/to/custom/wp-cli.yml wp core install
  2. 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', static function() {
    
        // 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', static function() 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>
  3. 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:
    require:
        - path/to/script.php

More detailed documentation about:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants