[ERROR] unknown option '--defaults'

Issue Summary

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


  1. Start any page
  2. open shell by right click => ‘Open Site Shell’
  3. 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

Thanks for creating this topic! I just tried replicating on my Mac and I’m able to run those commands.

The option --defaults is a WPCLI option so that it will use the configuration options provided by Local.

I wonder if there’s another version of WPCLI that’s being used by the terminal. What do you get when you issue which wp in the terminal?

When I run that command within a shell opened by Local, I get something like:

$ which wp

Hi Ben!

Thanks for getting back, and thanks for the hint. Im actually running a different version which is at ~/bin/wp

Running the command

/Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/posix/wp db check

is working just fine :slight_smile:

I’ll do some further tests and will post my progress here. Thanks for the hint!

1 Like

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’m using oh-my-zsh as well and encounter following:

my wp binary is in /usr/local/bin/and which wp reveals this path. When I delete this file I get

wp not found

on a regular shell and


On a shell opened from the context menu in Local

But my initial problem is most likely not related to that.


wp db tables => works
wp db check => unknown option error

I notices both environments uses the same wp-config.php but there’s different output with wp cli info

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 --defaults flag is something to tell wpcli to use the default MySQL configuration of the environment.

You can get an idea of the configuration within the terminal environment by cating the shell script that is run:

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

...Library/Application Support/Local/run...

Hi Ben!

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.

Thanks again for your time Ben.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.