[wp-trac] [WordPress Trac] #46573: Introduce a Site Health module for users to self-service their site

WordPress Trac noreply at wordpress.org
Fri Mar 22 09:44:58 UTC 2019


#46573: Introduce a Site Health module for users to self-service their site
---------------------------------------+-----------------------
 Reporter:  Clorith                    |       Owner:  pento
     Type:  enhancement                |      Status:  assigned
 Priority:  normal                     |   Milestone:  5.2
Component:  General                    |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-patch has-screenshots  |     Focuses:
---------------------------------------+-----------------------

Comment (by Clorith):

 Looking over the list of remaining issues from @pento first:

 The debug tab is a little slow because it still performs some tests, like
 checking if we can send http requests to wp.org, this is also done by the
 site health check, so perhaps caching the results here would be an idea to
 speed things up.

 `WP_Debug_Data::get_directory_size()` was used to get the sizes of the
 various directories (plugins, themes, uploads), but when @afercia was
 testing he managed to cause a fatal error fro ma timeout when run on a
 development setup where npm_modules and vendor directories existed,
 causing the RecursiveIterator feature to run too long. If we are to re-
 introduce these as display options, we need a safeguard here, to ensure it
 doesn't run for too long, or take up too much memory. If either of those
 cases happen, it should break out early and just provide a "could not
 determine size" style message for that field.

 I agree it would be nice if every single test had an actionable item,
 ideally one that solved the problem there and then, but for a first
 iteration I think linking to appropriate wp-admin pages, or documentation,
 is the best way forward.

 We don't have a page that explains https to users as well as they do, yet,
 but it could be used as inspiration to provide good information in our own
 article if we were to write one.

 Moving along to input from @karmatosed :
 The health tests do run every time the site health page, although it is
 stored as a transient once completed, we could probably leverage this to
 either not run it on every visit to this page, or introduce a way to re-
 run things manually.

 I totally agree with every item, even recommended ones, feeling urgent
 because of the badge labeling them as security-related items. Perhaps some
 of those tests can be classified as something else, or we could also look
 to use one of the other badge alternatives to not draw as much attention
 (there's a few styles included that have passed accessibility requirements
 to choose from)..?

 I can't speak for the boxes within boxes, @hedgefield may be able to chime
 in on the process there, I _think_ the thought was to separate out a long
 list of often scary information into sections first (accordions) to make
 the page less daunting, and retain the tabular output of actual data for
 each section for easier reading (I could be mistaken, hopefully someone
 will correct me on that).

 I'm with you on the assumption bit, the current plugin iteration has an
 admin notice with a short excerpt on what the pages mean (one on each
 tab), I don't recommend using that moving forward, as it's a bit tacky
 thrown inline like that and doesn't work well with the overall view, but
 perhaps introducing some kind of help icon to show a short description
 could be the answer here?

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


More information about the wp-trac mailing list