Not possible to add subcommand for db

[tyrann0us]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

Adding a custom subcommand of a native command with WP_CLI::add_command() works fine, except at least for the db command.

Describe how other contributors can replicate this bug

1. create a custom command
2. register it as a subcommand to the db command (see code snippet below)
3. see the error message

Adding a subcommand for core:

WP_CLI::add_command(
    'core foo', static function () {
        WP_CLI::success('foo');
    }
);
// Success: foo

Adding a subcommand for db:

WP_CLI::add_command(
    'db foo', static function () {
        WP_CLI::success('foo');
    }
);
// Error: 'foo' is not a registered subcommand of 'db'. See 'wp help db' for available subcommand.

Describe what you expect as the correct outcome

The subcommand works, outputting "Success: foo".

Let us know what environment you are running this on

OS:     Linux 5.10.109-0-virt #1-Alpine SMP Mon, 28 Mar 2022 11:20:52 +0000 x86_64
Shell:  
PHP binary:     /usr/bin/php8.0
PHP version:    8.0.24
php.ini used:   /etc/php/8.0/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 15.1 Distrib 10.5.15-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper
SQL modes:      STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /var/www/html
WP-CLI packages dir:    /home/[redacted]/.wp-cli/packages/
WP-CLI cache dir:       /home/[redacted]/.wp-cli/cache
WP-CLI global config:   
WP-CLI project config:  /var/www/html/wp-cli.yml
WP-CLI version: 2.7.1

(This is DDEV v1.21.2 on macOS 11.7.)

Provide additional context/screenshots
I haven't tested all native commands if adding subcommands works.

[danielbachhuber]

Thanks for the report, @tyrann0us !

Adding a custom subcommand of a native command with WP_CLI::add_command() works fine, except at least for the db command.

This seems to work for me:

$ cat test-db-command.php
<?php

WP_CLI::add_command(
    'db foo', static function () {
        WP_CLI::success('foo');
    }
);
$ wp --require=test-db-command.php db foo
Success: foo

How are you calling the file with your db foo command? The entire DB_Command class runs on after_wp_config_load, so you'd need to make sure your subcommand is registered before that:

https://github.com/wp-cli/db-command/blob/210ebcca1f28275d61c6a248a94da86d566ef9dd/src/DB_Command.php#L26-L28

[tyrann0us]

Hi @danielbachhuber, thanks for getting back to me.

How are you calling the file with your db foo command?

For testing purposes, I had wrapped the command in a plugin (basically just the PHP class with a plugin header on top of it, living in wp-content/plugins). So the WP_CLI::add_command() command was executed without any hooks like plugins_loaded or init. If I have to guess, that was the issue.
The reason I did this is that I was unaware of the --require flag; using it instead of the plugin wrapper works just fine.

I can't judge whether the differences in adding subcommands to e.g. core vs. db is something you would consider a bug, so I'll leave it up to you to close this issue or not.

Thanks!

[schlessera]

@tyrann0us With issues like this, it is usually a matter of timing. If you use the --debug flag, you should be able to see what commands are being registered at what time, and when WP-CLI tries to attach subcommands to missing parent commands.

Also, given that the db commands in general are meant to be run without actually loading WordPress (it might not be in a working state if you require direct DB manipulations), it does not make much sense to add subcommands to it within plugins. So, when you're trying to launch db foo, no plugins have been triggered yet. A WP-CLI package would be better in this case, as it exists independently of WordPress.

[schlessera]

I'm closing this, as I assume it works as expected. Feel free to reopn, @tyrann0us, incase you still think there is something off.