[wp-trac] [WordPress Trac] #50455: wp_check_php_version() does not account for backporting and therefore leads to confusing user messages about PHP security

WordPress Trac noreply at wordpress.org
Tue Jun 23 14:18:25 UTC 2020


#50455: wp_check_php_version() does not account for backporting and therefore leads
to confusing user messages about PHP security
--------------------------+---------------------------------
 Reporter:  robert.peake  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Site Health   |     Version:  5.1
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:  ui, administration
--------------------------+---------------------------------
Changes (by Clorith):

 * keywords:   => close
 * version:  5.4.2 => 5.1


Comment:

 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 [https://www.php.net/supported-versions.php
 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
 [https://developer.wordpress.org/reference/hooks/wp_is_php_version_acceptable/
 wp_is_php_version_acceptable filter], but also the more generic
 [https://developer.wordpress.org/reference/hooks/http_response/
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50455#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list