Drop support for PHP versions less than 5.6.

[klonos]

Sibling issue to #214 (I thought we already had one for this, but I could not find anything).

None of the tools that I use to set up local environments (ddev, lando etc) support php versions below 5.6, which makes it hard for me to test things when there are failures in my PRs for php53, but not for php70.

Here's a few stats from around the net, to help us decide...

https://blog.packagist.com/php-versions-stats-2019-1-edition

A few observations: PHP 7.3 is growing almost as well as 7.2 last year. With PHP 5.6 and 7.0 reaching end of life at the end of 2018, the number of people using maintained PHP versions dropped to 80% (from 84%), which is really not as bad as I expected as 31% of people had to upgrade. PHP 5 usage across all versions is now around 10%.

https://w3techs.com/technologies/details/pl-php/all/all

https://w3techs.com/technologies/details/pl-php/5/all

https://wordpress.org/about/stats

---

• Initial warning PR: Issue #3992: Provide warning that PHP versions prior to 5.6 will be dropped soon. backdrop#3881
• Actual increase of minimum version in bootstrap.inc: Issue #3992: Increase minimum PHP version to 5.6. backdrop#3922

[klonos]

...it's also worth mentioning that both php 5.6 and php 7.0 have been EoL for a while, and php 7.1 will be EoL by the end of the year.

[indigoxela]

both php 5.6 and php 7.0 have been EoL for a while

While that's correct regarding php.net, it's only half of the truth. ;)

Some Linux distributions still maintain older php versions and take care of security backports (think of CentOS 6 or Debian LTS).

...makes it hard for me to test things when there are failures in my PRs for php53...

So true! Unless using CentOS 6 (which has php53 as default), it's hard to get PHP older than 5.6 but still maintained.

[klonos]

Now that #285 is in core, we should be able to make a better-informed decision (once we have gathered enough metrics that is).

[klonos]

Stats update:

• https://blog.packagist.com/php-versions-stats-2021-1-edition
  
• https://w3techs.com/technologies/details/pl-php
  
• https://w3techs.com/technologies/details/pl-php/5
  
• https://wordpress.org/about/stats
  • 5.6 -> 8.3%
  • 5.5 -> 0.8%
  • 5.4 -> 1.1%
  • 5.3 -> 1.2%
  • 5.2 -> 0.5%

[klonos]

...I'd say that it's safe to deduct that the percentage of the internet still stuck with php5.5 and earlier is less than 15%.

[philsward]

Take into consideration people who have the ability to upgrade, but don't know they can or don't think they can, so they stay on older versions.

I'm all for stepping up the requirements. For anyone migrating from D7 over the next few years, I think even making the requirement set to 7, won't affect many people overall. If the requirement for Backdrop is php7, and someone needs to migrate, the migration is the perfect time to update the platform anyway.

I don't know if there is a way for telemetry to "ask" for all supported versions on the system or not, but if that is a possibility, it would be good to collect the used version of PHP as well as the available versions to the system to get a better idea of how many people are on an older version but have direct access to a newer version. CPanel and Plesk for example allow multiple versions on the same system.

Long story short, I'm all for tightening up the minimum requirements and would prefer to see it tightened up even further to v7. We are finally in a day-and-age where the minimum version isn't the target, but rather the latest working version that won't break things is the desired target on account of the speed boosts each newer version provides.

Also, if we can add telemetry to the Backdrop Upgrade Status module for D7, we would have a better idea of the hurdles this discussion might have for D7 migrations, helping even further to make an informed decision.

[klonos]

Also, if we can add telemetry to the Backdrop Upgrade Status module for D7, we would have a better idea of the hurdles this discussion might have for D7 migrations, helping even further to make an informed decision.

That's a good idea/point 👍🏼

[quicksketch]

I couldn't find my old issue where I laid out our PHP version policy, but the previous policy had been to support the oldest still-supported version of PHP provided by a Linux distribution. Here's a new table of default PHP versions by distribution:

Distro	Release Date	EOL Date	PHP Version
CentOS 6	2011-07-10	2020-11-30	5.3
CentOS 7	2014-07-07	2024-06-30	5.4
CentOS 8	2019-09-24	2021-12-31*	7.3
RHEL 6	2010-11-10	2020-11-30	5.3
RHEL 7	2014-06-10	2021-08-30	5.4
RHEL 8	2019-05-07	2029	7.3
Debian 8	2015-04-25	2020-06-30	5.6
Debian 9	2017-06-17	2022-06-30	7.0
Debian 10	2019-07-06	2024-06	7.2
Debian 11	2021-08-14	2026-06	7.4

*CentOS 8 were discontinued by RedHat, and the planned 10-year support cycle will be cut-off at the end of 2021 instead.

Ubuntu more or less follows the same support cycle as Debian, so I didn't include it here.

Due to the extremely long cycles of CentOS, that previously had been our benchmark which version of PHP we support. Since CentOS 6 went EOL last year, we should have at least bumped up to PHP 5.4 as the minimum version.

If we were to stick with the current policy, CentOS 7 is the limiting OS with PHP 5.4 as the default. However, the popularity of CentOS has waned quite a bit in recent years and is now discontinued. I think the compromise of bumping up to 5.6 would be a good one.

[philsward]

Going to reiterate telemetry. Short term I think 5.6 is a good compromise but over the next two years, I suggest we start leaning on what telemetry tells us is appropriate.

There's also the EoL of the PHP version as well that I feel is more important than the minimum an OS can handle.

PHP 5.6 is EoL, making 7.3 the oldest we should "probably" support that is (keyword) secure.

https://www.php.net/supported-versions.php

Telemetry

[quicksketch]

There's also the EoL of the PHP version as well that I feel is more important than the minimum an OS can handle.
PHP 5.6 is EoL, making 7.3 the oldest we should "probably" support that is (keyword) secure.

Both Debian and RedHat backport security fixes into their supported PHP versions. PHP itself might not support versions more than 2 years old, but the support cycles are longer for OSes, with averages of 5 years for Debian and 10 years for RedHat. During that time period, each vendor is backporting security fixes into their respective supported versions.

Debian example: https://unix.stackexchange.com/questions/599757/php-security-updates-in-debian-after-php-version-eol
RedHat example: https://access.redhat.com/security/updates/backporting

I agree that Telemetry will probably be the guiding factor long-term, but I want to clarify that "not supported by the PHP community" does not necessarily mean "not secure", since OS vendors are doing extra work to make their LTS releases both stable and secure.

[indigoxela]

...the previous policy had been to support the oldest still-supported version of PHP provided by a Linux distribution

That absolutely makes sense to me.

My additonal 2c:

1. It's fancy, that CentOS 7 will (apparently) survive CentOS 8 - but even if we "only" raise the minimal supported PHP version in Backdrop to 5.4, developer lifes already get slightly easier (AlmaLinux starts with version 8, so is not relevant here (yet))

2. Additionally to the official PHP versions, Debian and Ubuntu also have the sury repo, security backports for php5.6+ get provided by Microsoft

3. The Github Action we use for automated tests allows us to choose between (and including) 5.3 to 8.2, but local dev setups probably can't have anything below 5.6 without some effort (like local compiling)

So my personal conclusion is: 5.3 doesn't really have to be considered anymore. When Backdrop was released, the oldest supported version of PHP (by php.net) was 5.4 (correct me if I'm wrong, I'm not 100% sure).

There might be concerns regarding "make migrations from Drupal to Backdrop as easy as possible" - but should that include supporting ancient PHP versions? Is there actually a real benefit? Current D7 patches get checked against PHP 7 - is that correct?

Some material for discussion in today's LIVE event. 😄

[klonos]

I believe that if we are limited to only 2 versions on php, then these should be php7 and php8 going forward. Can we do 3 major versions? (i.e. whichever minimum 5.x we decide to support / php7 / php8)

[quicksketch]

Can we do 3 major versions? (i.e. whichever minimum 5.x we decide to support / php7 / php8)

I don't think we should make a selection based on major versions because PHP's major release cycle isn't consistent or predictable.

[indigoxela]

@klonos we can run tests on as many php versions we want. The limit to consider, though is the limit of max concurrent runners (20) in our GHA free plan.

And personally, I think that running more than two (for example, the oldest and newest supported by B) is a waste of resources and an unnecessary increase of our carbon footprint. 😉

[indigoxela]

Updated stats from https://wordpress.org/about/stats (our own telemetry isn't useful yet):

There's still a significant use of PHP 5.6, but lower versions than that seems to be a peripheral phenomenon.

[herbdool]

Reading through the comments it seems that nobody is opposed to the main suggestion: drop support for PHP below 5.6.

There are other good discussions but perhaps new issues can be created for those.

[quicksketch]

I agree with this approach. Let's start with dropping support below PHP 5.6.

I'd love if the PMC can confirm this is acceptable, since it's a direct question as to how far we pursue our backwards-compatibility principle.

We'll need a longer runway than 1.21.0 though. I would prefer to commit this as an early change in the 1.22.0 cycle (meaning we'd drop support May 15, 2022)

[indigoxela]

It seems to be something about file system permissions.

Strange, no files can get written - not in the files directory, not even temporary. Maybe the GHA setup (php.ini?) needs tweaks. Will have a look ASAP.

[indigoxela]

I can fix the file permission problem for php: PR.

But there's more going on which I can't fix.

In the first test fraction I get a bunch of "Class not found" errors - no clue why.
https://github.com/backdrop/backdrop/runs/5048318802?check_suite_focus=true

In the "Setup Webserver" section of that run I tried to debug php a bit more - a list of loaded modules (php -m) and the full php.ini file. Still no idea, what might be the cause.

[indigoxela]

That's a general problem with our tests! Even if "tests are green", there are actually all these "class not found" errors (mostly with tests in core/modules/system/tests/system.test it seems). Also on other php versions in our GHA, also on my local dev - with any php version. It's only that php 5.6 now chokes on these.

[klonos]

Hmm. Not good 🤔

[indigoxela]

I opened a separate issue for that: #5490

Hm... should I include the fix for GHA (php fpm setup) in that other PR?

[klonos]

should I include the fix for GHA (php fpm setup) in that other PR?

I just tested and RTBC'ed the PR for #5490, and I plan to bring it up during the dev meeting later today, so I expect it to be merged soon. Then all you'll need to do is rebase the GHA PR 😉

[quicksketch]

Thank you SO MUCH @indigoxela! I couldn't figure out why this was GHA-specific, but that fix in .github/misc/setup-php-fpm.sh explains it! I incorporated your fix into my PR at backdrop/backdrop#3922.

I also had to restore the GD imagerotate() work-around, as PHP 5.6 on GHA gets a different result than my local and newer versions of PHP 7. All tests should now be passing in the PR!

[indigoxela]

@quicksketch the code looks good, I've left some additional questions (comments) on your PR.

[indigoxela]

Regarding my questions about the possible remove of the error control operator: it's probably OK to leave them in place. They don't break anything - removing on the other hand could possibly (although it's unlikely).

There's actually nothing to actively test here. RTBC! 👍

[ghost]

Based on @indigoxela's RTBC label, and @quicksketch's comments in today's meeting re. just merging this in. I've gone ahead and done so.

Thanks to @quicksketch, @klonos, @indigoxela & @herbdool for the PR and reviews. Thanks also to everyone else for contributing and giving feedback. I've merged backdrop/backdrop#3922 into 1.x.

[quicksketch]

Thanks @indigoxela and @BWPanda!