[wp-trac] [WordPress Trac] #47046: Site Health: Remove grading
noreply at wordpress.org
Thu Apr 25 21:20:35 UTC 2019
#47046: Site Health: Remove grading
Reporter: Cybr | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Shortcodes | Version: trunk
Severity: normal | Resolution:
Keywords: site-health | Focuses: ui, administration
Comment (by Clorith):
So, there's a lot to go over here, and if I come off sounding a bit
defensive, that's probably a little bit right as I've been responsible for
the plugin (and still am), but I like to think I'm open to input when it's
got good arguments backing them :)
I'll start with your points @arena (because they came first).
I may be misreading some of your items, because I found them to be a bit
all over the place with various indicators, but hopefully I got the gist
38% of tests passed, it's a progress indicator of how many tests are
passing, maybe it's not super clear, but I think that's something we're
more likely to find out post-release as more non-developer users get eyes
on it, those users vastly outnumber developer users and they like
acknowledgements, giving them a visual representation in some manner is
good for this.
I'm not quite sure what you mean by consistency in displaying errors.
In what way is the debug information a security issue? This is information
any site admin has readily available to them at any given time regardless,
and there's no reason to try and hide their own details. If there are
specific concerns we would of course love to hear of them.
`WP_DEBUG` shouldn't be used in production, some times you need to, in
those cases you should know what you are doing, and remove it afterwards.
This is because many plugins or themes use this check to output
potentially sensitive data to logs and sometimes publicly available files,
this should be considered a critical issue in my opinion. Why you find
this laughable I don't quite understand, again keeping in mind this is
primarily aimed at the users who may not be heavy on the technology side.
If you know that things that prevent automatic updates are OK for you,
you're in that marginal group, you can know that you can ignore this error
so again I don't see the problem with this.
A loopback is a request made from the web application to it self
(basically a web-request from mysite.com to mysite.com), this is used to
trigger WP_Cron (which means scheduled events, automatic updates and
similar), but also to validate that your site is still avialable when
using tools like the built in theme and plugin editors.
That your site is slow loading in the admin area should not be related to
the Site Health module, it literally only runs when you visit that page,
so I'm not quite sure what this point is aimed at?
Now on to the input from @Cybr.
The first thing I noticed is that you seem to be running an older version
of the code used in core, which may explain some of the false positives
you are seeing (for example the PHP ones). Once 5.2-RC1 lands, the
[https://wordpress.org/plugins/health-check/ Health Check &
Troubleshooting plugin] will be updated to reflect the changes we've
implemented for core to ensure feature parity. It will then be released
ahead of 5.2, so you can also use it for testing once version 1.3.0 is out
if you'd like.
The score isn't representative of your site speed, and the site health
checks aren't all performance related, so the Site Health to PageSpeed
Insights comparison doesn't help here unfortunately.
As for the PHP modules, this is based off the recommendations and
requirements by the Hosting Team, the references for it all should be in
the test details on your site.
You are right that the majority of users will be blissfully unaware of
many of the things that may pop up here, until this point,but we have
(hopefully) done an OK job of providing both explanations, and action
items when possible, to help guide them here. Can they be improved
further? I'm positive they can, but in which direction we really won't
have a good feel for before the initial version has been given to the
As for others extending these tests, you are right that they will (and
some are already preparing for it), I've seen some really exciting uses of
it, from checking connectivity status to a SaaS, to in-site accessibility
audits based off the W3Tech tools and their APIs.
Will some of them be bad, oh absolutely, some of the tests will be
pointless; That's the nature of it all when we give over the reins, but
it's also what makes WordPress so great, because we ''do'' give the reins.
Hopefully this explains a little, answers some questions or addresses
concerns, if it doesn't I'd love specific items to respond to and I'd be
happy to do so.
Ticket URL: <https://core.trac.wordpress.org/ticket/47046#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac