Make the warnings about critical Site Health issues more prominent

[azaozz]

Judging by comments on make.wordpress.org and the support forums, seems many people like and care about the Site Health features. A logical next step would be to be able to "escalate" the more critical issues detected by Site Health and make an effort to bring them to the site admins/owners attention.

The most pressing issue at the moment is to try to clearly communicate the need for running on more recent PHP version. There are many benefits and virtually no (or very few) drawbacks for the actual site and for the community as a whole. However many site owners are probably not aware about what PHP version is installed on their server or how to go about updating it.

This ticket is intended for designing and implementing more prominent warnings about critical site health issues. Some ideas that came up in previous discussions:

• A non-foldable, non-hideable widget on the Dashboard (shown only to admins).
• Site Health emails listing the more critical issues and ways to address them. These can be sent to site admins perhaps monthly or whenever WordPress is auto-updated.
• Warnings (at the top) on most wp-admin screens. This would probably be quite intrusive and really annoying. Added here for completeness.

[SergeyBiryukov]

Related: #54338, also #49923, #50118, #50770, #53024, #54598.

[azaozz]

After discussing this with @Clorith, @hellofromTonya, and others, I'm thinking that sending infrequent (about once a month) emails would be best. It's like Site Health will be talking to the site owners/admins, telling them what can be done to make their sites better :)

Of course, like with all emails sent from WordPress, there will be a filter to disable these, or "filter" the frequency.

Any other ideas/suggestions?

[costdev]

Additional suggestion: A count of critical issues added to the Tools and Site Health menu items.

[costdev]

The suggestion above could help Site Health get attention from admins who already take heed of the Core, Theme and Plugin update counts. It would only show the count for critical issues.

It's a less intrusive option than an admin notice, and still has that "Hey, remember me?" element to it.

I'm not opposed to Core sending emails about Site Health, but I do fear it'll become a "delete and forget" scenario. We can't avoid that with emails, but we could avoid it with the counter. If the counter doesn't render the desired results, we could consider adding the email option, or do both from the outset?

[hellofromTonya]

The overarching goal of this ticket is to get site admins to take action to upgrade their PHP version (i.e. to migrate off of older PHP versions). In the past, similar initiatives occurred which did help, see #41191.

I'd like to suggest considering multiple strategies (AND), rather than selecting a single approach (OR). Why? To maximize awareness as people consume and interact with information differently. While one approach may get attention, it could be disabled and forgotten about.

Keywords:

• Adding servehappy keyword as this fits into past ServeHappy initiatives.
• Adding needs-design keyword for UX (user-experience) workflow considerations.

[azaozz]

Replying to costdev:

It's a less intrusive option than an admin notice, and still has that "Hey, remember me?" element to it.

Yep, very good idea imho, thanks.

Replying to hellofromTonya:

I'd like to suggest considering multiple strategies (AND), rather than selecting a single approach...

Yes, that would be better. The general idea about PHP and MariaDB/MySQL updates is to treat them the same as core, plugins, and themes updates as much as possible. Having the same visual clues (menu bubbles) and sending email warnings when there are more severe issues would help a lot of site owners, and the community as a whole. Of course some will ignore the emails and the bubbles but that doesn't mean we (the WordPress project) should stop trying to get them to act. It is in their best interest :)

[mcmwebsol]

If emails are going to be sent out for "critical" issues, then I think the detection of some of them needs to improve. For example, the "Your site is set to log errors to a potentially public file" doesn't actually detect if the debug log is readable over the web. A .htaccess file can be present that blocks debug.log from being web-readable and that critical issue will still be shown.

[Clorith]

The bubble-format is actually in use within the Health Check plugin already for testing, so this is something that's been tested thuroughly and seems to be a good approach, it does require a bit of tinkering to add the bubbles to parent menu elements ("Tools"), but it's definitely doable.

Replying to hellofromTonya:

The overarching goal of this ticket is to get site admins to take action to upgrade their PHP version

If this is the primary focus, we may want to start with updating the ServeHappy versions within Meta. They've intentionally not been bumped up to 8.x yet, to avoid causing unnecessary fear within users for such a large jump, but with 7.x becoming EOL at the end of the year, it may be time to make the bump.

IT should be noted that Site Health uses these values to determine if a PHP upgrade warning is needed/recommended/critical as well, so this bump would need to happen regardless at that point.

Adding an email flow isn't a terrible idea, but we need to be vary of how often, and what for, they go out for (to avoid users perceiving it as spammy), especially given that plugins or themes can also extend it, change priorities, add new checks, etc.

Perhaps a quarterly status, that shows a summary of good/recommended/critical on your site.
A followup to the weekly automated checks, that see if the critical rate has gone up, and only if it has send a notification to the site admin.

This would ensure critical items get addressed in a more timely manner, while the quarterly status gives the site admin a peace of mind reminder, and also keeps them aware that there are things they may want to keep track of over time? (just some immediate thought I had, lets iterate, obviously)

[azaozz]

Replying to Clorith:

The bubble-format is actually in use within the Health Check plugin already for testing, so this is something that's been tested thoroughly and seems to be a good approach, it does require a bit of tinkering to add the bubbles to parent menu elements ("Tools"), but it's definitely doable.

Great, lets add this as soon as it's ready. Can probably just "copy" the code that adds the bubbles to the other top menus.

If this is the primary focus, we may want to start with updating the ServeHappy versions within Meta. They've intentionally not been bumped up to 8.x yet, to avoid causing unnecessary fear within users for such a large jump, but with 7.x becoming EOL at the end of the year, it may be time to make the bump.

Yep, the main focus here is to move the needle low enough so the minimum PHP version can be bumped to (at least) 7.2, ideally to 7.4 soon.

Adding an email flow isn't a terrible idea, but we need to be vary of how often, and what for, they go out for (to avoid users perceiving it as spammy), especially given that plugins or themes can also extend it, change priorities, add new checks, etc.

Perhaps a quarterly status, that shows a summary of good/recommended/critical on your site.

Yes, quarterly sounds good, emails shouldn't be sent too often. Thinking emails for more urgent severe issues, like the site becoming non-upgradeable because it's on an old PVP version, should probably be more often, perhaps monthly? In any case, email frequency will be filterable and can be adjusted later too.

[SergeyBiryukov]

Replying to azaozz:

If this is the primary focus, we may want to start with updating the ServeHappy versions within Meta. They've intentionally not been bumped up to 8.x yet, to avoid causing unnecessary fear within users for such a large jump, but with 7.x becoming EOL at the end of the year, it may be time to make the bump.

Yep, the main focus here is to move the needle low enough so the minimum PHP version can be bumped to (at least) 7.2, ideally to 7.4 soon.

Last time a minimum supported PHP version bump was discussed in #51043, I believe the requirement stated in comment:16:ticket:51043 was to get the usage of the older versions we no longer want to support (PHP 5.6, 7.0, and 7.1 at this time) below 5% across all sites.

Looking at the ​current stats, this is already the case for PHP 7.0 and 7.1:

8.1	1.27%
8.0	6.33%
7.4	55.33%
7.3	14.09%
7.2	9.25%
7.1	2.23%
7.0	3.16%
5.6	5.90%

PHP 5.6 is pretty close too at 5.9% (down from 8.53% a year ago and 15.40% two years ago), so hopefully this ticket helps us get it across the line. That said, I wonder if PHP 5.6 is mostly used with older WordPress versions, so the usage gradually drops due to new sites being created and not necessarily due to older sites being upgraded.

[Clorith]

Should we then start by bumping the ​ServeHappy configs?

I'm thinking that we retain ACCEPTABLE_PHP at 7.x (maybe upping it to 7.4, which is widely available with hosts I believe, even if 8.x isn't quite yet?).

We would then just be changing the SUPPORTED_PHP and SECURE_PHP values. This would reduce the amount of sites seeing the ServeHappy dashboard widget, but the Site Health Checks actually lean more on the SECURE_PHP and SUPPORTED_PHP values, so would potentially flag up recommendations or critical notices to site owners about potential outdated PHP versions not receiving (official) security updates. 🤔

This change would also mean that no additional work is needed within core for the first part, and we could focus this ticket more on improving the discoverability of critical Site Health checks?

[SergeyBiryukov]

Replying to Clorith:

Should we then start by bumping the ​ServeHappy configs?

I'm thinking that we retain ACCEPTABLE_PHP at 7.x (maybe upping it to 7.4, which is widely available with hosts I believe, even if 8.x isn't quite yet?).

Good point! I have created ​#meta6432 with my current thoughts on this. Any feedback welcome :)

[azaozz]

Replying to SergeyBiryukov:

Last time a minimum supported PHP version bump was discussed in #51043, I believe the requirement stated in comment:16:ticket:51043 was to get the usage of the older versions we no longer want to support (PHP 5.6, 7.0, and 7.1 at this time) below 5% across all sites.

Right, this is 5% for all unsupported versions, i.e. 5% of the WordPress installs out there will not be able to get upgrades to the latest version because they are running on too old PHP. We are aiming for a minimum PHP version of 7.2, currently the numbers are:

7.1	2.23%
7.0	3.16%
5.6	5.90%
Total	11.29%

Thinking about it again, 5% is a huge number of sites. However not being able to upgrade sends a really strong message to site owners and hosts. Looking at previous times minimum required versions were bumped, these 5% rapidly went down to around 1-2% in few months.

I wonder if PHP 5.6 is mostly used with older WordPress versions, so the usage gradually drops due to new sites being created and not necessarily due to older sites being upgraded.

Yes, that sounds quite likely. But even if most sites that are currently on 5.6 are also running an older version of WP, we still shouldn't just drop them. Hoping we will be able to reach some of the owners of such sites with the enhancements we are adding in this ticket.

Actually this is a good follow-up question for the emails that Site Health is going to send. Thinking we should mention both the PHP version and the WP version if it needs upgrading.

[azaozz]

Was thinking we can reuse the Serve Happy Dashboard widget to show a "sticky" warning when the PHP version is too old and soon will become unsupported. However I don't see a good way to do that. Seems there are two possibilities:

1. Extend the Serve Happy widget.
2. Add a new widget specifically for this case, then remove it (or suspend it/comment it out) in the next version when it would not be needed.

At first look # 2 seems perhaps better, but then that new widget will interfere with Serve Happy. Most likely both will be shown at the same time. Don't think that'd be good.

Looking at extending the Serve Happy widget, perhaps we can add a "static" case/text that will be displayed instead of doing an API request when the PHP version is lower than 7.2?

Any other thoughts/ideas?

[SergeyBiryukov]

Replying to azaozz:

Was thinking we can reuse the Serve Happy Dashboard widget to show a "sticky" warning when the PHP version is too old and soon will become unsupported. However I don't see a good way to do that.

Hmm, how would that be different from the existing widget​ displayed in that case?

It looks like the widget can be hidden via Screen Options though, should we maybe remove the ability to hide it?

[azaozz]

Replying to SergeyBiryukov:

Hmm, how would that be different from the existing widget displayed in that case?

Thinking the text should be different. Should clearly explain that the site owner will not be able to upgrade WordPress if they do not get PHP upgraded first. Can probably keep the warning that the old version may become insecure too.

It looks like the widget can be hidden via Screen Options though, should we maybe remove the ability to hide it?

Yep, think so. Lets remove the ability to hide the widget if PHP is either insecure or would be below the minimum required version soon. Also perhaps the styling of that widget may need a look. The most important part is about needing to upgrade PHP, not what PHP is :)

Looking at what a patch should be like for that.

[SergeyBiryukov]

Replying to azaozz:

Replying to SergeyBiryukov:

Hmm, how would that be different from the existing widget displayed in that case?

Thinking the text should be different. Should clearly explain that the site owner will not be able to upgrade WordPress if they do not get PHP upgraded first. Can probably keep the warning that the old version may become insecure too.

OK, the text should be easy to change :) It's in wp_dashboard_php_nag() and can differentiate based on these flags in $response, coming from wp_check_php_version():

• string 'recommended_version' — The PHP version recommended by WordPress.
• bool 'is_supported' — Whether the PHP version is actively supported.
• bool 'is_secure' — Whether the PHP version receives security updates.
• bool 'is_acceptable' — Whether the PHP version is still acceptable for WordPress.

[azaozz]

Replying to SergeyBiryukov:

the text should be easy to change :) It's in wp_dashboard_php_nag() and can differentiate based on these flags in $response, coming from wp_check_php_version():

• string 'recommended_version' — The PHP version recommended by WordPress.
• bool 'is_supported' — Whether the PHP version is actively supported.
• bool 'is_secure' — Whether the PHP version receives security updates.
• bool 'is_acceptable' — Whether the PHP version is still acceptable for WordPress.

Yep, thanks, text is pretty easy to change. Do you know what the difference is between is_supported and is_secure, and why that would matter to the users? (BTW is_secure is a poorly named variable, would be 1000 times better as receives_security_updates imho. Should probably fix it.)

[azaozz]

In 56199-dashboard-widget.diff:

• Add (hard-coded) check to wp_check_php_version() whether the current PHP version is lower than the next minimum version.
• Use that check to add and update the warning messages in the wp_dashboard_php_nag() widget.

[SergeyBiryukov]

Replying to azaozz:

Do you know what the difference is between is_supported and is_secure

This is based on ​PHP: Supported Versions. Technically, at this time:

• is_supported should be 8.0, the earliest version still receiving bug fixes in regular point releases.
• is_secure should be 7.4, the version only receiving critical security fixes on an as-needed basis.

However, is_supported has not been bumped to 8.0 yet, for the reasons stated in ​#meta6432.

and why that would matter to the users?

For insecure versions, the warning is more "severe", it has a red exclamation mark (as seen on the screenshot​) and specifically states that the version is insecure, rather than just outdated.

Other actionable areas in the WordPress admin interface such as updates, plugins, and themes all have a corresponding menu item with a bubble-count to indication that there is actionable items within, and how many.

This change introduces a similar bubble count to the Site Health sub-menu item, indicating the amount of critical actionable items currently available.

Trac ticket: https://core.trac.wordpress.org/ticket/56199

[Clorith]

PR 3177 adds a bubble-count to the "Site Health" menu item, but not the parent "Tools" one, the reasoning being that there's no clean way of doing this without the same kind of "hard coded" approach as is done to add the counter to the sub-menu item within core.

I think re-visiting the parent menu item item is something that could be done in a future iteration, when a system for managing badges/bubbles within menu items in general is unified.

As for the implementation it self, it's basically taking the transient data that the dashboard widget also uses, and adds the counter based on the amount of critical issues, as described. The one place where the behavior might feel a bit strange, is when you click into the Site Health screen, since the badge is reactive to the status checks, it may disappear, and re-appear once the tests have re-ran (since the test suite starts with 0 issues, before it starts processing them and getting asynchronous test results back).

[ironprogrammer]

Test Report

Patch tested: ​PR #3177 👍🏻

Steps to Test

1. Configure environment to use PHP 5.6.
2. Disable the ​Health Check & Troubleshooting plugin, if active.
3. Navigate to Tools > Site Health.

Expected Results

• ✅ The Site Health submenu item has a bubble indicating one or more critical issues.
• ✅ The Site Health screen critical issues include the outdated PHP (5.6.x) notice.

Environment

• OS: macOS 12.5.1
• Browser: Safari 15.6.1
• Browser: Google Chrome 105.0.5195.102
• Server: nginx/1.23.1
• PHP: 5.6.40
• WordPress: 6.1-alpha-53344-src
• Theme: twentytwentytwo v1.2
• Active Plugins:
  • debug-bar v1.1.3
  • WordPress-Core-Test-Team-Suite v0.0.2

Actual Results

• ✅ Critical issues count bubble is displayed on Site Health submenu item.
• ✅ One of the critical issues identified is the outdated PHP version (the count matches the Site Health page).

Additional Notes

• With the ​Health Check & Troubleshooting plugin enabled, the plugin overrides the bubble update applied with this patch (see ​https://cldup.com/yjtoLQLP8J.thumb.jpg for comparison).

Supplemental Artifacts

[ironprogrammer]

Test Report

Patch tested: attachment:56199-dashboard-widget.diff​ 👍🏻

Steps to Test

1. Configure environment to use PHP 5.6 (or less than PHP 7.2). Includes "lower than future minimum" (7.2) supported versions.
2. Navigate to Dashboard.
3. Observe PHP Update Required widget.
4. Configure environment to use PHP 7.2 (or PHP 7.3). Includes supported, but not recommended, PHP versions.
5. Navigate to Dashboard.
6. Observe PHP Update Recommended widget.

Expected Results

• ✅ Under PHP <7.2, the PHP Update Required widget displays an updated warning notice (exact PHP version indicated may differ):

Your site is running on an outdated version of PHP (5.6.40), which does not receive security updates and soon will not be supported by WordPress. Ensure that PHP is updated on your server as soon as possible. Otherwise you will not be able to upgrade WordPress.

• ✅ Under PHP 7.2 and 7.3, the PHP Update Recommended widget displays an updated warning notice (exact PHP version indicated may differ):

Your site is running on an outdated version of PHP (7.2.34), which does not receive security updates. It should be updated.

Environment

• OS: macOS 12.5.1
• Browser: Safari 15.6.1
• Browser: Google Chrome 105.0.5195.102
• Server: nginx/1.23.1
• PHP: 5.6.40, 7.2.34
• WordPress: 6.1-alpha-53344-src
• Theme: twentytwentytwo v1.2

Actual Results

• ✅ The PHP Update Required widget displays the updated security and WordPress upgrade warning.
• ✅ The PHP Update Recommended widget displays the updated security warning.

Supplemental Artifacts

Figure 1: PHP Update Required widget under PHP 5.6 (​compare with before patch)

Figure 2: PHP Update Recommended widget under PHP 7.2 (​compare with before patch)

[ironprogrammer]

Design Suggestions

While working on comment:26, I considered how these warnings could pop a little more. These suggestions borrow from existing dashboard widget styles:

Clearly Separate New and OId Text

To my eyes, the non-bold middle sentence (former H3) looks odd. This change keeps the question heading intact, but separate from the updated warning block.

Figure 1: Add separator and re-bold the former H3

Emphasize Warning

Draws more attention to critical state. Would suggest alternate "warning" yellow left border when PHP Update Recommended widget is shown.

Figure 2: Add "critical" red left border and re-bold the former H3

Emphasize Follow-up Info

Draws more attention to corrective information.

Figure 3: Add "info" blue left border and re-bold the former H3

[azaozz]

@ironprogrammer Thanks for the tests and the design suggestions! Both look good imho. This ticket is already set to "needs-design" also setting it to "needs-design-feedback" to hopefully get some design reviews or more ideas.

Frankly I'm not so sure about having the "What is PHP ..." question. It's obvious we are talking about PHP, not sure why it repeats it. The explanations blurb is enough to cover it, and the "action button" below is a good "attention grabbing" :)

As the tests pass thinking to commit these two patches and then refine the design as needed.

[azaozz]

Dashboard widget and Site Health warnings.

[azaozz]

In 56199.diff:

• Same as 56199-dashboard-widget.diff for the Dashboard.
• Added similar (but shorter) warnings for Site Health.

[azaozz]

In 54165:

Site health: Add a menu bubble with the critical issues count to the Tools -> Site Health submenu.

Props: Clorith
See: #56199

Show Site Health and Dasboard's ServerHappy warnings when the current PHP version will be lower than the minimum supported PHP version when bumped up in the near future.

Trac ticket: https://core.trac.wordpress.org/ticket/56199

[azaozz]

In 54169:

Site health:

• Add a check to wp_check_php_version() whether the current PHP version is lower than the next (desired) minimum version.
• Set the next desired minimum PHP version to 7.2.
• Use that check to update the warnings in the wp_dashboard_php_nag() widget, and on the Site Health screen.

Props Clorith, SergeyBiryukov, ironprogrammer, azaozz.
See #56199.

[Clorith]

I'm following up on the discussion, and intent, to also add a in-frequent email status to site administrators. I've unfortunately not had the time to get to that as I had hoped yet, and I Feel it's one of those things that will drum up some reactions, so it feels a bit tight to beta-1 to introduce at this stage, so I'm proposing moving that part of it to the next release, any other thoughts or takes on that?

[davidbaumwald]

Based on @clorith's last comment, the remaining needs for this ticket, and 6.1 Beta 1 releasing tomorrow, this is being moved to Future Release.

If any maintainer/committer wishes to assume ownership of this during a specific cycle, feel free to update the milestone at that time.

[azaozz]

Replying to Clorith:

I Feel it's one of those things that will drum up some reactions, so it feels a bit tight to beta-1 to introduce at this stage

Sounds good. Also thinking perhaps the emails can be implemented in the plugin first, and collect some feedback before adding to core.

[ababir]

Regarding Site Health's critical issue, we can add a yellow-colored border for the category of the issue. It will indicate a stable indication that this section needs attention. Right now, as it's blue-colored, it might look like the problem has already been solved.

In Site Health PHP version check results:

• Colorizes "critical" status results in red.
• Colorizes "recommended" status results in orange.
• Adds padding to give space between result description and status badge.

Trac ticket: https://core.trac.wordpress.org/ticket/56199

[ironprogrammer]

Great idea, @ababir! I've added badge border coloration according to the PHP version check result in ​PR #4536.

Testing Instructions

Steps to Test

1. Configure environment for an outdated version of PHP.
2. Navigate to Tools > Site Health.
3. Observe the border color for the PHP outdated notice badge. (See Figure 1.)

Expected Results

• ✅ If the result is critical (such as outdated PHP), the badge border will be red.
• ✅ If the result is recommended, the badge border will be orange.

Supplemental Artifacts

Figure 1: Example of outdated PHP 5.6 result.