#2747 - PHP refresh (ongoing)
| Identifier | #2747 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | PHP refresh (ongoing) |
| Status | Open |
| Tags |
Roadmap: ongoing (custom) Roadmap: Over the horizon (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | When base line compat is for PHP 7.3...
Update CQC to be able to parse new syntax we don't necessarily intend to use right away: Trailing commas in parameters of function calls More Flexible Heredoc and Nowdoc Syntax Update phpstub.php new functions array_key_first() array_key_last() hrtime() is_countable() param changes setcookie() and setrawcookie() new signature When base line compat is for PHP 7.4... Update CQC to be able to parse new syntax we don't necessarily intend to use right away: Spread Operator in Array Expression Arrow Functions 2.0 Null Coalescing Assignment Operator Numeric Literal Separator New __serialize and __unserialize magic methods 'real' cast removed, and also is_real function Update phpstub.php param changes The preg_replace_callback() and preg_replace_callback_array() functions now accept an additional $flags argument strip_tags() now also accepts an array of allowed tags proc_open() now accepts an array instead of a string for the command; PHP will take care of any necessary argument escaping The allow_url_include ini directive is deprecated. Enabling it will generate a deprecation notice at startup When base line compat is for PHP 8.0... Enhance static typing Union types Implement PHP 8.2's Sensitive Parameter Value Redaction Support (we implement early knowing it won't do anything but won't create a parse error) Update CQC to be able to parse new syntax we don't necessarily intend to use right away: Named Arguments Attributes Constructor Property Promotion Union Types Match Expression Nullsafe Operator static (as in "late static binding") can now be used as a return type It is now possible to fetch the class name of an object using $object::class Traits can now define abstract private methods An optional trailing comma is now allowed in parameter lists Mixed type It is now possible to write catch (Exception) to catch an exception without storing it in a variable Update phpstub.php Add get_resource_id Add str_contains Add str_starts_with Add str_ends_with Add fdiv Add get_debug_type array_diff(), array_intersect() and their variations can now be used with a single array as argument When base line compat is for PHP 8.1... Update CQC to be able to parse new syntax we don't necessarily intend to use right away: Returning by reference from a void function 0o14; // Prefixed octal literal Array Unpacking with String Keys Named Argument After Argument Unpacking Enumerations First Class Callable Syntax Intersection Types Never type Readonly properties It is now possible to use new ClassName() expressions as the default value of a parameter, static variable, global constant initializers, and as attribute arguments. Objects can also be passed to define() now. Final class constants Update phpstub.php Add array_is_list Add fsync Add fdatasync fputcsv() now accepts a new eol argument which allow to define a custom End of Line sequence, the default remains the same and is "\n" When base line compat is for PHP 8.2... Make use of ini_parse_quantity Enhance static typing Specific "false" return type cms_strtolower_ascii and cms_strtoupper_ascii won't be needed, and we can remove the health check about Turkish locale (I think) Update CQC to be able to parse new syntax we don't necessarily intend to use right away: Constraints in traits Remove dynamic properties parsing support Readonly Classes Update phpstub.php Add ini_parse_quantity Add memory_reset_peak_usage as a comment (we don't need it) For each update... Update minimum version PHP version health check install.php restore.php.pre tut_web_hosting.txt Search the code for 'LEGACY' comments to resolve |
| Steps to reproduce | |
| Additional information | When raising our minimum version, we may consider what is the minimum version of PHP still supported. However realistically we also need to consider that webhosts often fail to upgrade to newer versions, and people may be on different versions supplied by popular Red Hat distributions - which back port security fixes. So, proceed with some detailed consideration. |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".


Comments
https://wiki.php.net/rfc/always_enable_json
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.
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.
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.
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).