Skip to content

Allow registration of custom global arguments #5649

@danielbachhuber

Description

@danielbachhuber

On WordPress.com, we'd like to add --blog_id=<id> as a global argument. WordPress.com has all sorts domain transformation logic in a long sunrise.php so, in certain cases, it would be more reliable to pass a specific --blog_id=<id> argument.

The idea was originally discussed in #854 (comment)

Because --blog_id=<id> still requires some blog id -> URL lookup, I'm still not convinced it's something WP-CLI should be responsible for. However, third-party code (via sunrise.php or similar) could easily perform this logic, so it would be nice if it was possible to register --blog_id=<id> as a global argument.

A couple of ideas:

  1. Have some form of filtering mechanism for the return values of WP_CLI::get_configurator():
    public static function get_configurator() {
    static $configurator;
    if ( ! $configurator ) {
    $configurator = new Configurator( WP_CLI_ROOT . '/php/config-spec.php' );
    }
    return $configurator;
    }
  2. Allow a custom path to be defined for config-spec.php:
    $configurator = new Configurator( WP_CLI_ROOT . '/php/config-spec.php' );

I kind of like the second option, which would give the environment control over which global arguments were available. I'm not sure what breaks when you remove one, though.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions