Make WordPress Core

Opened 7 months ago

Last modified 18 hours ago

#47606 assigned feature request

Display Site Health score on Dashboard

Reported by: guddu1315 Owned by: Clorith
Milestone: 5.4 Priority: normal
Severity: normal Version: 5.2.2
Component: Site Health Keywords: has-patch dev-feedback
Focuses: ui Cc:
PR Number:



Can we add site health score and list of critical issues in Dashboard ?
Not many users would know that there is something called Site Health Check in new version of WordPress. So displaying the score and critical issues list in Dashboard will notify users who are not aware about it.

Plus every time user logs in to the backend, he/she is reminded that his/her site needs updating.

Thank you,

Attachments (5)

site-health-dashboard.png (151.7 KB) - added by guddu1315 7 months ago.
dashbaord-widget.png (69.5 KB) - added by Clorith 6 weeks ago.
47606.patch (13.6 KB) - added by Clorith 5 weeks ago.
47606.diff (539 bytes) - added by dlh 2 weeks ago.
47606.2.diff (780 bytes) - added by xkon 8 days ago.

Download all attachments as: .zip

Change History (23)

#1 @joyously
7 months ago

The things that need attention already have nags.
Given #47046 I think this ticket is just asking for another dashboard widget.

#2 @afercia
7 months ago

  • Focuses accessibility removed
  • Keywords needs-design added

A Site Health dashboard widget sounds like an interesting idea to me, thanks for your proposal @guddu1315! Seems to me it needs some design feedback rather than accessibility feedback, I'm going to adjust the ticket properties :)

This ticket was mentioned in Slack in #core-site-health by sergey. View the logs.

5 months ago

#4 @hedgefield
4 months ago

  • Keywords needs-design removed

Good shout @guddu1315. Site Health is pretty hidden down in some submenu for what is arguably a feature that could use a little more attention as part of a good site hygiene strategy. An optional dashboard widget would be a good way to surface it.

The plugin version of Site Health already has a basic dashboard widget implemented: https://github.com/WordPress/health-check/issues/226 @SergeyBiryukov is currently looking at whether this can be merged into core I believe.

#5 @Clorith
6 weeks ago

#48986 was marked as a duplicate.

#6 @SergeyBiryukov
6 weeks ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.4

#7 @Clorith
6 weeks ago

  • Owner set to Clorith
  • Status changed from new to assigned

Let's start off by importing the widget from the plugin, it's tried and tested, non-intrusive, and doesn't end with information overload from too much happening at once.

I'll get a patch up later this week.

The implementation that exists right now looks like the screenshot in dashbaord-widget.png , and I think this is a great starting point, if changes turn out to be needed beyond this, we can iterate on them.

5 weeks ago

#8 @Clorith
5 weeks ago

  • Keywords has-patch added; needs-patch removed

47606.patch has a few pieces to it for functionality sake.

It makes sure the WP_Site_Health class can be instantiated once, so we don't have to recreate it for multiple page loads, this to facilitate that the class has to run in a few locations depending on context.

An instance is called in wp-settings.php, this is to make sure the introduced WP_Cron event can be picked up and handled (much like the fatal error handler, found right above it, is done, only without the assistance of helper functions).

The Dashboard widget it self is for the most part a straight copy from the plugin, as I mentioned I wanted to use that, it has a slight adjustment to the default string, shown only when no site health checks have been collected yet, to account for scheduled events being filterable so the frequency may not be what was originally implemented.

This also enqueues Site Health's JavaScript and styles on the Dashboard page, as well as the individual site-health.php pages.

The task of running tests was separated out to its own function, WP_Site_Health->perform_test( $callback ), to prevent repeating our selves in too many places.

And finally, a new cron schedule is added for weekly events (I've always been puzzled by this not already existing, but it's not been needed, and now it is, so makes sense to introduce it).

#9 @SergeyBiryukov
2 weeks ago

In 47062:

Cron API: Add a new cron schedule for weekly events.

Props Clorith.
See #47606.

#10 @SergeyBiryukov
2 weeks ago

In 47063:

Site Health: Introduce Site Health Status dashboard widget.

The widget informs administrators of any potential issues that should be addressed to improve the performance or security of their website, and directs them to the Site Health screen for more details.

Props Clorith, hedgefield, guddu1315.
See #47606.

#11 @SergeyBiryukov
2 weeks ago

In 47064:

Tests: In Tests_Site_Health, create a WP_Site_Health instance before clearing the cron array, as the constructor schedules its own task now.

See #47606.

#12 @afercia
2 weeks ago

Re [47062]: why not to use the existing constant WEEK_IN_SECONDS?

#13 @dlh
2 weeks ago

A stdClass isn't considered empty, so the empty( $issue_counts ) check in wp_dashboard_site_health() fails when $issue_counts is still in its initialized state as a new stdClass(). This generates Undefined property notices in the widget when the transient doesn't exist because the defaults aren't set.

The attached patch would switch the check to get_object_vars(), which returns an empty array for a new stdClass().

2 weeks ago

#14 @SergeyBiryukov
2 weeks ago

In 47068:

Cron API: Use WEEK_IN_SECONDS constant for the weekly schedule added in [47062].

Props afercia.
See #47606.

#15 @SergeyBiryukov
2 weeks ago

In 47069:

Site Health: Avoid "Undefined property" PHP notices in wp_dashboard_site_health() when the status result transient does not exist yet.

Props dlh for initial patch.
See #47606.

#16 @afercia
8 days ago

  • Keywords needs-patch added; has-patch removed

@SergeyBiryukov 👋 When you have a chance: seems to me that after [47063] all tests run twice. Both the WP built-in tests and the ones added by plugins.

To my understanding, [47063] introduced an initialize method that returns or creates an instance of the class. When it's called in wp-settings.php it initializes the class.

Since the class is initialized in wp-settings.php, the class __construct() runs on any admin page and calls the method within it e.g. maybe_create_scheduled_event, prepare_sql_data run on all admin pages.

More importantly, the class is initialized again in the Site Health pages thus the tests run twice.

8 days ago

#17 @xkon
8 days ago

  • Keywords has-patch dev-feedback added; needs-patch removed

I could replicate what @afercia mentioned in comment 16 and 47606.2.diff is a proposal for a solution as it still "allows" the ajax calls to pass on wp-settings. Not sure if this is optimal though so a 2nd look would be great :).

This avoids running the extra instance on all page loads but still keeps the calls enabled when necessary via dashboard + ajax.

This ticket was mentioned in Slack in #core-site-health by xkon. View the logs.

18 hours ago

Note: See TracTickets for help on using tickets.