#47046 closed enhancement (fixed)
Site Health: Remove grading
Reported by: | Cybr | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | 5.3 | Priority: | high |
Severity: | normal | Version: | 5.2 |
Component: | Site Health | Keywords: | site-health has-patch commit |
Focuses: | ui | Cc: |
Description
A few people have echoed their concerns regarding the Site Health on the feature announcement:
https://make.wordpress.org/core/2019/04/25/site-health-check-in-5-2/
The issue with grading is that users will favor a 100% score over what's right for their website.
Leading to issues, among:
- ambiguity effect,
- focalism,
- and selective exposure.
To explain those, people often go for the highest score, even if the outcome is ultimately detrimental. This is more easily achieved when the user doesn't know what implications getting such a rating would mean.
This argument is strengthened further as third parties can add custom status checks.
It would be better to leave the scoring out, and let users make informed decisions on their own (or via help from support forums), without grading them.
I haven't run the health check on production servers, whereon I've disabled automatic updates, offloaded cron jobs to the server, added Twenty Nineteen as an inactive fallback theme, added idle in-case-of-emergency plugins, and disabled imagick in favor of GD. With that, I'm sure I'll face a score of 30% or lower, and I doubt the majority of users will know why and reverse that process.
Attachments (5)
Change History (70)
#2
follow-up:
↓ 9
@
6 years ago
=> my 127.0.0.1 site got 38 % ... 38 % of what ?
Apparently, 38% of something WRONG because the 38% arc circle is in RED color (which sounds like 38% of errors because in the rest of the page, the color code is red for error, green for ok and orange for something in between (i guess 50% red/50% green)) !
Please put a help tab on this page !
=> Consistency in displaying errors or test checked using red cross, green check and orange dash ! for readability
=> The Info tab is a security issue in itself (too sensitive information)
=> Not supported by Site Health and generating security messages that are truely nonsense.
- WP_DEBUG defined and set to true
the critical issue about the WP_DEBUG and link to "Read about debugging in WordPress" is just laughable
- localhost or 127.0.0.1
The REST API request failed due to an error.
Error: [] cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received
I am glad to learn that my localhost cannot be accessed by any other external website (which ones ? personal data collected ?) !
=> Other stuff :
- Background updates are not working as expected :
Could not confirm that the wp_version_check() filter is available.
(Error) The folder .../wordpress/ was detected as being under version control (.svn).
This is not an error, it is exactly what i want
- Your site could not complete a loopback request
can anyone explain me what is a "wordpress loopback request" (no information on that topic in wordpress.org)
=> Too regularly, i have to wait 10 seconds for my test/dev site to display an admin page,
because Site Health is running !
and my code productivity keeps falling !
#3
@
6 years ago
@swissspidy Because I don't want my production network to run beta software I don't control, I went out of my way to rip Site Health out of Core. From that rip, I created a plugin for WP<5.2. For those interested, you can inspect that here: https://github.com/sybrew/wp-site-health-rip
As always, this code isn't endorsed by w.org, nor is it checked for security. Use at your own risk.
In this image, you can see the results: https://i.imgur.com/iEzQgjN.png
I expected a larger penalty. But 60/100 for one of the fastest and manually-audited WordPress sites is still not what we were aiming for.
Invalid complaints, like that we're using PHP 7.2.17, which is the latest version of the PHP 7.2 branch—and is stapled as active and secure, may require some tweaking.
I also found some other complaints that I believe are invalid, like bcmath, exif, fileinfo, and imagick module requirements; WordPress doesn't use most of these or has (better) alternatives.
I'd (loosely) assume >98% of the users don't know what some of these issues mean—mind you, they are the target audience of this feature—and they'll panic and complain to their hosting provider or developer as they want to win the numbers game. Then again, I'm exhilarated that the Core Team finally added this. A big push is what hosting providers needed, and they're finally getting it thanks to these checks—albeit accurate or not.
On the other hand, the problem lies in that the health check can (and will) be expanded by plugin authors with trivial recommendations which may hurt their site. For example, if you look at some SEO and security plugins, they're already using their own version of this to scare users and upsell their software. In those cases, you'll only be able to get a perfect score if you pay.
So, I still believe that the users will succumb to the fallacies/issues mentioned in the ticket. The detailed explanations are important and may require a more human touch (who to inform, how-to's, implications, etc.), but this is really all they need. The numbers, however, although minutiae, are not.
#4
@
6 years ago
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 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.
#5
@
6 years ago
- 38% of tests passed
so 38% should be in green, not in red ! or have the 62% of the circle in red and the 38% in green
- I'm not quite sure what you mean by consistency in displaying errors.
sometimes you have
-- red cross (for error i suppose), green check, orange dash
and sometimes you have text :
-- [error] bla bla bla
- Debugging is included in a chapter called "4 Critical issues" so apparently debug is one of the 4 critical issues ...
#7
@
6 years ago
How was this assigned to "Shortcodes" in the first place?
Anyway, thank you so much @Clorith for your engaging interest and time spent on this project!
I'd also like to thank you for the additional insights on some of the possible features we can integrate. I added those to my list!
You're right on my code-rip; I was a few (200...) commits behind :) But, upon closer inspecting, I think the API overly prefers PHP 7.3, and it will emit a critical warning when 7.2 is used; regardless of it being up-to-date.
I believe it should favor the latest version of all active branches. To only start showing warnings when the branch is phasing out, and finally with errors when it's no longer supported: https://www.php.net/supported-versions.php
The reason I highlighted performance is that I chose and tweaked the extensions that were used by WordPress, so no less-favorable fallbacks were used. A few critical modules are missing in the list from the Hosting Team, so may I suggest these to be added (yes, a new ticket would be better...):
- iconv
- mbstring (this is a must, +7000x faster than fallbacks, plus not all functions are covered)
- opcache (or equivalent)
- zip
I could go on in excruciating detail, like setting the php.ini's serialize_precision
to -1
. But, we digress even further.
As for the wording in the documentation, this is what we'll find out after the fact. Support requests will paint a better picture. As far as I know, these tests have only gone by developers and enthusiasts, not the general public.
One thing that comes to mind is that the Hosting Team's handbook page may have to inform the user on how to fix this. For instance, provide a link to the example letter to the hosting provider, as done here. Alas, I don't know if this is required; we'll have to wait and see. Ultimately, hosting providers should follow that list preemptively.
Now, as for this comment:
[...] it's a progress indicator of how many tests are passing, maybe it's not super clear.
Exactly, that's my initial concern. I still believe this is based on a point system, not a progress indicator—"x out of y" were marked completed, which is where I hope this will head to.
So, instead of giving a % completed, give real numbers, no colors, gauges, or other game-esque stuff, simply put:
"11/15 checks passed."
I think we'll come a long way if we only change the "66%" to "11/15" (which is actually 73%...). Do mind the overflow.
And, instead of coloring the wheel based on progression, I propose making it just blue (or the admin theme color).
Again, I do believe these checks will help us all. I am, however, still afraid of future implications and turning this into a game. Although, I'm very thankful for handing us your reins :) Cheers!
#8
@
6 years ago
This Trac ticket is about removing the grading and percentage score; it'd be best if other concerns are put in other tickets to make it manageable and focussed.
The percentage score and grading should be removed for at least two reasons:
1) Plenty of users don’t know how to interpret that kind of thing, and who have the sorts of obsessive personalities that can’t cope with it. They’ll believe that they absolutely must score 100%, and they’ll waste phenomenal numbers of man-hours of their own, of their hosting company, their site developer, of their plugin authors, to drive it up to 100%. (Site developers will respond by creating new plugins to hide it, fake it, exclude certain tests, etc.).
2) It’s bogus. There’s no objective, scientific way of producing a score on a 0-100 range for “site health”. It does not have an objective meaning, and will give a false sense of health to those who score highly.
A % score here in something like this is a way of reducing something complex and requiring skill to understand into something simple that everybody can understand. But sometimes, that's the wrong thing to do; it's done by being arbitrary and creating entirely new classes of knock-on problems elsewhere.
#9
in reply to:
↑ 2
;
follow-up:
↓ 13
@
6 years ago
Replying to arena:
=> The Info tab is a security issue in itself (too sensitive information)
This page is only available to administrators. Sensitive information is subjective here. There aren't any passwords, salts, etc included in this information. If you're concerned about what is output, then you can filter the response.
- WP_DEBUG defined and set to true
the critical issue about the WP_DEBUG and link to "Read about debugging in WordPress" is just laughable
You should not be running WP_DEBUG on a production site
The REST API request failed due to an error.
Error: [] cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received
I am glad to learn that my localhost cannot be accessed by any other external website (which ones ? personal data collected ?) !
This is just making a wp_remote_request()
back to your site to test that the REST API is accessible. If it isn't, critical parts of WordPress may not work, such as the new block editor.
- Background updates are not working as expected :
Could not confirm that the wp_version_check() filter is available.
(Error) The folder .../wordpress/ was detected as being under version control (.svn).
This is not an error, it is exactly what i want
If this is intentional, then it's safe to ignore or to filter from the test list.
- Your site could not complete a loopback request
can anyone explain me what is a "wordpress loopback request" (no information on that topic in wordpress.org)
A loopback is when WordPress makes a request back to itself from within a single request. A couple of examples are starting a new WP_Cron
instance, or when editing plugin or theme files through the admin.
=> Too regularly, i have to wait 10 seconds for my test/dev site to display an admin page,
because Site Health is running !
and my code productivity keeps falling !
The Site Health tool code only runs when you load the Site Health page, so it would have no affect on any other parts of your admin interface.
#10
@
6 years ago
This is just making a wp_remote_request() back to your site to test that the REST API is accessible. If it isn't, critical parts of WordPress may not work, such as the new block editor.
Does the block editor use *loopback* connections? REST from wp-admin != loopback.
#11
@
6 years ago
You should not be running WP_DEBUG on a production site
How does Site Health Check determine that it's a production site? I'm testing Site Health Check on a development site on localhost now, and I see no toggle for choosing production / staging / development. I do see various bogus warnings including this one, which it claims is a "Critical" "Security" issue. Similarly, the lack of SSL on localhost is not a security issue, because on localhost there is no potential for MITM.
WP_DEBUG
being on is actually a reasonable indication that the site isn't a production site.
#12
@
6 years ago
"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.
#13
in reply to:
↑ 9
@
6 years ago
Replying to earnjam:
Replying to arena:
=> The Info tab is a security issue in itself (too sensitive information)
This page is only available to administrators. Sensitive information is subjective here. >There aren't any passwords, salts, etc included in this information. If you're concerned >about what is output, then you can filter the response.
I don't want anyone, (even me) building that room even if there is a lock on its door. By the time, this code is in wp, those data can be collected (and the use of clipboard.js here is just another security issue)
- WP_DEBUG defined and set to true
the critical issue about the WP_DEBUG and link to "Read about debugging in WordPress" is just laughable
You should not be running WP_DEBUG on a production site
I don't think that a 127.0.0.1 site is a production site !
The REST API request failed due to an error.
Error: [] cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received
I am glad to learn that my localhost cannot be accessed by any other external website (which ones ? personal data collected ?) !
This is just making a
wp_remote_request()
back to your site to test that the REST API is accessible. If it isn't, critical parts of WordPress may not work, such as the new block editor.
i don't use the new block editor (sorry so used to wp editor for more than 10 years) and btw, my webhost refuse to support some techniques used by gutenberg ) !
this has to be documented somewhere. just a question of trust
- Background updates are not working as expected :
Could not confirm that the wp_version_check() filter is available.
(Error) The folder .../wordpress/ was detected as being under version control (.svn).
This is not an error, it is exactly what i want
If this is intentional, then it's safe to ignore or to filter from the test list.
“We can not solve our problems with the same level of thinking that created them”
― Albert Einstein
Just put an option in general setting to remove this menu options !
- Your site could not complete a loopback request
can anyone explain me what is a "wordpress loopback request" (no information on that topic in wordpress.org)
A loopback is when WordPress makes a request back to itself from within a single request. A couple of examples are starting a new
WP_Cron
instance, or when editing plugin or theme files through the admin.
=> Too regularly, i have to wait 10 seconds for my test/dev site to display an admin page,
because Site Health is running !
and my code productivity keeps falling !
The Site Health tool code only runs when you load the Site Health page, so it would have no affect on any other parts of your admin interface.
#14
@
6 years ago
Trying to put the dots altogether ...
in wp51, in function send_email() in /wp-admin/includes/class-wp-automatic-updater.php in line 728, it is possible to access to some wordpress.org support.
I tried to find where the $core_update->support_email
was set and found the following transient :
_site_transient_update_core
stdClass::__set_state(array( 'updates' => array ( 0 => stdClass::__set_state(array( 'response' => 'development', 'download' => 'https://wordpress.org/nightly-builds/wordpress-latest.zip', 'locale' => 'en_US', 'packages' => stdClass::__set_state(array( 'full' => 'https://wordpress.org/nightly-builds/wordpress-latest.zip', 'no_content' => false, 'new_bundled' => false, 'partial' => false, 'rollback' => false, )), 'current' => '5.2-RC1-45273', 'version' => '5.2-RC1-45273', 'php_version' => '5.6.20', 'mysql_version' => '5.0', 'new_bundled' => '5.0', 'partial_version' => '', )), ), 'last_checked' => 1556281173, 'version_checked' => '5.2-beta3-45268', 'translations' => array ( ), ))
Apparently there is a clear info on this transient about my site being a development site.
(and nothing about a support email btw)
#15
@
6 years ago
@arena Not sure why you're focusing on the support_email field in this ticket, but that is one potential field that the w.org api's can send back for autoupdates, so as to provide an email address for contacting if problems in the autoupdate arise. The field has not been used in some time.
#16
@
6 years ago
This ticket has spiraled, substantially, away from the original purpose. Feel free to discuss the progress indicator here, any other items please create new tickets if you want to have discussion about them, and try to avoid mass-tickets covering a whole slew of issues, please, it makes it impossible to track.
No further comment will be made about items unrelated to the topic of this ticket, for the sake of all our sanity.
#17
@
6 years ago
@all, the purpose, because there is always a purpose, is to demonstrate that wordpress knows that my site is a development site so "site health" should also know it !
And i totally agree on removing grading
(if not all the "site health" approach that lacks maturity and looks more and more toxic to me).
#18
@
6 years ago
I strongly agree with the OP that the grading should be removed. While in my opinion a lot of stuff in Site Health and especially on the Debug Info screen is super useful - especially also for plugin authors/ support, I see a disconnection between the grading and all the info provided below it.
There might be - a lot? - users who will interpret the grading also for Debug Info screen because the grading is currently "globally" displayed on this admin page (with those 2 tabs).
And my own experience was and is also, that the grading is misleading and has no real value. I also don't know how it is really calculated and how the data that goes into calculating is weighed/ interpreted internally. I guess that everyone of us also would interpret the importance of certain data differently.
The grading makes this whole - generally good - thing much more complicated on second sight and thought. Therefore we should remove it and release the overall feature without it. Especially the "obsessing to reach 100%"-factor for the average user is a risk way too high.
#19
@
6 years ago
I also agree with removing the numeric and other such meaningless indicators.
If the purpose is to provide useful debugging information, then having an arbitrary "number" or "color" does not fit with this goal. It creates a false incentive which is not necessary, and likely detrimental.
#20
@
6 years ago
- Priority changed from normal to high
I'm changing this to high, because I believe that this should be addressed before 5.2 is released. Having this could potentially be very harmful to people who choose to use these indicators in attempts to get 100% and similar.
#21
@
6 years ago
- Keywords needs-design-feedback added
No further comment will be made about items unrelated to the topic of this ticket, for the sake of all our sanity.
Absolutely agree! Lets try to get this ticket back on track (pun intended) :)
To summarize: The problem is that many sites will not be able to reach "100% Site Health" score, and that will make the admins needlessly worried.
The proposed possible solutions are:
- Show the number of passed tests instead of showing a percentage.
- Do not make the indicator red as lower score may not necessarily be "dangerous".
This ticket was mentioned in Slack in #design by clorith. View the logs.
6 years ago
#23
@
6 years ago
Show the number of passed tests instead of showing a percentage.
If this means "shows as a fraction instead of as a percentage", then that seems like a change that isn't meaningful.
#24
follow-up:
↓ 31
@
6 years ago
I think it will be better to replace it to show critical issues only, e.g. "5 Critical" in red. Anything would be better than showing a score here.
Most of the theme authors would know from the Google Pagespeed situation how awful it is show a subjective score metric to uninformed users. It's a valuable lesson for all UIs.
#26
@
6 years ago
- Keywords needs-design-feedback removed
It's more than fair to raise this concern, but we have to be mindful of where we are in the process. This is the last day before RC2 ships, and we've all agreed that in the RC phase we do not tamper with features unless there is a big problem. This is not an objectively critical problem or security issue. This is about what we consider best practices. And it's clear we don't all agree on this. I think the grading is nice to have. It could certainly be improved, but how exactly, we can debate for the next iteration, when we get actual data about how users interact with this thing. The fact that this is still open for debate in the RC phase is a bigger issue that I've already raised with WordPress leadership. I hope we can improve this process in the future so everyone can have the chance to give timely feedback and have it be considered properly.
#27
@
6 years ago
when we get actual data about how users interact with this "thing" !
what is the method ? is it relevant ?
what kind of data collected ? how ? is there any approval prior to any collect ?
#28
@
6 years ago
AFAIK, other than pinging the WordPress servers for updates (as it usually would via default functionality), there are no data collected automatically.
We'd have to collect data from written user feedback; either via the support forums or critical external reviews.
That said, I agree: it'd be better to punt this for a later release and take a more educated, less rushed approach. There's no data stored other than a transient, so this functionality can be easily mended in time, followed by an open letter explaining why changes were made.
#29
follow-ups:
↓ 39
↓ 52
@
6 years ago
I disagree with punting. The feature as a whole is extremely useful for support purposes. Getting rid of a few numerical and stylistic choices isn't difficult technically.
Keep the screens, ditch the useless numbers. Few lines of code to remove. Not a big change.
#30
@
6 years ago
I am not a programmer, and that might be what is needed here, as I know my end users.
I would like to offer an idea, not my idea, but I really like because, I can quickly take a look at know all is good, without having to figure out formulas and percentages.
One web-based application I use, it has a "System Health Status" area, I can take a quick glance to see what's good, warnings, and whats needing my attention, because it COULD be bad.
I can spend 10 seconds or less on this page and then move on or tackle what is needed.
And here is the approach,
3 Columns, 1 Color-Coded Green with a Check Mark; Another Yellow with an Attention icon; Third is red with an "X" in it
In all three columns, I am given in Green Column all that is good (and of course some of the green is what is recommended) the yellow it lists not real critical issues but some that might need near Future Attention, an example of this I was running on PHP 7.1, and since End of Life is this year, I was given a notice I was running PHP 7.1 was set and it's only getting security updates and end of life is near. That is good info to know.
And the Red Column, things like Error Reporting is set to display errors, not good in a production environment (I set that one so something would show in that column in my screenshot).
#31
in reply to:
↑ 24
@
6 years ago
Replying to asadkn:
Most of the theme authors would know from the Google Pagespeed situation how awful it is show a subjective score metric to uninformed users. It's a valuable lesson for all UIs.
Yes. I run a hosting company, and a constant problem, as mentioned above, is the number of people who are willing to spend many hours of their time and ours trying to increase their Google PageSpeed rank from 98% to 100%, or something similar, even when doing so is impractical and pointless.
Please just make it show a list of potential issues, with no percentage score.
This ticket was mentioned in Slack in #core by clorith. View the logs.
6 years ago
#33
@
6 years ago
As @hedgefield said, let's take a step back and look at this after 5.2, once we have more information. It's too late to make large changes now, and it would be good to see how it performs in the wild before changing colors. Let's keep an eye on the support forums once 5.2 is released.
#35
follow-up:
↓ 37
@
6 years ago
I strongly beg to differ.
- "Let's release it and then see how loudly people scream afterwards" is neither a sensible UX testing policy, nor a metric of whether something was a good idea to begin with.
- Whether or not Mr. Joe Average-Site-Owner does, or does not, enjoy having complex things over-simplified for him is not relevant, if the goal is quality software engineering and a resultant helpful experience.
- Hiding one visual element is not "a large change".
- We don't need to wait to "see how it performs in the wild". It performs badly in the wild, because it's an attempt to turn something complex into something simple, using arbitrary methods to do so, resulting in misdirected focus and lots of wasted man hours... and not in a way that's going to be surprising or new, but in a way well understood from previous mistakes in the area (e.g. Google PageSpeed scores). Again, in the case of a clear UX anti-pattern, whether Joe Average understands that is not relevant.
You turn on your car ignition tomorrow. A software update to your car means that the dashboard in front of you now has a new feature.... it's telling you that your "Car Health" is 70%. Explain what that means. Do you need a mechanic? How about if it's 80%? 90%? 95%? 98%? At what level should you be concerned, and why? Answer: you have no idea; the only meaningful information is the explanation of what items need looking at, and why.
#36
@
6 years ago
Whatever source it comes from, this
"Shoot first, then talk"
approach is definitely not open !
#37
in reply to:
↑ 35
@
6 years ago
I don't love the % score and would be fine with removing it since it's not really the relevant information here.
But I do want to point out that some of these examples just prove subjectivity of it. Google PageSpeed is cited several times as a well known example where it doesn't work, yet Google has not removed the score from that tool.
#38
@
6 years ago
yet Google has not removed the score from that tool.
@earnjam That's because it works *for Google*. Google aren't (directly) a web hosting company, or site developers. All the pain is outsourced. They strong-arm people into making all the changes they want, by the over-simplification. Sites get faster overall, even if there's plenty of wasted man-hours on the way - the man-hours are wasted by people other than Google. Site owners respond to simplifications even when those simplifications are wrong. That works better *for Google* than nuanced information.
Witness the same thing with the over-simplified "Your non-https site is insecure, you're doomed!" warnings in Google Chrome, strong-arming lots of people who don't really need SSL for their use sites into getting it, or if not, having to discuss with their website developer what the pluses and minuses of it were. Again, the blunt instrument works *for Google* to achieve what they wanted from the ideological view they were coming from (more SSL everywhere possible). And again, all the problems that he over-simplification caused were out-sourced to others.
Think also of the recent "Chrome gets auto-logged in when you log into a Google website" furore recently. Google act in the best interests of Google, not of the end user. End users have to make informed, intelligent choices to make sure that their own interests are being advanced. WP should not ape Google's way of working or use it as a model to emulate.
#39
in reply to:
↑ 29
@
6 years ago
Replying to Otto42:
I disagree with punting. The feature as a whole is extremely useful for support purposes. Getting rid of a few numerical and stylistic choices isn't difficult technically.
Keep the screens, ditch the useless numbers. Few lines of code to remove. Not a big change.
I totally agree with Otto here. This is a simple solution that makes sense... even if we value the information that comes from Site Health.
Most people won't understand what these information mean. The last we (developers) want is to add confusion with meaningless numbers.
This ticket was mentioned in Slack in #forums by yui. View the logs.
6 years ago
#44
follow-up:
↓ 47
@
6 years ago
- Keywords close 2nd-opinion added
We're now nearing a week into 5.2, and I am not seeing a whole lot of issues appearing relating to the grading. I'd say it's equal good and bad feedback, the little I've seen, some dislike it, others found it to be useful.
In light of there not being very little chatter about it in general, I say we close this ticket at this time.
#45
@
6 years ago
@Clorith Allow me to disagree. A week is small and that functionality might simply not have been seen by many people... yet.
We operate a maintenance service and we receive EVERYDAY questions about these arbitrary scores. The first one is the pagespeed score. People want to get 100%. They don't understand that it is not something you should wish.
We removed a known security plugin from our suggestions list for that exact reason. We had a client that didn't get a perfect score because he didn't have 2FA... on his intranet. We had to explain that it was irrelevant.
I could go on forever...
Each time, we do not complain to Google or the concerned plugin. We simply try to educate our client and try to find an "as good" product that won't trigger such questions.
To me, the question becomes: is this tool for debugging or is it to give a score ? The official blog post about 5.2 states "this release adds two new pages to help debug common configuration issues."
As a maintenance service, we love the information it provides but we also hate anything that triggers useless support calls/emails.
For these reasons, I still think removing the grading is the best move.
#46
@
6 years ago
I disagree that user feedback should be the principle metric (and I understood that the core team took that view too; see: https://wordpress.org/support/plugin/gutenberg/reviews/). Users will largely be unaware that the calculation is arbitrary and without ultimate meaning. How would they know that? They're entitled to assume that it wouldn't have been put in otherwise.
#47
in reply to:
↑ 44
@
6 years ago
Replying to Clorith:
We're now nearing a week into 5.2, and I am not seeing a whole lot of issues appearing relating to the grading. I'd say it's equal good and bad feedback, the little I've seen, some dislike it, others found it to be useful.
In light of there not being very little chatter about it in general, I say we close this ticket at this time.
I disagree @Clorith
A week is too less, since 5.2 as a major version update will normally not triggered automatically and a lot of updates have most likely not happened yet.
I can only emphasize what @maximejobin said above. I had already discussions with clients about the percentage grading value and also the tests itself. Clients are totally confused about the grading, and also very worried about lot of the tests.
In result, I pro actively removed the grading via CSS, plus additionally all tests via the "Site Health Tool Manager" plugin - except for 1 test that always is met so the client sees the big check mark.
It was/ is exactly like I assumed it: the site health "Status" feature has lots of issues, the Debug Info screen is very useful.
Removing the grading in Core is essential.
#48
@
6 years ago
I would have to agree with @maximejobin, @DavidAnderson, @daveshine
There should be more time for feedback on this, like them we are encountering questions and what it will take to get to 100%. 100% of what? And why and is 100% even needed?
In my previous career, as an Airline Pilot, as a 'quick reference' I liked percent gauges. It was very helpful to see how systems on the aircraft were operating. But the key was, we had to know the system it was monitoring, those percentages actually had meaning (and they had parameters they should be in). With most percentage indicators I have seen of recently associated with websites, they are cool, but without any real meaning. Way to arbitrary in meaning and no defined parameters.
This ticket was mentioned in Slack in #hosting-community by mike. View the logs.
6 years ago
#50
@
6 years ago
- Keywords needs-design-feedback added; close removed
This piece of UI doesn't appear to be appropriate for the information that it represents. Site health actually isn't a sliding scale when several of the items aren't required for a completely healthy site. A site can be 100% ok without having a 100% score on this meter, and that makes it inappropriate.
That said, some further research by the design team would go a long way.
#51
@
6 years ago
Well, WorPress 5.2 is here and the site health grading, complete with colors and all is there, notwithstanding the excellent argumentation of members in this discussion against meaningless %.
Grading is a dumb idea because it is totally arbitrary and unscientific.
We can now expect tons of complaints from customers.
For example, the background updates issue, indicated as critical, will raise hell with many site owners.
#52
in reply to:
↑ 29
@
6 years ago
Why not add a filter to show/hide the health grade?
This way, external plugins can control the Health Score visibility?
#53
@
6 years ago
First off, I love what you did with your plugin there, I enjoyed the header, it was a cool twist, so thumbs up on that!
We're discussing, and testing, approaches in the Health Check plugin to see what works best. I'm not sure if we'll land on anything specific within the 5.2.2 window, so I will keep the current milestone of 5.3 until we're more clear on the direction and know for certain what version it'll land in.
#54
@
5 years ago
- Component changed from Administration to Site Health
Moving Site Health tickets into their lovely new home, the Site Health component.
#55
@
5 years ago
- Keywords has-patch added; 2nd-opinion needs-design-feedback removed
All right, this has been a while in the making, so thank you all for your patience here, as a few of us have been working on the plugin side of things to test implementations to find a nice golden middle road.
47046.patch is the culmination of that. new-grading-indicator.PNG shows what we've landed on, the numeric indicator is gone, and is replaced with two (three) simple strings for clarity.
During loading, the string states Results are still loading…
, after which it will be updated with either a Good
or Should be improved
statement. This removes arbitrary confusion about what the numbers mean, and what is going on (previously the indicator was just pulsing, which was not super obvious to all).
As I've also had a chance to observe plugins interacting with this new area over the months since the release, it's become clear that the weighting of issues needs to be adjusted, in light of this, critical issues will always lead to a should be improved
response, but items in the recommended
pile will have a much smaller impact on the overall results.
Speaking of the indicator, yes, we've kept it, the visual aspect of seeing that there's still that remaining push to get things into a good state is rather valuable, and also provides a representation of where to look for the results once the checks have finished doing their thing.
#56
@
5 years ago
@Clorith just a couple of observations in testing this patch.
- Looks great!
- I understand that we should perceive
Background updates not working as expected
to be a critical issue, however, if we are under version control we perhaps we could move this toRecommended
and notCritical
? - Just because
WP_DEBUG_LOG
is true doesn't mean that the file is publicly viewable. We can now determine the exact file path of thedebug.log
by usingini_get( 'error_log' );
. Perhaps some testing to see if this is in the path to be viewable by a browser should the message display.
#57
@
5 years ago
Good valid points, the the reason for WP_DEBUG_LOG
is really because there's no way of knowing what URL the logfile might be available under, so for the average user, this is the better approach, while the seasoned user that has this set intentionally, it's possible to make the presumption that they know what this is and that it can be disregarded during testing.
I agree on the background updates bit, but we should split that out into a separate ticket so that this one remains focused on the indicators.
#58
@
5 years ago
Sorry, I just realized I should make a different ticket.
For the WP_DEBUG_LOG
something as simple as testing the error log path against ABSPATH
and if ABSPATH
is in the error log path the critical
otherwise recommended
.
Just adding
$result['status'] = strpos( ini_get( 'error_log' ), ABSPATH ) ? 'recommended' : 'critical';
to the end of get_test_is_in_debug_mode()
might help.
#61
@
5 years ago
- Keywords commit added
Tagging this for commit as 47046.patch should be good to go.
#64
follow-up:
↓ 65
@
5 years ago
Are there any known bugs with notifications in Trac? I've turned them off for this ticket, but still get one every time someone posts on it (screenshot: https://snipboard.io/CLcvYW.jpg ).
#65
in reply to:
↑ 64
@
5 years ago
Replying to DavidAnderson:
Are there any known bugs with notifications in Trac?
Yes, see #meta3594.
Wanna actually test it first? :-) Curious to see the results.