wp_check_php_version() does not account for backporting and therefore leads to confusing user messages about PHP security

[robert.peake]

The function wp_check_php_version, which drives the PHP update nag in the admin, relies on ​http://api.wordpress.org/core/serve-happy/1.0/ but only passes in the version of PHP to the API.

This does not account for the security practices of distributions such as RedHat or CentOS, which apply backporting to the versions of PHP that they support to maintain older versions as secure: ​https://access.redhat.com/security/updates/backporting

As a result, the message is confusing to admin users who are unaware of the underlying operating system in use or of backporting.

OS distribution types are easily discovered in PHP, and could be passed to the API to check whether backporting were in place to suppress the nag.

While it is possible to use remove_meta_box on a case-by-case basis, it would be better if this were supported by core, i.e. a misleading message were not displayed in the first place, rather than special measures being taken to suppress it.

RedHat and CentOS together represent 20% market share of all linux distributions, and linux represents the vast majority of web servers running WordPress. This is therefore a widespread issue.

[Clorith]

Hiya,

So you are correct in that it disregards distros who create their own custom backports for security patches.

Firstly, this was discussed before the ServeHappy dashboard widget was introduced, but it's there to move PHP usage, not specifically security (although they do go hand in hand). Helping users recognize there's something they should and could do to improve performance and stability of their site is the bigger goal here.

On top of that, it's just not feasible to keep track of what distros, and which distro-specific versions, are considered "up to date" in terms of security at any given time. It's then better to base it on the PHP version numbers and their overview of ​supported versions as a single source of truth for this.

All of that said, if you are a hosting provider, running a distro that's known for doing this, there are filters in place to accommodate such scenarios so you can mark what is considered a secure release;

Specifically ​wp_is_php_version_acceptable filter, but also the more generic ​http_response filter used for remote requests.

In light of the above, I'm leaning towards closing this as wontfix, but I'm interested in hearing any suggestions for how it may be improved upon still.

[robert.peake]

A quick-and-dirty fix could go like this:

<?php
function backport_remove_php_nag() {
    if (strtolower(substr(PHP_OS, 0, 5)) === 'linux') {
        $files = glob('/etc/*-release');
        $first_file = $files[0];
        $contents = file_get_contents($first_file);
        if (false !== strstr($contents, 'CentOS') || false !== strstr($contents, 'RedHat') || false !== strstr($contents, 'Fedora')) {
            remove_meta_box( 'dashboard_php_nag', 'dashboard', 'normal' );
        }
    }
}
add_action( 'wp_dashboard_setup', 'backport_remove_php_nag' );

Obviously, you could set a transient so you don't have to open a file with every admin page load to find the distro, build out a proper list of distros that engage in backporting, and let the API maintain this logic rather than using case structure in the code.

This simple approach assumes that if you encounter a distro that does backporting, "all bets are off". It is the hosting provider's job to make sure the distro itself is up to date (and therefore any backport updates applied).

I understand your desire to "move PHP usage". But in current form, you are telling somewhere on the order of 10-20% of admin users (many of whom have no idea what PHP is,which is why you include a description to help them) that "WordPress has detected that your site is running on an insecure version of PHP."

In the case of backporting distros, that is clearly misleading, if not a bit alarmist. Even just using the above logic to alter the phrasing would help countless hosting providers have more rational conversations with their customers.

[Clorith]

I'm afraid I'm not convinced here, putting such an administrative burden on us to know what distros backport, which versions of distros backport what versions, what about those specialized distros that aren't mainstream but still used, not to mention hoping hosts are applying backports, it is just not feasible I believe.

Adding on that the aim of the Site Health is to let users self-service their site, if there's a potential for their site running insecure software, the user should know, and have the option of engaging their host, or finding a new one if such an engagement doesn't end as expected.

Is this a popular stand to take for those who apply backports? Absolutely not, but at the same time such hosts could utilize the filters in place to reflect that their version of PHP is acceptable.

There are multiple ways they can do this, either by changing the test using the site_status_tests filter, changing the result of the check using the site_status_test_result filter, or maybe even filtering the ServeHappy API lookup directly using the http_response filter.

[Clorith]

As there hasn't been any new movement here in a while, I'm going to close the ticket for now.

It is of course still possible to continue discussion even on a closed ticket to see if some new information comes to light, and the ticket can be re-opened for consideration at such a time.