[wp-trac] [WordPress Trac] #50770: Facilitate async debug entries in Site Health Info

[WordPress Trac]

#50770: Facilitate async debug entries in Site Health Info
-------------------------+------------------------------
 Reporter:  westonruter  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Site Health  |     Version:  5.2
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50770#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform