In a future version we can remove the Health Check for JSON support, if this RFC passes (and I think it will):
https://wiki.php.net/rfc/always_enable_json

I've reviewed the situation of people being stuck on older PHP versions.

Linux distributions...

I've only looked at distributions with a half-realistic chance of someone wanting to run a webserver.
Often distributions will update the PHP version as a part of their support cycle. i.e. distro version X will not stay on PHP version Y, it'll get updated during the support cycle.

Fedora:

We can check PHP support at https://dl.fedoraproject.org/pub/fedora/linux/releases/32/Everything/x86_64/os/Packages/p/ ; change "32" to whatever is latest Fedora (https://en.wikipedia.org/wiki/Fedora_version_history)
At time of writing it is PHP 7.4 for version 32.
Popular for servers, and people may be on older releases. The oldest supported (version 31) is PHP 7.3.

CentOS (and RHEL):

CentOS and RHEL basically have the same version numbers.
We can check PHP support at http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/ ; change "8" to whatever is latest CentOS (https://en.wikipedia.org/wiki/CentOS#CentOS_releases)
At time of writing it is PHP 7.3 for version 8.
Popular for servers, and people may be on older releases. The oldest supported soon (version 7) is PHP 5.4.
There are always unofficial repositories with newer PHP versions though, and you can always hand-install.

Debian:

We can check PHP support at https://packages.debian.org/stable/allpackages?format=txt.gz
At time of writing it is PHP 7.3 for buster.

Ubuntu (and LinuxMint and Elementary OS):

We can check PHP support at https://packages.ubuntu.com/focal/allpackages?format=txt.gz ; change "focal" to whatever is latest Ubuntu (https://en.wikipedia.org/wiki/Ubuntu_version_history)
At time of writing it is PHP 7.4 for focal.

Raspbian:

We can check PHP support at http://archive.raspbian.org/raspbian/dists/stable/main/binary-armhf/Packages
At time of writing it is PHP 7.3 for 1.4.

OpenSUSE:

We can check PHP support at http://download.opensuse.org/distribution/openSUSE-stable/repo/oss/INDEX.gz
At time of writing it is PHP 7.4 for 15.2 (Leap release).
There is also a rolling release.

Slackware:

We can check PHP support at http://slackware.mirrors.tds.net/pub/slackware/slackware64-current/PACKAGES.TXT
At time of writing it is PHP 7.4 for 14.2.

Manjaro:
This is on a rolling release.

MacOS...

PHP 7.3 is included with Big Sur (latest MacOS). But it also will not be in future MacOS (https://twitter.com/GrahamJCampbell/status/1295111982924861442).
In HomeBrew it is PHP 7.4 (https://formulae.brew.sh/formula/php).

Hosting control panels...

cPanel (and WHM which manages it) is extremely dominant, even more so nowadays.
For a long times cPanel ships EasyApache. While this is optional, most hosts are going to use it to allow users to pick their own PHP version. EasyApache states they follow PHP's own support planning for what PHP versions to make available.
I can only see an issue with users on very old webhosts where WHM/cPanel/EasyApache has not been properly maintained - which can be resolved easily if it is a VPS, or is a bigger problem if it is shared hosting.



In summary, everyone nowadays is using a pretty decent version, except for servers that have essentially been abandoned. And such servers should have a newer PHP installed via some other method, or replaced.

Actually I heard Amazon Linux (based on RHEL) has only PHP 5.4 :(.

v11 is now requiring PHP 7.1.
The CQC now scans for 7.1 compatibility.
PHP type hints have now been universally applied across the codebase.
ocProducts PHP automatically makes any type hint strict.
I've fixed a tonne of errors where our phpdoc was inconstant, and now our tests all pass.
It's really nice to have strict type across the codebase finally. I was one of the people pushing for PHP to adopt strict types way back before it was approved, as we'd already had a different kind of strict typing in Composr and it had worked well for us. Now we finally get the bug-detection benefit of this.

I don't think I'll keep updating all the way to 7.3. There's no major advantage to do that, other than seeming more modern - and I think 7.1 is good enough from that point of view given we need to be moving to getting v11 finished! 7.1 was necessary over 7.0 as we needed "type nullability" for us to reasonably use the type hints.

Actually PHP 7.1 doesn't support object type hints, so we are already needing PHP 7.2+. So I am moving us towards that as a base.

As of today, PHP does not support any versions below 8, and version 8.0 is security fixes only. Any reason we should continue supporting 7.2, or could we bump to 7.4 which is the oldest version I've seen being run on 99% of servers today.

The only reason I can think of to stay on 7.2 is for CentOS 7/8, but both are being discontinued in June 2024.

NTS:

Bump compat to 7.4 in June 2024 (unless v11 already hit beta status by then which is highly unlikely). 99% of servers will be on 7.4 or later by this point once Centos 7/8 is discontinued. So I think it'll be good to get CQC and php_stub up to spec in those regards.

both 7.4 and 8.0 are EOL by PHP devs anyway. So I think that's a good fitting... support 2-3 minor versions behind the oldest supported PHP version.

Do NOT close this issue when done; unassign self instead.

EDIT: Okay I was wrong, it's about 92% of sites will run / are running 7.4 or later according to an estimate: https://stitcher.io/blog/php-version-stats-january-2024 . But we may want to define a good standard, perhaps the 3% mark as a foundation. So I'd estimate 7.3 will drop below 3% by June 2024 according to these estimates, further justifying a compat of 7.4. I think 7.4 would be a good compat because many people are still using 7.4 for fear 8.0 will break site code (and rightfully so; v8 has a lot of deprecations).