[DX] Drop support for php 5.6 - or change our policy re smallest version shipped with supported major linux distros

[klonos]

This is a follow-up issue to #3992

Backdrop core currently supports php versions from 5.6 and up (see the announcement), but there are certain cases where this becomes problematic. I am starting a register of such cases here, along with linked example issues in the core queue:

• type hinting of types other than objects and arrays: Deprecated function: mb_strlen(): Passing null to parameter #1 ($string) of type string is deprecated in mb_strlen() (line 479 of ../unicode.inc) #5890
• ???

PHP 5.6 has been EoL since 31 Dec 2018 (see https://www.php.net/eol.php), which means no official security fixes. However, LTS (long-term support) versions of various linux distributions being used by popular hosting providers have been backporting security fixes and major bug fixes to 5.6, so we couldn't exactly call 5.6 EoL and be done with it. Also, Zend seems to be providing a paid LTS service for any PHP version after and including 5.6: https://www.zend.com/services/php-long-term-support

---

Some stats (at the time of writing - Jan 2023). Let's try to keep these up to date as this issue here is being considered:

• https://packagist.org/php-statistics (showing roughly ~1% combined usage of all versions of php 7.0 and below in Jan 2023)
  
• https://w3techs.com/technologies/details/pl-php/all/all (apparently still not below 20% globally as of Jan 2023)
  
• https://wordpress.org/about/stats
  
• our own telemetry stats: https://backdropcms.org/project/backdrop/telemetry (showing only 2% of roughly 325 sites on php 5.6)

[klonos]

...I have tentatively set this task for the Backdrop 2.x milestone, which won't come before Jan 2025 (see the roadmap and the announcement). We may decide to reconsider sooner than that though.

Does D7 EoL affect this decision here at all? If so, then how?

This will need discussion/approval by the PMC.

[herbdool]

We are still following the policy of supporting the lowest version still supported by a Linux distro. See #3992 (comment).

So that looks like 7.2?

[klonos]

Yes @herbdool, that'd be right I believe 👍🏼

FTR, I'm adding here the table that @quicksketch had compiled back then:

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.

[klonos]

...and also FTR, here's what's currently being reported for the various php versions in our telemetry:

Value	Count	Percentage
7.1	1	0%
5.6	7	2%
7.0	14	4%
7.3	26	8%
8.1	33	10%
8.0	37	11%
7.2	45	13%
7.4	173	51%

[yorkshire-pudding]

• our own telemetry stats: https://backdropcms.org/project/backdrop/telemetry (showing only 2% of roughly 325 sites on php 5.6)

I wonder whether it is possible from the raw telemetry stats (or whether it would need to be added) to know what version of Backdrop someone using 5.6 is on; that would give some kind of indication as to the active management of the site. I guess we do know that they're on a version after telemetry was added.

It would also be interesting to understand why people are still on 5.6. My guess is inertia; nothings broke so nothing to fix and host not encouraging then to move.

[klonos]

I guess we do know that they're on a version after telemetry was added.

Yup, we can only assume 1.20+.

It would also be interesting to understand why people are still on 5.6. My guess is inertia; nothings broke so nothing to fix and host not encouraging then to move.

Yup, it's that. If you take a look at the version-specific table of our usage stats, you'll see that we have the same "problem" as our Drupal brethren: some sites seem to never be updated past their initial build (you can tell that by the roughly same amount of installations for each version over time), while some others take longer to be updated (slowly decreasing amount of installations over time).

There's also what I call the obvious "supported cluster" of sites in the table, and you can tell that by the trend where the previous releases counts seem to be dropping at about the same pace that the new releases count is rising:

I am assuming that certain site owners simply don't care past the initial release of their site. Perhaps it was a startup that never flourished. Perhaps they simply don't have the budget to keep updating their site, and it's relatively low-traffic that they simply take the risk of potential hacking. Perhaps the people that built the site prefer to have one-time customers, and they don't really bother explaining the need for regular updates (because it may be a demotivating factor for the sales pitch), and that is not part of their services 🤷🏼

[jenlampton]

I'm also in favor of waiting on removing support for PHP 5.6 until backdrop 2.0. (Perhaps at that point, our requirements can be updated to PHP 8?)

I'm concerned that existing Backdrop sites aren't going to be upgrading the PHP versions. Even if PHP 5 isn't supported, there will still be web hosts offering patched versions, and if there is other old software on the same instance it could be too much of a risk to update the PHP version just to support the Backdrop site.

[kiamlaluno]

I cannot say if my case is a minority, but the hosting provider I am using for my personal site added support for PHP 7.3 only the last month. If they add new PHP versions at the same "speed," I would be probably able to use PHP 8.0 on 2030.

[yorkshire-pudding]

My hosts supports from 5.2 to 8.2 using cPanel, so I hope it is a minority.

[klonos]

Yeah, lets keep this as a placeholder. I'll try my best to be keeping the stats/metrics up to date from time to time, and as suggested during this week's dev meeting, perhaps once we have a bigger percentage of sites with Telemetry enabled, perhaps we can make a better-informed decision then.