[wp-trac] [WordPress Trac] #47046: Site Health: Remove grading

[WordPress Trac]

#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
 of them.

 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
 masses.

 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