Add a new Site Health command

[plittlefield]

Is it possible to add Tools > Site Health to the cli ?

[danielbachhuber]

Thanks for the idea, @plittlefield !

Is it possible to add Tools > Site Health to the cli ?

Could you describe with a bit more detail how you'd expect it to work?

[plittlefield]

Happy to help.

Sure, how about ...

NAME

wp health

DESCRIPTION

Checks, shows the status and extra information about the WordPress site health.

SYNOPSIS

wp health <command>

SUBCOMMANDS
check                  Checks WordPress site health.
status                 Good, OK, or Bad.
info                   Shows the extra server information.

EXAMPLES

# Run health check
$ wp health check
...
output
...

# Show status summary
$ wp health status
Good

# Display the server information
$ wp health info
...
output
...

[danielbachhuber]

@plittlefield This is great, thanks!

I've asked the folks in #core-site-health if anyone has additional feedback or input.

[Clorith]

I think this is a great idea, I'd probably re-label it as wp site-health <command>, for consistency with the terminology used within core.

The info section can be... a lot... so maybe requiring that to be a bit more limited is the way to go, but other than that, it seems like a good set of commands, I'll throw in my thoughts for command structures here (all outputs of course available as table/JSON/CSV like any other data output from WP-CLI);

wp site-health check

Runs the normal checks as performed when visiting the Site Health Check page, providing the name of the check, the badge/area it belongs to, and the status. I intentionally omitted the description text here, because they may contain various allowed markup elements that would not work well in a CLI context.

Check	Type	Status
WordPress Version	Security	critical
Plugin Version	Security	recommended
REST API Availability	Performance	recommended
Communication with WordPress.org	Security	good

wp site-health status

Returns the overall status, as would be indicated by the "indicator circle" in WP-Admin. This one is relatively simple, but relies on the results of the check command. As seen below, there are multiple criteria which may trigger each scenario;

The "critical" state (red coloring):

• There are 1 or more critical issues.

The "recommended" state (yellow coloring)

• There are 0 critical issues AND there are 80% or less checks with a status of good.

The "good" state (green coloring)

• There are 0 critical issues AND Greater than 80% of checks have a status of good.

wp site-health info

This section can quickly get out of hand, so I propose this be split up, with a flag for those who want to be adventurous.

wp site-health info sections

Output a list of available info sections that are registered.

Label	Section reference
WordPress	wp-core
Directories and Sizezs	wp-path-sizes
[...]
WordPress Constants	wp-constants
Filesystem Permissions	wp-filesystem
Jetpack	jetpack

The last one is not a core one, but is registered by the Jetpack plugin, and used as an example that non-core entries may exist, and have quite a bit of data in them 😄

wp site-health info <section reference> [--all] [--private]

So for those who are adventurous, I figured allowing an --all flag would be useful. If the all flag is not passed, then a <section reference> from the info sections command is required. This will help reduce information overload, and give users just the information they need, when they need it (or that's the thought at least).

The --private flag is to include fields marked as private. The info section allows plugin and theme authors to flag data as "private" to indicate it should not be shared publicly, for example in a support request, so by hiding these values by default, you are not accidentally exposing any sensitive information, if you are for example on a terminal in a shared location where someone might look over a shoulder or similar.

Given a command such as wp site-health info wp-constants --private, you would be given the following response;

Field	Private?	Technical Details	Details
ABSPATH	Yes	/sites/clorith.net/files/	/sites/clorith.net/files
WP_HOME	No	undefined	undefined
[...]
WP_DEBUG	No	false	Disabled
WP_DEBUG_DISPLAY	No	true	Enabled

The "Private" section is only included if the --private flag is added, if not, that column is omitted for simplicity.

[plittlefield]

Wow. Amazing work. This looks perfect and exactly what I wanted! Thanks so much. Please make it happen. :-)

[danielbachhuber]

Moved this to state:approved

If any contributors would like to pick this up, feel free to start a site-health-command repo in your GitHub account. Once it's far enough along, we can look into moving it to the wp-cli organization.

@wp-cli/committers Alternatively, this might be a good project to work on during a contributor day.

[marksabbath]

I will work on this.

[marksabbath]

Here is the kickstart https://github.com/marksabbath/site-health-command

[swissspidy]

Nice, great to see this come to life!

Let us know if there's anything you'd like help with.

At first glance, it looks like it will need similar logic as WP_Site_Health::enqueue_scripts() so that the available tests aren't hardcoded. So:

1. Call WP_Site_Health::get_tests() to get all checks
2. For each direct test, run ::perform_test()
3. For the async tests, perform the necessary HTTP requests (like the ::wp_cron_scheduled_check() method does)

That said, I'm not really familiar with the WP_Site_Health class :)

[marksabbath]

Nice, great to see this come to life!

Let us know if there's anything you'd like help with.

At first glance, it looks like it will need similar logic as WP_Site_Health::enqueue_scripts() so that the available tests aren't hardcoded. So:

1. Call WP_Site_Health::get_tests() to get all checks
2. For each direct test, run ::perform_test()
3. For the async tests, perform the necessary HTTP requests (like the ::wp_cron_scheduled_check() method does)

That said, I'm not really familiar with the WP_Site_Health class :)

Yeah, I spotted an approach like you're referring here. My plan is to do something similar in the near future.

I'm gonna implement at least the status described here and then come back to refactor and perhaps add all the checks that are possible, leaving those 3 as default and some sort of way to run specific tests and a --all to show all of them.

As a side note, I'm very glad that I've started working on this project. I've spent most of the time figuring a lot of things out and now I have the confidence that I can contribute way more with wp-cli 😄