Facilitate async debug entries in Site Health Info

[westonruter]

I noticed that loopback request test is not included in the Site Health Info. It seems that no asynchronous tests are included in the debug information with the exception of the hard-coded wp-paths-sizes. In the same way that site_status_tests allows for specific tests to be async, it would be great if debug_information allowed the same. Other existing core tests should be included in the Site Health Info as well, specifically the tests dotorg_communication, background_updates, and loopback_requests.

For some context: I work on the AMP plugin and loopback requests are essential for the plugin to work properly. When users create support forum topics with their Site Health info, it would be very helpful if the result of the Loopback Requests test were included in the debug info.

[Clorith]

I definitely agree that this should be a thing, and I'm going to move to focus away form just the async tests core does, to making a more generalized implementation for any developer, makes little sense to keep this "private".

Having thought a bit on this, and keeping in mind that we want to retain the wp.a11y.speak implementation that communicates that data is loading, and when all async data has been fetched, I'm seeing two approaches, either via actions, or filters.

An action could be invoked, but this would mean that the developers are responsible for not only doing the remote actions, but also updating the debug information, and the text that is copied (these are two different values, as it is human readable, and technical jargon respectively).

Due to this, I'm thinking it may make more sense with a filter, this would allow them to append a much simpler object to an array of async responses, I'm thinking along the lines of:

• Their debug data identifier
• Their human readable text
• Their technical text
• (optional) Callback function

With all this data available, core could then internally make the text replacements where it is needed.

The optional callback is to fire events if needed, my inspiration for this is the directory size fetcher that already exists, which removes a spinner when the sizes are updated; This is currently part of the function that updates the texts, but since that function needs to be generalized, a new method needs to allow for modifying more on the page at the "right time" (since during the filter would in most cases be too early, as no values have been updated yet).

If there's agreement that the filter approach is the safest, I am happy to own getting that in place.

[Clorith]

#53068 was marked as a duplicate.