WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 6 weeks ago

#47336 new enhancement

Consider adding a JS/Client based Site Health Check for the REST API

Reported by: youknowriad Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.2
Component: Site Health Keywords: close
Focuses: rest-api Cc:

Description

Related discussion https://wordpress.slack.com/archives/C02RQC26G/p1558429627205600

At the moment, the Site Health Page includes a REST API check that is based on a wp_remote_get call to the posts endpoint.

The problem with this approach is that it only catches issues if they're on the PHP side of things. In the Gutenberg repo, we noticed that there are a lot of issues related to Firewalls... breaking the REST API calls.

The idea here is to consider adding a check to the site health page performing a REST API endpoint call triggered from the client (JS). That way it will go through the regular flow of REST API endpoint calls gutenberg and other clients will use.

Change History (6)

#1 @swissspidy
19 months ago

  • Keywords site-health added

#2 @earnjam
19 months ago

  • Type changed from defect (bug) to enhancement

#3 @mnelson4
18 months ago

+1 this, although the code to be changed may send a request to the REST API, the REST API itself shouldn't require any changes, right? Maybe this would fit better into another component?

#4 @desrosj
18 months ago

  • Component changed from REST API to Site Health

Moving Site Health tickets into their lovely new home, the Site Health component.

#5 @TimothyBlynJacobs
6 weeks ago

Now that Site Health async tests have been moved to the REST API, #48105, is this still necessary? cc @clorith.

#6 @Clorith
6 weeks ago

  • Keywords close added; site-health removed

I don't think this needs any other resolution, no.

With the async tests now being triggered by JS and going through the REST API, and an improvement was also made to JS error handling at the same time, so any failures to use the REST API would be surfaced that way.

There is still the get_test_rest_availability check in Site Health, which could be removed, but at the same time I think it does sort of make sense to leave it in, as you then get both sides of the coin checked out, and I have seen plugins and themes hit up various "local" REST endpoints for whatever reason via PHP code previously, so this would just be an added sanity check for such cases.

Note: See TracTickets for help on using tickets.