Fails when WordPress is in a subdirectory

[aaemnnosttv]

E.g. Using Bedrock

Vanilla WP

Any ideas why this command would work differently than others?

[danielbachhuber]

No idea why it's not working. Here are some debugging questions:

• Do other WP-CLI commands work for your Bedrock install?
• Can you share what you see when you run wp db ack world --debug?

[aaemnnosttv]

Do other WP-CLI commands work for your Bedrock install?

Yep!

Debug output:

wp db ack world --debug
Debug (bootstrap): Using default global config: /Users/aaemnnosttv/.wp-cli/config.yml (0.053s)
Debug (bootstrap): Using project config: /Users/aaemnnosttv/Code/Roots/bedrock/wp-cli.yml (0.055s)
Debug (bootstrap): Loading packages from: /Users/aaemnnosttv/.wp-cli/packages/vendor/autoload.php (0.067s)
Debug (bootstrap): Required file from config: /Users/aaemnnosttv/.wp-cli/commands/wp site create-many.php (0.076s)
Debug (bootstrap): ABSPATH defined: /Users/aaemnnosttv/Code/Roots/bedrock/web/wp/ (0.076s)
Debug (bootstrap): Running command: db ack (0.079s)
Debug (bootstrap): Begin WordPress load (0.085s)
Debug (bootstrap): wp-config.php path: /Users/aaemnnosttv/Code/Roots/bedrock/web/wp-config.php (0.085s)
PHP Notice:  Undefined variable: table_prefix in /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/wp-settings-cli.php on line 131
PHP Stack trace:
PHP   1. {main}() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/boot-fs.php:0
PHP   2. include() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/boot-fs.php:17
PHP   3. WP_CLI\Runner->start() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/wp-cli.php:21
PHP   4. WP_CLI\Runner->_run_command() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Runner.php:907
PHP   5. WP_CLI\Runner->run_command() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Runner.php:323
PHP   6. WP_CLI\Dispatcher\Subcommand->invoke() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Runner.php:316
PHP   7. call_user_func:{/Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:390}() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:390
PHP   8. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:390
PHP   9. call_user_func:{/Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67}() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67
PHP  10. Run_DB_Ack_Command->__invoke() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67
PHP  11. WP_CLI\Runner->load_wordpress() /Users/aaemnnosttv/.wp-cli/packages/vendor/runcommand/db-ack/command.php:73
PHP  12. require() /Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Runner.php:1014
Error: The site you have requested is not installed.
Run `wp core install`.

Didn't notice this error before, but that explains why it thinks WP is not installed.

[danielbachhuber]

Hm, it shouldn't be hitting wp-settings-cli.php. Which version of WordPress is this?

[aaemnnosttv]

Ah, this was an older test install and hadn't been updated for a while. It was running 4.5.2.

After updating to 4.7.3, I'm getting the same error, from a different file:

PHP Notice:  Undefined variable: table_prefix in /Users/aaemnnosttv/Code/Roots/bedrock/web/wp/wp-settings.php on line 110

Still getting this

Error: The site you have requested is not installed.
Run `wp core install`.

[danielbachhuber]

Is $table_prefix defined in your wp-config.php ?

And, to confirm, the site loads properly in your browser?

[aaemnnosttv]

The site does load in the browser just fine.

Bedrock sets the $table_prefix in the config/application.php file which is loaded by wp-config.php. https://github.com/roots/bedrock/blob/master/config/application.php#L57

If the database config was a problem, I would expect that I should not be able to run commands like this:

wp post list
+----+--------------+-------------+---------------------+-------------+
| ID | post_title   | post_name   | post_date           | post_status |
+----+--------------+-------------+---------------------+-------------+
| 1  | Hello world! | hello-world | 2016-05-25 22:15:48 | publish     |
+----+--------------+-------------+---------------------+-------------+

[danielbachhuber]

Huh. Not sure what the issue is then without being able to debug further.

Btw, this will eventually land in wp db proper wp-cli/db-command#7

[fullyint]

I came across the error messages above using wp db search (also using roots/bedrock: WP in subdir).

For comparison, wp db tables succeeds. If I adjust this condition to also get_wp_config_code() for wp db search, the command succeeds (wp-config loads and I avoid Undefined variable: table_prefix).

I have no familiarity with the wp-cli codebase, but perhaps some wp db * commands could get_wp_config_code() like wp db tables.

💚 Thank you for wp-cli!

[aaemnnosttv]

Nice find @fullyint. I took another look and found the real cause.

It seems as though wp-cli is actually loading the wp-config code twice as you can see from this snippet where I added var_dump(microtime()) into the wp-config.php to test the command wp db search home --debug.

Debug (bootstrap): ABSPATH defined: /Users/aaemnnosttv/Sites/brock/web/wp/ (0.096s)
/Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Runner.php(940) : eval()'d code:9:
string(21) "0.28491600 1505810611"
Debug (bootstrap): Running command: db search (0.1s)
Debug (bootstrap): Begin WordPress load (0.108s)
Debug (bootstrap): wp-config.php path: /Users/aaemnnosttv/Sites/brock/web/wp-config.php (0.108s)
/Users/aaemnnosttv/.wp-cli/core/wp-cli/php/WP_CLI/Runner.php(1020) : eval()'d code:9:
string(21) "0.29391700 1505810611"
Debug (bootstrap): Loaded WordPress (0.252s)

Because Bedrock sets the $table_prefix in its config/application.php file, which is included via require_once in the wp-config.php, the variable is only set the first time, and is undefined for the second eval() since the file is not required a second time.

@danielbachhuber Is this double loading of wp-config necessary?

@fullyint You can modify Bedrock to work with this command by moving the $table_prefix definition into wp-config.php, but it would be nice if this could be solved in wp-cli as well.

diff --git a/config/application.php b/config/application.php
index aecdc8b..9414d30 100644
--- a/config/application.php
+++ b/config/application.php
@@ -54,7 +54,6 @@ define('DB_PASSWORD', env('DB_PASSWORD'));
 define('DB_HOST', env('DB_HOST') ?: 'localhost');
 define('DB_CHARSET', 'utf8mb4');
 define('DB_COLLATE', '');
-$table_prefix = env('DB_PREFIX') ?: 'wp_';
 
 /**
  * Authentication Unique Keys and Salts
diff --git a/web/wp-config.php b/web/wp-config.php
index b53a2e7..ca9d7eb 100644
--- a/web/wp-config.php
+++ b/web/wp-config.php
@@ -6,4 +6,5 @@
  */
 require_once(dirname(__DIR__) . '/vendor/autoload.php');
 require_once(dirname(__DIR__) . '/config/application.php');
+$table_prefix = env('DB_PREFIX') ?: 'wp_';
 require_once(ABSPATH . 'wp-settings.php');

[danielbachhuber]

Because Bedrock sets the $table_prefix in its config/application.php file, which is included via require_once in the wp-config.php, the variable is only set the first time, and is undefined for the second eval() since the file is not required a second time.

Can Bedrock use require instead of require_once ?

Is this double loading of wp-config necessary?

Right now, yes, but it is a bit of a hack.

wp db search (and other wp db * commands) call @WP_CLI::get_runner()->load_wordpress(); because WP-CLI executes wp db * commands after wp-config.php has loaded but before the rest of WordPress has loaded: https://github.com/wp-cli/wp-cli/blob/d9d405a4ca01ba23e80277b8cb9000857e84e0cd/php/WP_CLI/Runner.php#L875

Related wp-cli/db-command#15

I'm open to eventually changing this, but no set timeline for doing so. wp-cli/db-command#50

[danielbachhuber]

Also, glad you were able to figure out an interim fix :)

[aaemnnosttv]

Can Bedrock use require instead of require_once?

Changing the require_once statements in wp-config.php to require does fix it as well.

I'm not very confident that the Roots group would accept this change though as it isn't really addressing a problem with Bedrock. Perhaps I'll suggest. In the meantime, this isn't too bad.