Add `wp db status` command for database health overview #307

Copilot · 2026-02-01T16:05:09Z

Adds single command to retrieve database health and configuration info, consolidating what previously required running wp db size, wp db tables, wp db prefix, and wp db check separately.

Implementation

New status() method in DB_Command class
- Queries information_schema.TABLES for size, engine, charset, collation
- Detects mixed engines/charsets/collations across tables
- Runs mysqlcheck for health status
- Formats output as aligned key-value pairs
- Supports --dbuser, --dbpass, and --defaults options for authentication
Command registration in composer.json
Behat test coverage for output validation and credential options

Output

Database Name:     wp_cli_test
Tables:            54
Total Size:        312 KB
Prefix:            wp_
Engine:            InnoDB
Charset:           utf8mb4
Collation:         utf8mb4_unicode_ci
Check Status:      OK

Notes

Uses SI units (1000-based) for size formatting, matching existing wp db size --human-readable behavior
Handles edge cases: zero/null size, missing tables, check failures, mixed engines/charsets/collations
Works without loading WordPress (@when before_wp_load), suitable for automation and use before WordPress is installed
Supports standard database authentication options (--dbuser, --dbpass, --defaults) for consistency with other db commands

Original prompt

This section details on the original issue you should resolve

<issue_title>Add wp db status command for quick database health overview</issue_title>
<issue_description>I would like to suggesta new WP-CLI command: wp db status

The command would provide a concise, read-only overview of the current WordPress database health and configuration in a single output, reducing the need to run multiple separate commands.

For support, debugging, and hosting diagnostics, it would be beneficial to have a single, non-destructive command that aggregates key database information into one quick report.

Currently, checking database status requires running several commands such as: wp db size, wp db tables, wp db prefix, wp db check, etc.

My Proposed Command:

wp db status

Output Example:
Database Name:     wp_mehrazmorshed
Tables:            54
Total Size:        312 MB
Prefix:            wp_
Engine:            InnoDB
Charset:           utf8mb4
Collation:         utf8mb4_unicode_ci
Check Status:      OK
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
<comment_new><author>@ernilambar</author><body>
It will be included in next "3.0.0" version.</body></comment_new>
<comment_new><author>@swissspidy</author><body>
Yeah you can already try it out in the nightly release.

One difference is that the site-health command involves loading WordPress, whereas the db commands usually also work when WordPress is not even installed yet.</body></comment_new>
<comment_new><author>@ernilambar</author><body>
Although database info is available from "site-health" command I am positive is adding specific db command which gives info without loading whole WordPress. It would be helpful in scripting.</body></comment_new>
</comments>

Fixes Add wp db status command for quick database health overview #306

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

codecov · 2026-02-01T16:21:17Z

Codecov Report

❌ Patch coverage is 98.03922% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/DB_Command.php	98.03%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

swissspidy · 2026-02-02T01:50:25Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a new wp db status command, which provides a convenient overview of the database's health and configuration. The implementation is solid and consolidates information from several other commands. My review focuses on improving the new Behat tests for better robustness and refactoring parts of the new status() method to enhance code clarity, reduce duplication, and improve maintainability.

gemini-code-assist · 2026-02-02T01:52:18Z

features/db-status.feature

+  Scenario: Display database status for a WordPress install
+    Given a WP install
+
+    When I run `wp db status`
+    Then STDOUT should contain:
+      """
+      Database Name:
+      """
+    And STDOUT should contain:
+      """
+      Tables:
+      """
+    And STDOUT should contain:
+      """
+      Total Size:
+      """
+    And STDOUT should contain:
+      """
+      Prefix:            wp_
+      """
+    And STDOUT should contain:
+      """
+      Engine:
+      """
+    And STDOUT should contain:
+      """
+      Charset:
+      """
+    And STDOUT should contain:
+      """
+      Collation:
+      """
+    And STDOUT should contain:
+      """
+      Check Status:
+      """
+
+  Scenario: Verify database status shows correct database name
+    Given a WP install
+
+    When I run `wp db status`
+    Then STDOUT should contain:
+      """
+      wp_cli_test
+      """
+
+  Scenario: Verify database status shows check status as OK
+    Given a WP install
+
+    When I run `wp db status`
+    Then STDOUT should contain:
+      """
+      Check Status:      OK
+      """


The Behat tests are split across multiple scenarios, each testing a small part of the command's output. This makes the tests less robust as they don't verify the output structure as a whole. Combining these into a single, more comprehensive scenario would improve test clarity and strength. Using should match with regular expressions for dynamic values like table count and size will also make the assertions more precise and resilient to minor changes.

Scenario: Display database status for a WordPress install Given a WP install When I run `wp db status` Then STDOUT should contain: """ Database Name: wp_cli_test """ And STDOUT should match /^Tables:\s+\d+$/m And STDOUT should match /^Total Size:\s+[\d.]+ \wB$/m And STDOUT should contain: """ Prefix: wp_ """ And STDOUT should match /^Engine:\s+\w+$/m And STDOUT should match /^Charset:\s+\w+$/m And STDOUT should match /^Collation:\s+\w+$/m And STDOUT should contain: """ Check Status: OK """

gemini-code-assist · 2026-02-02T01:52:18Z

src/DB_Command.php

+		if ( empty( $db_size_bytes ) || $db_size_bytes <= 0 ) {
+			$db_size = '0 B';
+		} else {
+			$size_key    = floor( log( (float) $db_size_bytes ) / log( 1000 ) );
+			$sizes       = [ 'B', 'KB', 'MB', 'GB', 'TB' ];
+			$size_format = isset( $sizes[ $size_key ] ) ? $sizes[ $size_key ] : $sizes[0];
+			$divisor     = pow( 1000, $size_key );
+			$db_size     = round( (int) $db_size_bytes / $divisor, 2 ) . ' ' . $size_format;
+		}


This block for formatting the database size into a human-readable string is very similar to logic within the size() method. To avoid code duplication and improve maintainability, consider extracting this logic into a private helper function that can be reused in both places. For now, the logic can be slightly simplified for better readability by inverting the conditional and using the null coalescing operator.

if ( ! empty( $db_size_bytes ) && $db_size_bytes > 0 ) { $size_key = floor( log( (float) $db_size_bytes ) / log( 1000 ) ); $sizes = [ 'B', 'KB', 'MB', 'GB', 'TB' ]; $size_format = $sizes[ $size_key ] ?? $sizes[0]; $divisor = pow( 1000, $size_key ); $db_size = round( (int) $db_size_bytes / $divisor, 2 ) . ' ' . $size_format; } else { $db_size = '0 B'; }

gemini-code-assist · 2026-02-02T01:52:19Z

src/DB_Command.php

+		WP_CLI::log( sprintf( '%-18s %s', 'Database Name:', $db_name ) );
+		WP_CLI::log( sprintf( '%-18s %d', 'Tables:', $table_count ) );
+		WP_CLI::log( sprintf( '%-18s %s', 'Total Size:', $db_size ) );
+		WP_CLI::log( sprintf( '%-18s %s', 'Prefix:', $prefix ) );
+		WP_CLI::log( sprintf( '%-18s %s', 'Engine:', $engine ) );
+		WP_CLI::log( sprintf( '%-18s %s', 'Charset:', $charset ) );
+		WP_CLI::log( sprintf( '%-18s %s', 'Collation:', $collation ) );
+		WP_CLI::log( sprintf( '%-18s %s', 'Check Status:', $check_status ) );


The block of WP_CLI::log() calls for outputting the status is repetitive. This can be refactored to be data-driven by storing the status information in an associative array and then iterating over it to generate the output. This approach is more maintainable and makes it easier to add or modify status fields in the future.

$status_items = [ 'Database Name' => $db_name, 'Tables' => $table_count, 'Total Size' => $db_size, 'Prefix' => $prefix, 'Engine' => $engine, 'Charset' => $charset, 'Collation' => $collation, 'Check Status' => $check_status, ]; foreach ( $status_items as $label => $value ) { WP_CLI::log( sprintf( '%-18s %s', $label . ':', $value ) ); }

Copilot

Pull request overview

This PR adds a new wp db status command that provides a consolidated view of database health and configuration information in a single command, eliminating the need to run multiple separate database commands (wp db size, wp db tables, wp db prefix, wp db check).

Changes:

New status() method in DB_Command class that queries database metadata and runs health checks
Command registration in composer.json
Behat test coverage validating output format

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 9 comments.

File	Description
src/DB_Command.php	Implements the `status()` method that retrieves database name, table count, size, prefix, engine, charset, collation, and check status, formatting output as aligned key-value pairs
features/db-status.feature	Adds Behat test scenarios to verify the command outputs all expected fields and displays correct values
composer.json	Registers the new `db status` command in the commands array

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

src/DB_Command.php

Copilot · 2026-02-02T01:55:25Z

features/db-status.feature

+Feature: Display database status overview
+
+  Scenario: Display database status for a WordPress install
+    Given a WP install
+
+    When I run `wp db status`
+    Then STDOUT should contain:
+      """
+      Database Name:
+      """
+    And STDOUT should contain:
+      """
+      Tables:
+      """
+    And STDOUT should contain:
+      """
+      Total Size:
+      """
+    And STDOUT should contain:
+      """
+      Prefix:            wp_
+      """
+    And STDOUT should contain:
+      """
+      Engine:
+      """
+    And STDOUT should contain:
+      """
+      Charset:
+      """
+    And STDOUT should contain:
+      """
+      Collation:
+      """
+    And STDOUT should contain:
+      """
+      Check Status:
+      """
+
+  Scenario: Verify database status shows correct database name
+    Given a WP install
+
+    When I run `wp db status`
+    Then STDOUT should contain:
+      """
+      wp_cli_test
+      """
+
+  Scenario: Verify database status shows check status as OK
+    Given a WP install
+
+    When I run `wp db status`
+    Then STDOUT should contain:
+      """
+      Check Status:      OK
+      """


The test scenarios don't verify that the --dbuser, --dbpass, and --defaults options work with the status command. Looking at similar commands like db check (features/db-check.feature:42-138), these options are tested to ensure they properly override credentials and handle authentication failures. Consider adding test scenarios to verify these parameters work correctly with wp db status, especially since the current implementation has a bug where these parameters aren't being passed through.

Added test scenarios in commit 8a0d032 to verify --dbuser, --dbpass, --defaults, and --no-defaults options work correctly with the status command, including authentication failure cases.

Copilot · 2026-02-02T01:55:25Z

src/DB_Command.php

+		$check_args                          = [];
+		$command                             = sprintf(
+			'/usr/bin/env %s%s %s',
+			Utils\get_sql_check_command(),
+			$this->get_defaults_flag_string( $check_args ),
+			'%s'
+		);
+		list( $stdout, $stderr, $exit_code ) = self::run(
+			Utils\esc_cmd( $command, DB_NAME ),
+			[ 'check' => true ],
+			false
+		);


Empty $check_args array is passed to get_defaults_flag_string(), but this array is never populated with potential dbuser or dbpass parameters that might have been passed to the command. If the status command is invoked with --dbuser or --dbpass options (similar to other db commands like check or optimize), these credentials won't be passed to the mysqlcheck command, causing authentication failures. The status method should accept $assoc_args parameters and pass them through to the check command, similar to how the check() method works at line 252-266.

Fixed in commit 8a0d032. Updated method signature to accept $_ and $assoc_args parameters, and now passes credentials through to the mysqlcheck command via array_merge( [ 'check' => true ], $assoc_args ).

src/DB_Command.php

Copilot · 2026-02-02T01:55:25Z

src/DB_Command.php

+	/**
+	 * Displays a quick database status overview.
+	 *
+	 * Shows key database information including name, table count, size,
+	 * prefix, engine, charset, collation, and health check status. This
+	 * command is useful for getting a quick snapshot of database health
+	 * without needing to run multiple separate commands.
+	 *
+	 * ## EXAMPLES
+	 *
+	 *     $ wp db status
+	 *     Database Name:     wp_cli_test
+	 *     Tables:            54
+	 *     Total Size:        312 KB
+	 *     Prefix:            wp_
+	 *     Engine:            InnoDB
+	 *     Charset:           utf8mb4
+	 *     Collation:         utf8mb4_unicode_ci
+	 *     Check Status:      OK
+	 *


The command documentation should include OPTIONS section documenting the --dbuser, --dbpass, and --defaults parameters that are supported by other database commands. These options are standard across all db commands that interact with MySQL directly (check, optimize, repair, etc.) and users would expect them to work here as well for consistency.

Added OPTIONS section in commit 8a0d032 documenting the --dbuser, --dbpass, and --defaults parameters that are now supported.

Copilot · 2026-02-02T01:55:26Z

src/DB_Command.php

+	 *     Collation:         utf8mb4_unicode_ci
+	 *     Check Status:      OK
+	 *
+	 * @when after_wp_load


There's a discrepancy between the PR description and the code. The PR description states the command "Works without loading WordPress (@when after_wp_load), suitable for automation", but having @when after_wp_load means WordPress DOES get loaded. The statement seems to be backwards. Either the annotation should be removed (to inherit after_wp_config_load from the class level), or the PR description needs correction to accurately reflect that WordPress is loaded.

@copilot apply changes based on this feedback — it should be available before_wp_load

Fixed in commit 8a0d032. Changed @when annotation from after_wp_load to before_wp_load so the command runs before WordPress loads, making it suitable for automation and scripts.

src/DB_Command.php

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Initial plan

970cf3f

Copilot AI assigned Copilot and swissspidy Feb 1, 2026

Copilot started work on behalf of swissspidy February 1, 2026 16:05 View session

Copilot AI and others added 2 commits February 1, 2026 16:10

Add wp db status command implementation

0a6e265

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Fix edge case handling for zero database size

7c06ca3

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Add wp db status command for database health overview~~ Add wp db status command for database health overview Feb 1, 2026

Copilot AI requested a review from swissspidy February 1, 2026 16:13

Copilot finished work on behalf of swissspidy February 1, 2026 16:13

swissspidy requested a review from Copilot February 2, 2026 01:50

Copilot started reviewing on behalf of swissspidy February 2, 2026 01:50 View session

gemini-code-assist bot reviewed Feb 2, 2026

View reviewed changes

Copilot AI reviewed Feb 2, 2026

View reviewed changes

swissspidy and others added 3 commits February 2, 2026 20:47

Update src/DB_Command.php

94d0fea

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Update src/DB_Command.php

ba35677

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Update src/DB_Command.php

66478f6

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot started work on behalf of swissspidy February 3, 2026 02:02 View session

Fix wp db status to accept parameters and run before WordPress loads

8a0d032

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Copilot finished work on behalf of swissspidy February 3, 2026 02:05

Add wp db status command for database health overview #307

Are you sure you want to change the base?

Add wp db status command for database health overview #307

Conversation

Copilot AI commented Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Implementation

Output

Notes

My Proposed Command:

Output Example:

Uh oh!

codecov bot commented Feb 1, 2026

Codecov Report

Uh oh!

swissspidy commented Feb 2, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 2, 2026

Choose a reason for hiding this comment

Uh oh!

swissspidy Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Add `wp db status` command for database health overview #307

Add `wp db status` command for database health overview #307

Copilot AI commented Feb 1, 2026 •

edited

Loading