Make WordPress Core

Opened 5 years ago

Last modified 3 years ago

#47336 new enhancement

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

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


Related discussion

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
5 years ago

  • Keywords site-health added

#2 @earnjam
5 years ago

  • Type changed from defect (bug) to enhancement

#3 @mnelson4
5 years 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
5 years ago

  • Component changed from REST API to Site Health

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

#5 @TimothyBlynJacobs
3 years ago

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

#6 @Clorith
3 years 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.