[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:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  site-health     |     Focuses:  ui, administration
----------------------------+---------------------------------

Comment (by DavidAnderson):

 > "The site health check shows critical information about your WordPress
 configuration and items that require your attention."

 This statement is too absolute, given the current workings.

 To pick another few issues out of the air after just another few minutes
 of review:

 1) Now we're going to have WP core installing inactive default
 themes/plugins (Akismet, TwentyX, Hello Dolly), whilst also telling the
 user that they're a security risk and not recommended. i.e. WP core does
 X, whilst simultaneously telling the user that X is bad security practice.
 Though...

 2) "Inactive plugins are tempting targets for attackers" - that's bogus
 advice. They're less vulnerable (and less easy to find) than active
 plugins. A normal reading of that line implies the opposite (i.e. special
 source of temptation).

 3) Recommends the installation of php-imagick and its Ghostscript parser,
 without mentioning that this potentially opens you up to all the potential
 security bugs (Google for past issues) in such a large/complex piece of
 software as a script parser. i.e. It's not a straightforward "install
 this, definite win" issue as the Health Check presents it, but a trade-
 off/judgment.

 4) The "Server architecture" line will trigger a mod_security rule on some
 installs and the page won't be seen at all, which is counter-productive.
 I've seen it with UpdraftPlus from far too many users until we modified
 the output to stop triggering the rule. (Yes, the rule is stupid/annoying
 - but it exists - specifically, don't output `x86_64`).

 5) "Background updates ensure that WordPress can auto-update if a security
 update is released for the version you are currently using.". Historically
 patch releases were security releases; but now they're frequently being
 used for new core features as well (e.g. the "Privacy" features in WP
 4.9.6 IIRC). As such, insisting that they're deployed automatically,
 otherwise "critical security" problem means insisting that site owners put
 their sites at risk of new features causing new bugs whilst they sleep.
 i.e. It's a trade-off, not a slam-dunk security decision. Perhaps a site
 owner wants to manually test the new release to see if its features break
 anything on his site via a staging version, before deployment. WP Core
 needs to make its mind up about whether background patch updates are only
 about security/bugs, or about new features, and present the decision about
 using them to the user as a choice; the presentation in "Site Health
 Check" over-simplifies.

 As someone who's experienced in web hosting, plugin development, plugin
 support, client management and WP core, what I see here overall is
 something far too under-cooked for consideration for WP core. Currently
 it's very predictable that it'll cause a lot of pain if it gets released.

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