Add a new Site Health command
Is it possible to add Tools > Site Health to the cli ?
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?
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
...
@plittlefield This is great, thanks!
I've asked the folks in #core-site-health if anyone has additional feedback or input.
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.
Wow. Amazing work. This looks perfect and exactly what I wanted! Thanks so much. Please make it happen. :-)
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.
I will work on this.
Here is the kickstart https://github.com/marksabbath/site-health-command
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:
- Call
WP_Site_Health::get_tests()to get all checks - For each
directtest, run::perform_test() - For the
asynctests, 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 :)
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:
- Call
WP_Site_Health::get_tests()to get all checks- For each
directtest, run::perform_test()- For the
asynctests, perform the necessary HTTP requests (like the::wp_cron_scheduled_check()method does)That said, I'm not really familiar with the
WP_Site_Healthclass :)
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 😄
Hello,
I have created a repo for site health command collecting ideas from the comments in the issue.
- Package repo - https://github.com/ernilambar/site-health-command
- Readme - https://github.com/ernilambar/site-health-command#readme
Commands:
wp site-health check [--<field>=<value>] [--fields=<fields>] [--format=<format>]wp site-health info [<section>] [--all] [--fields=<fields>] [--format=<format>] [--private]wp site-health list-info-sections [--fields=<fields>] [--format=<format>]wp site-health status
Notes:
wp site-health list-info-sections- Subcommand name here not good here. I have added here just as POC. We could convert it towp site-health info-section listor evenwp site-health section list
Hello,
I have created a repo for site health command collecting ideas from the comments in the issue.
- Package repo - https://github.com/ernilambar/site-health-command
- Readme - https://github.com/ernilambar/site-health-command#readme
Commands:
wp site-health check [--<field>=<value>] [--fields=<fields>] [--format=<format>]wp site-health info [<section>] [--all] [--fields=<fields>] [--format=<format>] [--private]wp site-health list-info-sections [--fields=<fields>] [--format=<format>]wp site-health statusNotes:
wp site-health list-info-sections- Subcommand name here not good here. I have added here just as POC. We could convert it towp site-health info-section listor evenwp site-health section list
Looks like yours is way more complete than mine, so I'm gonna step back on this. LMK if you need help.