[wp-trac] [WordPress Trac] #47046: Site Health: Remove grading
WordPress Trac
noreply at wordpress.org
Fri Apr 26 15:47:16 UTC 2019
#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
More information about the wp-trac
mailing list