[Drupal 7] Require PHP 5.3

fwiw I think this is worth doing.

http://w3techs.com/technologies/details/pl-php/5/all shows that 14% of all sites using 5.* are using 5.2

In practice I'd expect this to prevent new installs, but just show a warning on existing ones - although that could probably use some testing (could do it with a different PHP version to be sure) - at least until PHP 5.3-specific code gets committed to 7.x.

What the PHP developers consider "end of life" is very different from what the rest of the world (including Linux distributions who provide extended security support) considers end of life :) I guess there may no longer be any Linux distributions that still support 5.2 either, but I am not sure.

To me, it seems too early to do this - 14% is a pretty big number. (In fact, the above link shows that PHP 5.2's usage is currently about the same as the combined usage of PHP 5.5 and 5.6....)

This issue also doesn't really describe any compelling reason to make the change. We already have reasonably good support for PHP 5.3 namespaces and such in Drupal 7 (and solvable issues open for areas where we don't), just that we don't use them in Drupal core itself. So I'm not sure it's really been a major problem yet.

Ubuntu 8.04 shipped with PHP 5.2.4 and support finished in May 2013.

Ubuntu 10.04 shipped with PHP 5.3.2 and support finished in September 2015.

https://wiki.ubuntu.com/Releases

Debian Lenny shipped with 5.2.something, support was finished in 2012:

https://wiki.debian.org/DebianLenny

When we were looking at raising Drupal 8 requirements from PHP 5.2 to PHP 5.3, only RHEL/Centos didn't have 5.3 available, but at that time they were on PHP 5.1 and I think they jumped to 5.3 later skipping 5.2 entirely, less sure on that though.

#576508: Require PHP 5.3 has information on what shipped with what at the time 8.x introduced the requirement.

Based on that, I don't think it's possible to run PHP 5.2 on a supported linux distribution without using a non-standard build of PHP to downgrade from whatever it ships with.

The only reason to drop support would be to discourage people from running Drupal 7 on environments that have either explicitly downgraded PHP to 5.2 or have not updated their OS for 2-3 years. I don't see why we'd start introducing PHP 5.3 code into 7.x at this point.

According to Distrowatch (http://distrowatch.com/table.php?distribution=centos)

RHEL/Centos 5 had php 5.1 << version is too old to Run drupal 7 already.

RHEL/Centos 6 has php 5.3.3

Changing minimum requirement to php 5.3 should not have any impact on services sing RHEL/Centos

@catch posted #2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7 to deal with the more general policy of how we drop support for EOL PHP versions.

when I was creating PHP 7 compatibility patches for Views, Ctools and Panels, some people wanted to double check if the changes would have any impact on PHP 5.2 (unlikely, but still need to check).

Contrib projects can set their PHP requirement higher than core's. For example, Webform has a PHP 5.3 requirement. What about filing issues with Views, Ctools and Panels to raise their requirement? They might say no, but I'd be curious to learn their reasons.

14% is a pretty big number

Looks like even now, 2 years later, it's still at 8.6%. Wow.

I think that this is still worth doing, plus, by the time we RTBC and announce it, it's going to be 2018 already.

My reasoning for this is that it opens the door to shipping some kind of rudimental autoloader with D7. The huge D7 codebases are not going away anytime soon, but nothing's stopping us from modernizing them over time.

To be honest, are people willing to upgrade code on Drupal 7 core and contrib modules to take advantage of PHP 5.3 as a minimum requirement?

And which advantages on PHP 5.3 would be applied?
https://secure.php.net/manual/en/migration53.new-features.php
- Support for namespaces has been added? It's maybe too late to be rewriting that kind of code.
- Support for Late Static Bindings has been added? Same.
- Support for native Closures (Lambda/Anonymous functions) has been added? Same.
- Constants can now be declared outside a class using the const keyword? Same.
- Support for jump labels (limited goto) has been added? Probably not a good idea.
- Nowdoc syntax is now supported, similar to Heredoc syntax, but with single quotes? This is useful, but do we need it now?
- The ternary operator now has a shorthand form: ?:..? This is useful too, but coding standards may be more important.
- A garbage collector for circular references has been added, and is enabled by default? This is useful and requires no changes.
(...)

Is it worth the effort?
I don't think it brings that many great features for a code that can't suffer major refactoring.

Comparing to PHP 5.4:
https://secure.php.net/manual/en/migration54.new-features.php
- Support for traits has been added.
- Short array syntax has been added, e.g. $a = [1, 2, 3, 4]; or $a = ['one' => 1, 'two' => 2, 'three' => 3, 'four' => 4];.
- Binary number format has been added, e.g. 0b001001101.
- The session extension can now track the upload progress of files.
(...)

Often developers set PHP 5.4 as minimum requirement much because of short array syntax, which i think is unnecessary.

I think t's not a good policy to just change the requirements "because so", much less on already shipped and stable products.
I've been having this discussion with occasional authors in different communities who don't seem to care about support and servers.

According to https://dri.es/the-end-of-php-5:

Drupal 7 will drop support for older versions of PHP 5 on December 31st [2018], but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

Earlier today, we released Drupal 7.61 which now supports PHP 7.2. This should make upgrades from PHP 5 easier. Drupal 7's support for PHP 7.3 is being worked on but we don't know yet when it will be available.

Supposedly all older PHP 5 support was "dropped"; however, I cannot seem to find any issue that discussed this specifically or where this decision was made.

The only change record I found was the following (which links to issues that discuss some 7.x plans, but not much):

Drupal 8 support for PHP 5.5 and 5.6 will end on March 6, 2019

Regardless, I agree that this is the right move forward for Drupal 7.

Let's do it.

For clarity on the dashboard and other places you don't see the version.

I completely agree... however there are a few organizations that still uses PHP 5.3.3.

What I have in mind is the following:

I would say that from Drupal 7 to Drupal 7.65, PHP < 5.6 is supported.
Starting from Drupal 7.65, PHP 5.6 would still be supported but the advised version would be the latest PHP 7 version.
7.65 is an arbitrary version number to be defined and obviously not the next Drupal 7 version.

If we announce this now, it would let people know this in advance that support for PHP < 5.6 would be dropped very soon.

What do you think ?

Also stop automated testing on unsupported versions of PHP.

@Pol, so are you saying no PHP 5 support at all and announce something similar like D8 did?

"Drupal 7 support for PHP 5 will end on March 6, 2019"

#18 I don't think deprecating usage of PHP 5 is on the table right now.

I still think it would be good to get rid of PHP 5.2 (which is a hassle to support) and possibly PHP 5.3 (which has some inconsistencies).

I think there's genuine confusion as to what is on the table right now as the blog post from Dries doesn't support what seems to have been discussed or lack thereof.

edit: I can't assign to Dries, so just tagging for product manager review.

Hi all,

I updated my previous post and summarized here what I have in mind.

• From Drupal 7.1 to Drupal 7.65 (this version needs to be defined): PHP 5.3 to 5.6
• From Drupal 7.65 and onward: PHP 5.6 to ... (whatever currently supported PHP version)

Later on, we could imagine to have the same for PHP 5.6.

It would be nice to have @Dries's input on this.

I would add that we should only support versions of PHP 7 that are supported. This means right now, not PHP 7.0.

This is a very valuable point indeed.

I'm also confused about how to interpret the blog post. It says:

Drupal 7 will drop support for older versions of PHP 5 on December 31st, but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

Note that the following third-party organizations backport security fixes for the following PHP versions:

• RHEL 6 for PHP 5.3 until November 2020.
• RHEL 7 for PHP 5.4 until June 2024.
• Ubuntu 14.04 for PHP 5.5 until April 2019.
• ZendServer 8.5 for PHP 5.6 until December 2020.
• Ubuntu 16.04 for PHP 7.0 until April 2021.

If "older versions of PHP 5" is intended to mean "versions that do not get security backports from any reliable third-party organization", then the only "older version" that currently meets that criteria is PHP 5.2.

On the other hand, the blog post specifically calls out PHP 5.6 as the one (and by implication, the only one?) that will be supported for Drupal 7 for as long as there are third-party organizations supporting it, but frankly, I'm concerned about abandoning Drupal 7 sites that are currently perfectly happily and securely running on RHEL 6, RHEL 7, or Ubuntu 14.04.

My thoughts on this are:

1. Any system requirements change or BC break of this nature should be announced at least a year in advance. (That's what we did for D8's PHP 5 support, for Symfony 3, and IIRC for D6's PHP 4 support as well.)
2. For something like a stale PHP version, the status report in Drupal itself should start warning the site owner at the time of the announcement.
3. Drupal 7 is in LTS, and there are perfectly functional sites out there that probably haven't done anything other than hop from security update to security update for the past 8 years. They have never broken, except maybe briefly when that one early patch release broke CTools. ;) It's very different from D8, where the faster pace of development, new features, and minor release schedule have kept site owners more directly aware of Drupal's release process.
4. In general, I think we should avoid changing system requirements (which is essentially a giant BC break) without a very strong reason. The simple fact that their version is unsupported and insecure mostly isn't our problem. We can warn them on the status report that their version of PHP is outdated and possibly insecure, but it's not our job to ensure the security of their stack.
5. "Old and unsupported" does become our problem when there is a security issue that affects Drupal only on the old-and-unsupported thing, but even then, we have to balance the different risks to the ecosystem of breaking old sites vs. the maintenance burden of protecting them. For example, Drupal 7 uses jQuery 1, which has been EOL for several years. Rather than break D7's BC with a jQuery 3 upgrade, the security team opted to mitigate a jQuery 1 vulnerability within Drupal core itself.
6. One of the primary reasons Drupal 8 is dropping support for older PHP versions is that we have to choose between running unsupported versions of our dependencies or increasing our PHP requirements to match theirs. D7 mostly doesn't have this issue.

So, for each of 5.2 through 5.5, I think it would be good to discuss what the drawbacks are, other than "it's out of security coverage" (a given, but also see above from @effulgentsia) or the annoyance of not being able to use the nicer PHP syntax we have for D8 (a maintenance burden, yes, but is it enough so to risk stopping D7 site owners from getting unrelated security updates or breaking their sites so they just give up and move to a different platform?)

Edit: These are the things I would say as a release manager, but I am not a release manager of D7. :)

Oh, I forgot to say something else, which is that it's worth considering making an old PHP version a warning rather than an error at update. Because old PHP and maybe some bugs from syntax errors is less bad for the site than not being able to install a Drupal core security update.

One more thought. I think it would also make sense to postpone this issue on Drupal 8 dropping support for 5.5 and 5.6, since we have a planned process to make the break as gentle as possible, but only the first step (status report warning) has been committed. Then when 8.7.0-alpha1 is released and 8.8.x is branched we can "backport" the pattern to D7.

Edit: But, I would recommend adding a status report warning ASAP. See #2670966: Warn users of old PHP versions and #2927344: Specifically warn about end dates for PHP support for old versions for what we did with D8.

I think we could start in needing PHP 5.3 or 5.4; PHP 5.2 is a nightmare to support and really not supported anymore

We are still on RH6 on a number of servers, plans are in the works to upgrade but it’s a slow process in a large organization.

I’ll echo @xjm’s points above, especially around security updates!

Maybe leave this for another reason to move to Drupal 8

@joelpittet: Thanks for sharing that. I realize that what your organization does may or may not be indicative of what others do, but I think it's still helpful to gather stories about what's happening "on the ground". With that in mind:

We are still on RH6 on a number of servers

Are you using its stock PHP version (5.3), or are you using a later PHP version from RHSCL or elsewhere? And for whatever that answer is, why is that your organization's choice?

plans are in the works to upgrade but it’s a slow process in a large organization

Are you planning on upgrading to RH7, or waiting till RH8 (currently in beta)? Are you planning to be complete prior to RH6's EOL of 11/2020, and if so, how much prior?

FWIW, here's a proposal:

1) We drop support (by which I mean, we stop running automated tests for, and therefore assume that more and more things start breaking as patches get committed and released) for PHP 5.2 some time in 2019. I don't know what the ideal amount of notice (a hook_requirements() warning and an official statement on drupal.org similar to https://groups.drupal.org/node/518200) for this is. Since I'm suggesting dropping support in 2019, that means I'm also suggesting less than 1 year of notice. But whether we want 3 months, 6 months, 9 months, or ?, I don't know yet. Thoughts?

2) We drop support (same definition as above) for PHP 5.3, 5.4, and 5.5 some time in 2020. The benefit to doing this is that Drupal 9.0 will be released in 2020, currently targeted for June 3, 2020. Once Drupal 9.0 is released, the security team will be responsible for supporting 3 major versions of Drupal (7, 8, 9) and 4 total branches (7.x, 8.8.x, 8.9.x, and 9.0.x), which is more work than the current workload of 2 major versions and 3 total branches. Furthermore, PHP 7.4 will be out by then, for a total of 9 PHP versions if you count from 5.3, but only 6 if you count from 5.6. Reducing the number of PHP versions to test and accommodate for in each security release helps. Finally, https://dri.es/drupal-7-8-and-9#3 already announced the expectation of raising PHP requirements for Drupal 7 once Drupal 9 is released, though for people who don't follow Dries' blog, we should also update the "What happens to Drupal 7?" section of https://www.drupal.org/documentation/9.

For this, given RHEL 6 and RHEL 7 users (see #26), I definitely think that we should give people at least one year notice (hook_requirements() warning linking to an official statement on drupal.org). I think it would be ideal if we also made it one year from when RHEL 8 is available (to give RH6 and RH7 users the option of upgrading to RH8 instead of being forced into a non-stock version of PHP). So perhaps the PHP 5.3, 5.4, 5.5 discontinuation could be something like "the later of Drupal-9.0's-release or RH8's-release-plus-one-year"? Or if that's too confusing, we could perhaps pick a date like June 3, 2020, and just stick to it regardless of when Drupal 9.0 or RH8 are released?

3) We drop support (same definition as #1 above) for PHP 5.6 (and maybe 7.0 and 7.1) some time in 2021. The benefit of doing this is to do it sometime on or before November 2021, which is when D7 becomes officially EOL and goes into commercial LTS. By dropping support for obsolete PHP versions prior to this, we do it via official channels (and via official changes to D7's hook_requirements(), etc.), thereby freeing up the commercial LTS providers from having to manage that process. Note that per #26, PHP 5.6 and 7.0 no longer receive security backports even from those organizations past April 2021.

Thoughts?

@effulgentsia we are using stock PHP 5.3 and I believe the rational was it would be supported by Redhat for security fixes until RH6's EOL.

We are moving to SCL for transition to RH7 but ran into issues with it packaging too many other "related" packages that aren't needed in their collections and storing them in non-standard locations(making Drush not work for the SSH $PATH for example), all things we can work around but were a pain for the sysadmins.

My hope is to move our department's servers to RH7 by the end of the year if not sooner(personally hope the end of the month), the upgrade process has been going on for quite some time already, just have some issues popup that slow things down like network manager getting in the way, etc.

We are moving to SCL for transition to RH7

Does that mean #33.2 would work for you (i.e., ok to drop PHP 5.4 support in 2020?) or would you expect to be able to run PHP 5.4 on RH7 until its EOL of 2024?

re #35. Short answer: RH7 is packaged with 5.4, so I'd expect D7 to support 5.4 till 2024.

RH6 - November 30, 2020
RH7 June 30, 2024
https://access.redhat.com/support/policy/updates/errata

I hope the other departments are also upgrading (I don't know them all) and I've heard from a few of them who are in the same boat as we are so I'm trying to speak up for them as well. I'm not sure the other departments have the same resources to get SCL setup and I presume they would stick to the version that is packaged with the OS for the reason I mentioned above.

Here is an article about what WordPress is doing: WordPress to show warnings on servers running outdated PHP versions: WordPress PHP minimum requirement to change to PHP 5.6 in April and PHP 7.0 in December.

Thanks for sharing that!

That article says:

The WordPress team would like to officially modify the WordPress CMS minimum PHP version requirement from PHP 5.2 (the current) to PHP 5.6 by April 2019.

They don't say where they source that statement from.

I found https://make.wordpress.org/core/2018/12/08/updating-the-minimum-php-vers..., which looks like a not-yet-decided proposal, and that says:

I’d like to propose that in April 2019, we bump the minimum PHP version requirement to be 5.6. Sites that choose to remain on 5.5 or below will still receive security updates and possibly bug fixes, but would not be able to upgrade to the latest major WordPress version until they upgraded to a supported version of PHP.

That's similar to what we did with Drupal 8, by releasing it with a PHP 5.5 requirement in 2015, figuring that people with older PHP versions can remain on Drupal 7. But unless we choose to security support multiple branches of 7.x, raising the requirement for Drupal 7 would leave people with older PHP versions no option to remain on a security supported Drupal version.

An update from the trenches: We deployed a couple sites in PHP 7.1 on RH7 SCL and they come with PHP 7.1.8 but ran into a bug in OPCache that was fixed in PHP 7.1.9. We are going to message RH and look at going to PHP 7.2 as a fall-forward 🔧

The bug occurred here /admin/structure/types/manage/CONTENT-TYPE/fields:

Warning: Narrowing occurred during type inference. Please file a bug report on bugs.php.net in require_once() (line 341 of includes/module.inc).

http://git.php.net/?p=php-src.git;a=commitdiff;h=3df47c12f77a71f90778ec4...
http://php.net/ChangeLog-7.php#7.1.9

Fix link in issue summary.

Duplicate of #3319435: Update system requirements (including INSTALL.txt) for D7.