Track PHP 8.1 support in hosting and distributions

Ubuntu

Ubuntu has a good track record of getting the latest PHP version into their LTS releases:
- PHP 5.5 was released in June 2013 and made it into Ubuntu 14.04.
- PHP 7.0 was released in December 2015 and made it into Ubuntu 16.04.
- PHP 7.2 was released in November 2017 and made it into Ubuntu 18.04.
- PHP 7.4 was released in November 2019 and made it into Ubuntu 20.04.

It's a pretty reasonable guess that PHP 8.1 will make it into Ubuntu 22.04, but we won't know until some time between PHP 8.1's release (November 2021) and Ubuntu's release (April 2022).

RHEL

RHEL has app streams, so they can get a new a PHP version into any RHEL's minor versions (released in May and November). Their track record so far is:
- PHP 7.2 in RHEL 8.0, released May 2019
- PHP 7.3 in RHEL 8.1, released Nov. 2019
- PHP 7.4 in RHEL 8.3, released Nov. 2020

If this pattern continues, they'll get PHP 8.0 in Nov. 2021 and PHP 8.1 in Nov. 2022. If that's the case, and if Drupal 10.0 releases in June 2022, that means a PHP 8.1 requirement will mean that RHEL users will need to either wait until November before they can use Drupal 10, or have to install PHP 8.1 themselves.

Debian

- Debian 11 (bullseye) is planned to be released August 14, 2021 with PHP 7.4.

So if Drupal 10 requires at least PHP 8, then whether it's 8.0 or 8.1 won't affect Debian users much. They'll need to custom install it on Debian 11, and chances are that Debian 12 (2023) will have at least PHP 8.1.

Besides distributions, the other consideration is hosting companies. I think it's very likely that many hosting companies will not offer PHP 8.1 by June 2022.

However, I think there are also a lot of compelling reasons to start Drupal 10 with a PHP 8.1 minimum. Mostly because we don't have much success yet with dropping support for a PHP version in a Drupal minor, and I don't think we'll be able to support PHP 8.0 for all of Drupal 10's lifetime.

There's a mostly complete list of php extensions that already compatible with 8.1 - remi repo for redhat OSes https://github.com/remicollet/remirepo/issues/177

https://webhostingcat.com/what-version-of-php-does-your-web-hosting-comp... lists 21 hosting companies (some are Wordpress-specific, most are generic), including most of the biggest ones. Of those, 7 offer PHP 8.0 while 14 still have PHP 7.4 as the maximum. However, that was last updated in March. I did quick Google searching on those 14 and found that 4 of them now also offer PHP 8.0:

• Dreamhost
• Hostinger
• HostPapa
• Media Temple

Assuming the other items in that list are accurate (I did not check), that puts 11 of them at PHP 8.0 and 10 at PHP 7.4, or pretty much 50/50.

Not sure how good a proxy that is for where these companies will be next year around this time. Perhaps that means also a 50/50 split between 8.1 and 8.0? Unless we think that 8.1 uptake will be either faster or slower than 8.0?

I guess a related question is: is 50% hosting company support good enough? Let's say that means 50% of D9 users (note that user percentage doesn't necessarily correlate with hosting company percentage, depending on what percentage of Drupal site owners each of these companies serves) have the option of upgrading to D10 within a couple months of it coming out, while the other 50% maybe need to wait up to a year, is that ok? D9 will still be supported during that wait.

One reason we want fast adoption of D10 is to create more incentive for contrib maintainers to make sure their modules work on D10, either before 10.0 is released, or as soon after as possible. If a given contrib project doesn't have a large enough D10 user base, then that maintainer might still be too busy working on D9 projects and not have enough interest/time to put into D10 testing/fixing. Which then creates a negative feedback loop since it holds up more users from upgrading. But it's a non-linear relationship: the difference between having 25% of users on D10 vs. 0% is obviously significant, but with respect to porting a contrib modules, how much of a difference does say 50% or 80% vs. 25% make? At some point, there's a threshold of enough users to provide the needed incentive, though what that threshold is probably varies from module to module.

I can see an argument to be made for playing it safe, keeping the minimum to 8.0, and thereby encouraging maximum early adoption of Drupal 10. But I can equally see an argument for saying that enough people will have access to PHP 8.1 that we'll still get good enough Drupal 10 adoption in 2022, and that it's perfectly ok for people on slow-PHP-adopting hosting companies to not upgrade to Drupal 10 until 2023.

Just used to upgrade Ubuntu to 20.10 (dev) and php7 been replaced by php8

But I can equally see an argument for saying that enough people will have access to PHP 8.1 that we'll still get good enough Drupal 10 adoption in 2022, and that it's perfectly ok for people on slow-PHP-adopting hosting companies to not upgrade to Drupal 10 until 2023.

It's also fairly likely that at least some hosting companies will start offering PHP 8.1 quicker because we require it, especially if we announce soon that we're going to do so.

Note that a lot of (shared) hosting companies use software like Plesk and cPanel to run their hosting business. These both fairly quickly keep pace with PHP version releases, so that will inevitably mean that PHP 8.1 support will be possible with a good chunk of hosting providers even if they don't advertise it at first.

#3252386: Use PHP attributes instead of doctrine annotations would mean requiring PHP 8.1 (if we don't want to fork doctrine annotations to core if/when it becomes unsupported by the time Drupal 11 is EOL), which is the first real blocking reason to require PHP 8.1. Even if we somehow decided to fork annotations for now and try to switch in Drupal 10, we wouldn't be able to convert any nested annotations in core (or contrib) without requiring PHP 8.1 because it's a syntax error on PHP 8.

I revisited the blog post @effulgentsia looked at in #3223435-7: Track PHP 8.1 support in hosting and distributions, which has been updated for January 2022.

August 2021:

PHP 8.0: 11
PHP 7.4: 10

January 2022:

PHP 8.1: 6
PHP 8.0: 8
PHP 7.4: 5

So approximately six hosts have gone from PHP 8 to 8.1, and five have gone from PHP 7.4 to PHP 8.1 (didn't look at individual entries to see if there was any leapfrogging happening), in less than six months.

If the hosts continue on roughly that scale of movement, we'd be looking at something like a 50/50 split between PHP 8 and PHP 8.1 in June, and then close to 100% on PHP 8.1 or higher this time next year (i.e. most of these hosts supporting 8.1 by or shortly after 8.2 is released).

If we compare that extremely ballpark projection to the release windows, then it's something like 50%, 75%, 90% of hosts supporting PHP 8.1 when we release.

Some of the shared providers are a bit cagey about which versions they support, or their docs are so out of date they talk about PHP 5, but Dreamhost has an overview posted in September 2021: https://help.dreamhost.com/hc/en-us/articles/215082337-What-versions-of-... It looks like they aim to support the three supported PHP versions at any one time, but haven't switched to 7.4-8.1 yet.

I personally think these numbers are encouraging and support just saying we'll require PHP 8.1 now. The earlier we commit to it, the more time there is to do things like update contrib modules for PHP 8.1 compatibility. It doesn't look like shared hosting is going to be the thing that blocks people updating, or not for very long.

If we're going to switch to annotations, we need that available in Drupal 9 as an API, so really need to make a decision to unblock that work.

Please stop making posts about the language features of 8.1. This issue is only for gathering data on the availability of PHP 8.1 in distros, hosting providers, and the Composer ecosystem. I am going to unpublish comments that do not contain data. Thanks!

BOA LEMP stack by Omega8.cc supports PHP 8.1, 8.0, 7.4 (also older versions for legacy sites), configurable per site: https://twitter.com/omega8cc/status/1484498430005235713?s=20

I searched http://web.archive.org/ for the article in #7, and found that according to that article, shared hosting company adoption (among the ~20 sampled in that article) of PHP 7.4 in 2020 was much faster than for PHP 8.0 in 2021.

July 2020: 75%
October 2020: 100%

What we don't know is whether adoption of PHP 8.1 in 2022 will be more like 7.4 in 2020 or more like 8.0 in 2021.

One factor that might have driven faster adoption of PHP 7.4 in 2020 was that WordPress listed that as a recommendation in June 2020, along with a recommendation for customers of shared hosting companies to bug those companies about it.

However, WordPress has not yet updated that recommendation from 7.4. I don't know if they plan on doing so in 2022, and if so, when during the year, and if they'll bump it to 8.0 or skip straight to 8.1.

https://make.wordpress.org/core/2022/01/10/wordpress-5-9-and-php-8-0-8-1/ lists some remaining issues of WordPress 5.9 (currently in RC) with PHP 8.1. They note they'll work on those for WordPress 6.0, but that release is at least a few months away.

With respect to Linux distros, following up on #4...

Debian 11 ("Bullseye") shipped in August 2021, with PHP 7.4.
Debian does releases every 2ish years, so Debian 12 ("Bookworm") will likely be released in 2023. It already has PHP 8.1, though there's always the chance of them reverting it during testing (as they reverted PHP 8.0 to 7.4 for the Debian 11 release).

Ubuntu 20.04 ("focal") shipped in April 2020, with PHP 7.4.
Ubuntu 22.04 ("jammy") is a few months from release and currently has both PHP 8.0 and 8.1 (according to that link), but I would expect them to remove one of them prior to release. Per #4, their track record for their LTS releases is to release with the latest, so I'd expect them to release with 8.1 unless they run into problems with it.

RHEL 8 did not continue their track record of incrementing their PHP version in November. Their November 2021 release stayed on PHP 7.4. Though perhaps that's a blessing, because now they're saying they'll support PHP 7.4 for the remainder of RHEL 8's life (until 2029), implying they won't release any more PHP versions to the RHEL 8 app stream.

Meanwhile, RHEL 9 is in beta and has PHP 8.0. They might still change that between now and release, though they did not change their PHP version (7.2) between RHEL 8.0 beta and its release. If they follow a similar pattern as they did for RHEL 8, that would mean a RHEL 9.0 in May 2022 with PHP 8.0, and then a RHEL 9.1 release in November 2022 with PHP 8.1 added, but 8.0 still supported until May 2024.

I wonder if that latter part should be a concern for us. If RHEL 9 supports PHP 8.0 until May 2024, but Drupal 9 EOLs in Nov 2023, then does that mean we want to accommodate Drupal 9 users on PHP 8.0 being able to upgrade to Drupal 10 prior to Drupal 9's EOL but without changing their PHP version? I can see an argument for us wanting to accommodate that, especially for environments (e.g., at universities) where the site owner doesn't control the server's PHP version. On the other hand, with RHEL app streams, changing the PHP version is an easy one line command (as long as you have admin permission to the server), and you still get a fully RHEL-managed PHP version (it's not like it was for RHEL 7, or still is for Ubuntu, where doing so required you to move from RHEL's package to a less trustworthy 3rd party package).

does that mean we want to accommodate Drupal 9 users on PHP 8.0 being able to upgrade to Drupal 10 prior to Drupal 9's EOL but without changing their PHP version?

If RHEL 8 indeed ends up maxing out at PHP 7.4, then I think the bigger scenario we'll run into is Drupal 9 sites on servers that are stuck on PHP 7.4, but we're definitely not accommodating that.

I've found that the version released in an OS or provided by a hosting provider is a chicken & egg situation or like playing chicken on a bicycle. We look at what they require, they look at what we require and whoever blinks first, that becomes the new standard.

As far as "official" version provided by an OS, the ease of switching that version has only gotten easier as PHP's version velocity has accelerated the last few years. There are dozens, if not hundreds of blog posts how to install PHP 8.0 on ubuntu, debian, RHEL etc within days and weeks after 8.0 is released.

The big sticky point is the hosting providers. But if they are given sufficient lead time, they should be able to ramp up support for more modern versions of PHP on a timely schedule.

PHP 8.1 is not supported by Pantheon.
Actually they do not fully support PHP 8.0 yet.

If RHEL 8 indeed ends up maxing out at PHP 7.4, then I think the bigger scenario we'll run into is Drupal 9 sites on servers that are stuck on PHP 7.4, but we're definitely not accommodating that.

We might want some documentation on the two options out of this situation (update the server in-place vs. put the codebase on a new server, import the database, rsync the files over, and update there, switch the DNS), how to tell hosts you're stuck etc. I can't see anything under https://www.drupal.org/docs/upgrading-drupal/ specifically dealing with this, it just says ensure you're on the correct platform requirements.

The overall issue we have is that some hosts and PHP projects have adapted to the new PHP release cycle, and some have not. iirc it's only PHP 7.1 which introduced the new three year cycle, which is a long time if you count from its release in December 2016, but not so much if you count from its EOL in December 2019.

Also that with the PHP cycle itself there's no LTS release concept. if PHP 7.4 and 8.1 were both LTSs, you could predict that sites and hosts will stay on 7.4 then jump to 8.1, but because there's nothing like this, you get the roughly 1/3rd split between 7.4, 8.0 and 8.1 in #3223435-14: Track PHP 8.1 support in hosting and distributions, and it's not clear which version the remaining 7.4 hosts will update to, or on what schedule the PHP 8.0 hosts will update etc.

@Chi do you have a reference for Pantheon not fully supporting PHP 8.0 yet?

Is it means, that policy should be updated because amount of cloud deployments should be bigger then redhat of all kinds?

Id D10 can keep 3 year cycle pace of PHP? otherwise 9.4 could be used by hostings on RHEL/centos (both mostly different nowadays)

Data for individual HSPs can be added and tracked in the child issue: #3261443: [tracking issue] Track hosting provider support for PHP 8+

(We keep that in a separate issue because we want to keep the noise there to a minimum, since it will be promoted to the wider community for their data.)

I opened up support tickets to a handful of the (what felt like to me) bigger shared hosting providers and updated the linked tracking issue. Bluehost shared hosting supports 7.4. Pantheon, Acquia, GoDaddy support PHP 8.0. The rest all support 8.1 already.

Here's Packagist's data on PHP version adoption, from May 2021 to present:

Source: https://packagist.org/php-statistics

Meanwhile, here's the same data for Composer installs of drupal/core only, for Drupal 9 only:

Source: https://packagist.org/packages/drupal/core/php-stats#9

(Keep in mind that tarball builds of core also still exist and are not included in the above stats.)

Compare the above with this data from May 2020, when the combined use of PHP 7.3 and 7.4 already accounted for fully half the Composer ecosystem adoption:

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

Moving the current known info for distros into the IS, and linked the child issue therefrom.

Note that we are keeping this issue open even though Drupal 10 now requires PHP 8.1, because we want ot continue to use it to track PHP 8.1 availability and usage.

Added two new screenshots to the issue summary.

17% of Drupal 10 sites are on PHP 8.2, 83% on PHP 8.1, not really any other options.

47% of Drupal 9 sites are on PHP 8.1, 23% use PHP 8.0, 26% are on PHP 7.4

PHP 8.1 has gone from ~10% to ~50% of Drupal 9 sites in the past eight months, so that is not bad progress overall.

This means ~50% of Drupal 9 sites can't currently update on their present infrastructure, but there's also rapid adoption of PHP 8.1 which suggests lots of them are getting ready or at least off 7.4. Main question I guess is how many are left on PHP 8.0 and PHP 7.4 in November/December.

I think we should keep this open still, but not critical any more, so moving to major. We should also start a similar issue for Drupal 11 PHP requirement support.

I was surprised to see so many Drupal 10 sites on PHP 8.2, but it kind of makes sense given they were released around the same time, so for people starting brand new sites (or migrating from to Drupal 7) it would be an easy choice.

Fixing the order of images in the image summary.

There's an interesting thing (depending on your definition of interesting) happening on packagist with Drupal 9 php stats:
https://packagist.org/packages/drupal/core/php-stats#9

At the end of 2023, PHP 7.4 was 16% of installs with PHP 8.1 at 65% and PHP 8.0 at 10%

Now PHP 7.4 is 29% of installs, PHP 8.1 is 53% and PHP 8.2 is 7.5%, PHP 8.0 down to less than 5%.

So PHP 7.4 usage is a higher percentage, while PHP 8.0 has been almost squeezed out by 8.1 and 8.2.

Drupal 9 usage has gone down by approximately 30-40,000 in the same time period as sites update to Drupal 10.

So what this shows is that the sites that were already on PHP 8.0 or PHP 8.1 have either updated to Drupal 10 already, or in some cases updated to PHP 8.2 (likely in preparation for a 10.x update). But then there is a rump of 9.x sites still on 7.4 that have neither updated their PHP version nor their Drupal version and are drifting further behind.

Some percentage of those 9.5 sites on 7.4 will update their PHP version and Drupal version at the same time.

This only gives us an idea of package installs though - there will be 9.5 sites that haven't run composer update/install at all and those won't register in the stats.

Given that Drupal 10 is long since released with the 8.1 requirement and now in its long-term support phase, I'm going to mark this fixed. With changes to both our release cycle and PHP's allowing longer support for old versions (and therefore more time to upgrade), we're moving toward #3406215: [policy] Default to requiring the latest stable PHP release available when a new major version reaches the first beta window as a standard practice so that we overlap PHP's support cycle as closely as possible rather than trying to predict how well HSPs will keep up.

Thanks to everyone who helped provide the data on their hosting providers so we could make a good decision for Drupal 10!

First alpha of PHP 8.5 is out and core using polifill already, so I'm using #3523596: [meta] PHP 8.5 support for the same kind of tracking