Opened 4 years ago
Last modified 4 years ago
#51088 new defect (bug)
Site Health Status widget displays incorrect or inconsistent number of issues
Reported by: | Ate Up With Motor | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.5 |
Component: | Site Health | Keywords: | has-screenshots |
Focuses: | Cc: |
Description
I have observed that the Site Health Status widget on the admin dashboard sometimes displays an incorrect or inconsistent number of issues.
When I log into the dashboard (on several different WordPress sites), the Site Health Status widget will often say "Take a look at the n items on the Site Health screen" where n is typically 5 or even 6. When I click on the Site Health screen and give it a moment or two to run, the number of issues shown is usually no more than 1 or 2 (generally trivial things, like not having a default theme). Once I've visited the Site Health screen and given it time to load, the dashboard widget will generally update to display that same number. However, if I don't, the widget will continue to display the incorrect total.
My very tentative theory is that this might be a processing speed issue. My sites use shared hosting, so they can be laggy. I wonder if perhaps areason for this behavior could be that certain Site Health tests are not completing within a specified interval and that is causing the widget to list those tests as failed rather than incomplete. However, I don't know enough about how the Site Health processes work to judge how likely that may be.
Attachments (1)
Change History (9)
#2
@
4 years ago
I concur. On the Site Health page itself, while it's still calculating, it displays the message "Results are still loading… " until it's finished, after which it displays correctly. Even if it's a bit laggy on a slow or heavily loaded server, there's little ambiguity about what it's doing. The widget is more of an issue because it doesn't appear to finish calculating itself -- even after returning to the main dashboard several times after performing other tasks, it will often still show its preliminary, high estimate of 5 or 6 issues.
One concern with the high false positive number the widget sometimes displays is that if an administrative user becomes accustomed to it, they may tend to ignore the widget and thus be slow to recognize when the Site Health monitor has really identified a real problem. This has already happened to me a few times; I had a new issue (luckily not a severe one -- a stalled cron job) that had persisted for several days because I assumed the Site Health widget was crying wolf again. That's unfortunate because it tends to reduce the effectiveness of this useful functionality.
#3
@
4 years ago
Hiya,
The widget it self doesn't perform any tests at all, it just gets the results form the last time the Site Health check was performed (if this was by visiting the Site Health page it self, or the weekly scheduled event).
This is where the slight separation comes in, if a problem was resolved after the scheduled check, or the last visit to the Site Health page, then the number shown in the widget may no longer be accurate until the next automatic check, or visit to the Site Health page it self.
Suggestions on how to improve this is obviously more than welcome, running the checks on the dashboard would not be an option, as that would be a bit too heavy for the first page you visit.
#4
@
4 years ago
The usefulness of this widget - as it is - should be reviewed.
- Have a datestamp?
- Timeout after n days, then say unknown or no current information (visit Site Heath)?
- Removed / replaced by a direct link to Site Heath in At a Glance?
This ticket was mentioned in Slack in #design by clorith. View the logs.
4 years ago
#6
@
4 years ago
site-health-dashboard-widget.png is a mockup of a change to the widget so that it displays the last time the tests were run.
I'm not convinced this is the right way to address this, but at least it shows that the results displayed are not necessarily current, and that you might see different results when you actually go to the Site Health screen.
Note: the suggestion here is to use human_time_diff() instead of timestamp.
Hi @ate-up-with-motor. Thanks for opening this ticket. Yes, I've noticed this behavior also in the dashboard widget, and on the "Site Health" page.
I also believe that the slight lags noticed in the number display is due to calculations being performed before the display (although I doubt that's the only cause).
For example on the dashboard widget, from https://github.com/WordPress/wordpress-develop/blob/master/src/wp-admin/includes/dashboard.php#L1790 to L1806.
On the "Site Health" page I don't think it's really a problem because correct numbers load after a second or two. But it is an issue on the admin widget because it usually takes several refresh and much more time to get the correct numbers.