Problem/Motivation
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.
Also, according to http://php.net/eol.php, all PHP 5 support reached end of life on Dec. 31st 2018.
Proposed resolution
Increase the requirement for Drupal 7 to PHP 5.6 and recommend to use PHP 7 or above.
Remaining tasks
- Update INSTALL.TXT
- Update
DRUPAL_MINIMUM_PHP
constant - Update requirements page
- Stop automated testing on unsupported versions of PHP
User interface changes
None
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|
Comments
Comment #2
skyredwangComment #3
skyredwangComment #4
skyredwangThe fact that many Drupal 7 sites are performing well on PHP 5.3 or above makes
optional?
Comment #5
cilefen CreditAttribution: cilefen commentedComment #6
catchfwiw 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.
Comment #7
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedWhat 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.
Comment #8
catchUbuntu 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.
Comment #9
NaheemSays CreditAttribution: NaheemSays commentedAccording 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
Comment #10
skyredwangThe motivation I have for creating this request is:
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). Therefore, I hope to take PHP 5.2 off their mind.
Comment #11
xjm@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.
Comment #12
effulgentsia CreditAttribution: effulgentsia at Acquia commentedContrib 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.
Looks like even now, 2 years later, it's still at 8.6%. Wow.
Comment #13
bojanz CreditAttribution: bojanz at Centarro commentedI 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.
Comment #14
lpalgarvio CreditAttribution: lpalgarvio as a volunteer commentedTo 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.
Comment #15
markhalliwellAccording to https://dri.es/the-end-of-php-5:
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.
Comment #16
markhalliwellComment #17
markhalliwellFor clarity on the dashboard and other places you don't see the version.
Comment #18
PolI 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 ?
Comment #19
Liam MorlandAlso stop automated testing on unsupported versions of PHP.
Comment #20
markhalliwell@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"
Comment #21
Fabianx CreditAttribution: Fabianx as a volunteer commented#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).
Comment #22
markhalliwellI 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.
Comment #23
PolHi all,
I updated my previous post and summarized here what I have in mind.
Later on, we could imagine to have the same for PHP 5.6.
It would be nice to have @Dries's input on this.
Comment #24
Liam MorlandI would add that we should only support versions of PHP 7 that are supported. This means right now, not PHP 7.0.
Comment #25
PolThis is a very valuable point indeed.
Comment #26
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI'm also confused about how to interpret the blog post. It says:
Note that the following third-party organizations backport security fixes for the following PHP versions:
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.
Comment #27
xjmMy thoughts on this are:
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. :)
Comment #28
xjmOh, 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.
Comment #29
xjmOne 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.
Comment #30
Fabianx CreditAttribution: Fabianx as a volunteer commentedI 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
Comment #31
joelpittetWe 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
Comment #32
effulgentsia CreditAttribution: effulgentsia at Acquia commented@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:
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?
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?
Comment #33
effulgentsia CreditAttribution: effulgentsia at Acquia commentedFWIW, 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?
Comment #34
joelpittet@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.
Comment #35
effulgentsia CreditAttribution: effulgentsia at Acquia commentedDoes 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?
Comment #36
joelpittetre #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.
Comment #37
Liam MorlandHere 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.
Comment #38
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThanks for sharing that!
That article says:
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:
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.
Comment #39
joelpittetAn 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
:http://git.php.net/?p=php-src.git;a=commitdiff;h=3df47c12f77a71f90778ec4...
http://php.net/ChangeLog-7.php#7.1.9
Comment #40
Liam MorlandFix link in issue summary.
Comment #41
MustangGB CreditAttribution: MustangGB commentedDuplicate of #3319435: Update system requirements (including INSTALL.txt) for D7.