Fix --defaults flag issue in SQL mode discovery for db query commands

[Copilot]

The --defaults flag was being incorrectly ignored during SQL mode discovery, causing commands like wp db query "SELECT 1;" --defaults to fail with MySQL connection errors.

Problem

When using the --defaults flag with wp db query, the command would fail during SQL mode discovery with an error like:

Error: Failed to get current SQL modes. Reason: '"mysql --no-defaults --no-auto-rehash --batch --skip-column-names --execute="SELECT' is not recognized as an internal or external command

Root Cause

The issue occurred because get_defaults_flag_string() modifies the $assoc_args array by reference, removing the 'defaults' key after processing it. This caused a sequence problem:

1. Main query command calls get_defaults_flag_string($assoc_args) → returns empty string (correct), removes 'defaults' key
2. SQL mode discovery calls get_sql_mode_query($assoc_args) → internally calls get_defaults_flag_string($assoc_args) again
3. Second call can't find 'defaults' key → incorrectly returns --no-defaults flag
4. SQL mode discovery query fails because it uses --no-defaults when user specified --defaults

Solution

Preserve the original $assoc_args before the first call to get_defaults_flag_string() and pass the original arguments to get_sql_mode_query():

// Preserve the original defaults flag value before get_defaults_flag_string modifies $assoc_args
$original_assoc_args_for_sql_mode = $assoc_args;

$command = sprintf(
    '/usr/bin/env %s%s --no-auto-rehash',
    $this->get_mysql_command(),
    $this->get_defaults_flag_string( $assoc_args )  // Modifies $assoc_args
);

// Use original args for SQL mode discovery
$assoc_args['execute'] = $this->get_sql_mode_query( $original_assoc_args_for_sql_mode ) . $assoc_args['execute'];

Changes Made

• Fixed the issue in three methods that had the same pattern: query(), import(), and run_query()
• Added test case to verify SQL mode discovery respects the --defaults flag
• Minimal change: only 22 insertions, 3 deletions across 2 files

Testing

Added a new test scenario in features/db-query.feature:

Scenario: SQL mode discovery respects --defaults flag
  Given a WP install

  When I try `wp db query "SELECT 1;" --defaults --debug`
  Then STDERR should match #Running shell command: /usr/bin/env (mysql|mariadb) --no-auto-rehash#
  And STDERR should not match #Running shell command: /usr/bin/env (mysql|mariadb) --no-defaults#

Fixes #1.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/Behat/Gherkin/zipball/34c9b59c59355a7b4c53b9f041c8dbd1c8acc3b4
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/RCdY1Y /usr/bin/composer install (http block)
• https://api.github.com/repos/php-fig/log/zipball/f16e1d5863e37f8d8c2a01719f5b34baa2b714d3
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/RCdY1Y /usr/bin/composer install (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[lkraav]

This issue is really not related specifically to SQL mode discovery, but rather how wp db query loses any general arguments given to it, such as --defaults, or as another use case example, --ssl-verify-server-cert.

All these args work correctly for wp db cli, so maybe we could explore how wp db query is different and how wp db cli succeeds in managing retaining cmdline args better.

[Copilot]

This issue is really not related specifically to SQL mode discovery, but rather how wp db query loses any general arguments given to it, such as --defaults, or as another use case example, `--ssl-...

You're right that this is a broader architectural issue. The problem is that get_defaults_flag_string() destructively modifies $assoc_args (removes the 'defaults' key), which works fine for simple commands like wp db cli but breaks when commands need multiple operations that each require the same WP-CLI flags.

Looking at the difference:

• wp db cli: Single operation, calls get_defaults_flag_string() once
• wp db query: Multiple operations (main command + SQL mode discovery), both need defaults flag

Would you prefer a solution that makes the flag handling non-destructive across all commands, or should we explore having SQL mode discovery take a different approach that doesn't rely on re-parsing the args? I'm curious what specific architectural change you'd like to see explored.

[lkraav]

Would you prefer a solution that makes the flag handling non-destructive across all commands, or should we explore having SQL mode discovery take a different approach that doesn't rely on re-parsing the args? I'm curious what specific architectural change you'd like to see explored.

Let's try to fix wp db query alone first @copilot

Here's debug output of failure

Debug (bootstrap): Processing bootstrap step: WP_CLI\Bootstrap\RegisterDeferredCommands (0.212s)
Debug (bootstrap): Processing bootstrap step: WP_CLI\Bootstrap\InitializeContexts (0.212s)
Debug (bootstrap): Processing bootstrap step: WP_CLI\Bootstrap\LaunchRunner (0.213s)
Debug (bootstrap): Using default global config: /var/www/cxl.com/.wp-cli/config.yml (0.213s)
Debug (bootstrap): No project config found (0.213s)
Debug (bootstrap): argv: /var/www/cxl.com/.local/bin/wp db query SELECT CURRENT_USER(); --ssl-verify-server-cert --debug (0.213s)
Debug (bootstrap): ABSPATH defined: /var/www/cxl.com/html/institute/ (0.213s)
Debug (hooks): Executing hook: before_wp_load (0.213s)
Debug (context): Using context 'cli' (0.213s)
Debug (bootstrap): Begin WordPress load (0.213s)
Debug (bootstrap): wp-config.php path: /var/www/cxl.com/html/institute/wp-config.php (0.213s)
Debug (bootstrap): Looking for UTF-8 BOM (0.213s)
Debug (bootstrap): Looking for UTF-16 (BE) BOM (0.213s)
Debug (bootstrap): Looking for UTF-16 (LE) BOM (0.213s)
Debug (hooks): Executing hook: after_wp_config_load (0.214s)
Debug (hooks): Processing hook "before_run_command" with 1 callbacks (0.214s)
Debug (hooks): On hook "before_run_command": WP_CLI\Bootstrap\RegisterDeferredCommands->add_deferred_commands() (0.214s)
Debug (bootstrap): Running command: db query (0.214s)
Debug (db): Running shell command: /usr/bin/env mariadb --no-auto-rehash (0.238s)
Debug (db): Final MySQL command: /usr/bin/env mariadb --no-defaults --no-auto-rehash --batch --skip-column-names --host='dbpgf00000000.sysp0000.db2.skysql.com' --user='dbpgf00000000' --default-character-set='utf8' --execute='SELECT @@SESSION.sql_mode' (0.238s)
Error: Failed to get current SQL modes. Reason: ERROR 1045 (28000): Access denied for user 'dbpgf00000000'@'1.2.3.4' (using password: YES)

[Copilot]

Would you prefer a solution that makes the flag handling non-destructive across all commands, or should we explore having SQL mode discovery take a different approach that doesn't rely on re-parsing...

You're right, the issue is broader than just the --defaults flag. The real problem is in get_current_sql_modes() method where it has an empty foreach loop that's supposed to preserve MySQL arguments but doesn't preserve any. This causes SQL mode discovery to lose connection arguments like --ssl-verify-server-cert. I'll fix this to properly preserve all valid MySQL arguments.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/wp-cli/mustache.php/zipball/ca23b97ac35fbe01c160549eb634396183d04a59
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/9r4PIF /usr/bin/composer install --no-dev (http block)
• https://api.github.com/repos/wp-cli/spyc/zipball/6aa0b4da69ce9e9a2c8402dab8d43cf32c581cc7
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/9r4PIF /usr/bin/composer install --no-dev (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list