Discoverability for fourth level commands provided by plugins - #642

Another option would be to split the event subcommands into a separate top-level command, which will give you:

wp crontrol-event list and wp crontrol-event delete

Coincidentally enough, I've been meaning to open a discussion on the same exact topic.

We have the same need for https://github.com/humanmade/wp-cli-remote-command, which currently has commands like:

• wp remote site-list
• wp remote plugin-install
• wp remote theme-activate

I don't have a good technical recommendation on how to achieve this. The primary value in my mind is usability.

On a similar note, it would be nice to be able to manually sort the order of appearance for subcommands, instead of alphabetical.

From an API perspective, it could be as simple as:

WP_CLI::add_command( 'crontrol event', 'CrontrolEventCommand' );

Note that this would also open the door for attaching additional subcommands to built-in commands:

class PluginGithubCommand extends WP_CLI_Command {

  function __invoke( $args, $assoc_args ) {
    // Do it.
  }
}

WP_CLI::add_command( 'plugin install-github', 'PluginGithubCommand' );

Functional prototype time!

I've changed the internals of find_command_to_run(), and subsequently find_command(), such that WP-CLI traverses up the branch of a perceived command tree, instead of down the branch.

With a command like wp remote option get blogname, WP-CLI will look for commands named:

1. wp remote option get blogname
2. wp remote option get
3. wp remote option
4. wp remote

As far as I can tell (and what the tests can tell me), this doesn't break the internals.

There's one side effect though: If none of those commands are registered, then our error reporting gets a little wonky (strongly related to #782). I can't think of a good way to detect whether your mistyped command correlates with a top-level command, second-level command, third-level command, etc., so I changed the behavior to this for now:

salty-wordpress ➜  wordpress-trunk.dev  wp apples
Error: 'apples' is not a registered wp command. See 'wp help'.
salty-wordpress ➜  wordpress-trunk.dev  wp remote apples
Error: 'remote apples' is not a registered wp command. See 'wp help'.
salty-wordpress ➜  wordpress-trunk.dev  wp remote apples banana
Error: 'remote apples banana' is not a registered wp command. See 'wp help'. 

Open questions:

• If I have CompositeCommand wp option, should I be able to register CompositeCommand wp option get?
• Similarly, if I have CompositeCommand wp remote option, should someone should be able to register CompositeCommand wp remote?
• Do we want to support fifth- and sixth-level commands?
• If I do wp remote and there's no command registered at that level, should it list registered commands the next level down? How should our usage indicators change with multi-level command support?

First of all, let's set some ground rules:

1. A command is either concrete (i.e. it actually does something), or it's a container for other commands; never both. That means we should not allow wp search-replace remote, because wp search-replace is a concrete command that accepts a positional parameter.
2. Once a concrete command is registered, it shouldn't be possible to overwrite it later. WP_CLI::add_command() should throw a warning that the command is already registered.

If I have CompositeCommand wp option, should I be able to register CompositeCommand wp option get?

Yes, regardless if wp option get is a CompositeCommand or a concrete command.

Do we want to support fifth- and sixth-level commands?

I don't see why not.

If I do wp remote and there's no command registered at that level, should it list registered commands the next level down?

Yes, even if there's no description. Or maybe we need a new method for adding descriptions to containers.

Similarly, if I have CompositeCommand wp remote option, should someone should be able to register CompositeCommand wp remote?

I think this is the trickiest question. TBD

With a command like wp remote option get blogname, WP-CLI will look for commands named:

wp remote option get blogname
wp remote option get
wp remote option
wp remote

So, if I pass a thousand IDs to wp post delete, it will do 1002 command lookups?

So, if I pass a thousand IDs to wp post delete, it will do 1002 command lookups?

Yeah. Other ideas?

Well, the other idea would be to descend from the root command, as it's currently done.

Just wanted to update that this is on my radar again. I'd like for it to go out when the package command goes out, as they compliment each other nicely.

Taking a stab at this.

With #1005 landed, you can now do this:

WP_CLI::add_command( 'crontrol event', 'Control_Events_Command' );

Bash completions will be overhauled in #212.