[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