Site Health should flag PHP versions in the dev-stable branch

[DionDesigns]

PHP always maintains two active branches, one called production-stable and one called development-stable (aka "bleeding edge").

Site Health should focus on getting sites to use the latest version of PHP in the production-stable branch, and flag sites using PHP versions in the bleeding edge branch. Some text could be displayed to the effect that WordPress may not be compatible with PHP versions in the “bleeding edge” branch, but WordPress will always be compatible with PHP versions in the production-stable branch.

This would also have the benefit of fewer PHP compatibility issues with plugins and themes.

[Clorith]

Site Health already does something fairly similar, it relies on the data from the ServeHappy data, which maintains a list of still maintained PHP versions, as well as WordPress' recommended version, used to display warnings within both Site Health's checks, but also on the admin dashboard in certain situations.

The endpoint for this is available at https://api.wordpress.org/core/serve-happy/1.0/?php_version=7.0.0

I'm not sure if we should do more with this, having the ability to control these numbers is important as the PHP project moves forward we obviously want to help move forward as well, but must be timely in pushing users to not cut anyone off, or cause unwanted concern with non-technical users.

[DionDesigns]

We have seen the issue I'm raising during the past two months, with users updating to the latest version of PHP and finding that WordPress no longer works. WordPress 5.8 will not even install if PHP 8.1 is active.

Yes, this issue will (I think) go away in a few days with the release of WordPress 5.9, but that isn't the point. With some minor changes in Site Health and the WP documentation, for most people the issue would have never occurred.

For example, statements such as "PHP 7.4 or later" should be avoided. Instead, for the release of WP 5.9, use "PHP 7.4 - 8.1" and make a statement to the effect that later versions of PHP may work, but this release of WordPress is only guaranteed to work with the versions of PHP that were available at the time of its release. If PHP 8.2 is released before WordPress 6.0, change the statement to "PHP 8.0 and 8.1" until WP6.0 is released.

You could even build the highest supported PHP release for each WP version into wp-includes/version.php:

$max_php_version = '8.1';

This could also allow a simple check during the install process to flag potential problems before they occur.

The text on ​https://wordpress.org/support/update-php/ states in several places that people should run "the latest version of PHP" -- including in a proposed letter to the user's hosting company. Perhaps these occurrences should changed to something like "the latest production-stable version of PHP", and make a statement near the top of the page (perhaps in boldface) such as "The latest version of PHP is in the development-stable branch, and while we make every effort to maintain compatibility with this branch, WordPress is not guaranteed to work correctly with it."

Anyway, I hope you see my point.