Executing any wp db CLI command causes the error message
[ERROR] unknown option ‘–defaults’
Troubleshooting Questions
Does this happen for all sites in Local, or just one in particular?
yes
Are you able to create a new, plain WordPress site in Local and access it in a Browser?
yes, but doesn’t matter
Replication
Start any page
open shell by right click => ‘Open Site Shell’
type in wp db repair or wp db check (or any other dbcommand)
System Details
Which version of Local is being used?
5.9.7+5156 (latest)
What Operating System (OS) and OS version is being used?
macOS Catalina
Which CLI info do you have?
WP-CLI: WP-CLI 2.5.0-alpha
Composer: 1.10.8 2020-06-24
PHP: 7.4.1
MySQL: mysql Ver 14.14 Distrib 5.7.28, for macos10.14 (x86_64) using EditLine wrapper
Gotcha – I was able to replicate the error you were encountering by downloading the 2.4.0 version of WPCLI and using that.
I know that in the past, I’ve had some issues where using oh-my-zsh would make it so Local’s wp-cli version wasn’t being applied more specifically than a manually added PATH like ~/bin
I found the “defaults” in /Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/config.yaml.
Once disabled the error is gone. The site is working too so I wonder if this settings is necessary at all.
All “wp db” commands that support the defaults flag should use it. Without this, MYSQL_HOME will not be respected and the wp db commands will not be able to interface with Local site databases.
- from config.yaml
not sure what that means but it seams the --default flag somehow get passed through mysql binaries.
The actual --defaults flag was introduced to wpcli in this pull request:
so that wpcli can use environment specific configuration (for example a custom MySQL socket)
Since each Local site is a separate MySQL instance, they don’t share the same default MySQL installation, and therefore don’t have the same default socket (/tmp/mysql.sock)
I’m curious to know how these commands are working on your machine without the --defaults flag. Do you have another offline dev tool or have manually installed MySQL using something like Brew?
It’s possible that the wp db command is working, but instead of working on the Local site, it’s working against the MySQL database that’s located at the default socket location. Does that make sense?
I have only a WP CLI installed as explained on the offical page. Since Local uses sockets I’ve adjusted DB_HOST for that in my wp-config.php:
if ( defined( 'WP_CLI' ) && WP_CLI ) {
//use the socket on CLI
define( 'DB_HOST', 'localhost:/Users/Xaver/Library/Application Support/Local/run/xC4M_uqBn/mysql/mysqld.sock' );
}
otherwise I would get
mysqlcheck: Got error: 1045: Access denied for user ‘root’@‘localhost’ (using password: YES) when trying to connect
on a wp db command.
Another thing I notice - but I think it’s not related - are some PHP warnings I only get when I run the command on the Local Shell but not in a regular shell:
Warning: Invalid argument supplied for foreach() in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php on line 426
Warning: array_merge(): Expected parameter 2 to be an array, string given in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php on line 365
Warning: array_merge(): Expected parameter 1 to be an array, string given in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php on line 451
so even from the Local shell my own wp is used.
Since I define the socket within the wp-config.php I doubt that. Also wp option get home returns the correct URL.
I tried to replicate running wpcli commands using a system installed version of WPCLI and I never was able to get the same results.
I’d recommend using the bundled version of wpcli from within the shell that’s created with “Open Site Shell” since that reduces the complexity of this greatly.
As for the PHP errors, I wonder if there’s an issue with the DB_HOST that’s set in the wp-config.php file – namely the space between Application and Support
Thanks for all your efforts on this, I really appreciate it.
Escaping the space in DB_HOST makes my scripts break so I guess this not the problem.
I also think that my initial problem is not related to the thread topic and since this has been resolved for me and I may open a new topic once I have some specific questions.
I have a custom plugin which relies on WP CLI to manage my development site. It worked flawless with Local 3.x but I finally switched over to the latest release (which is blazing fast btw) and try to get it working with it.
I think we should stop this here as the initial topic has been resolved and other problems are not directly related to this.