This is a follow up from #1751100: Bump minimum version of php required to 5.3.5 - see comments on that thread for background.

There are at least threefour major reasons for PHP 5.3.10:

  1. An interface extending another can extend a method too (https://bugs.php.net/bug.php?id=43200)
  2. We can switch to bcrypt/blowfish for password hashing, which is stronger than what we have now (a major reason is that the password stretching would be in a C loop rather than a php loop, so harder for an attacker to exploit through optimization), as well as being more standard.
  3. The $node parameter for DOMDocument::saveHTML() was added in PHP 5.3.6 and is necessary for HTML5.
  4. Initial charset is supported by in the PDO MySQL driver since 5.3.6.

Some important data from the other issue:

  • Ubuntu 12.04: 5.3.10
  • OSX 10.7: 5.3.10
  • OSX Mountain Lion: 5.3.13
  • Red Hat Enterprise Linux RHEL-6.3: 5.3.3
  • XAMPP for Linux: 5.4.4
  • MAMP: 5.4.4 / 5.3.14
  • WAMP: 5.3.13
  • Fedora: 5.4.6
  • Debian 6.0 "squeeze": 5.3.3
  • Debian 7.0 "Wheezy" beta: 5.4.4
  • Centos: 5.3.3
  • FreeBSD 9.0: 5.3.8 - it is not a trouble due to integrated port collection system for update
  • FreeBSD 8.2: 5.3.5 - it is not a trouble due to integrated port collection system for update
  • FreeBSD 7.4: 5.3.5 - it is not a trouble due to integrated port collection system for update
  • OpenBSD 5.0: 5.3.6 - it is not a trouble due to integrated port collection system for update
  • OpenBSD 5.1: 5.3.10

Note that 5.3.5 is already required so operating systems shipping with 5.3.3 already need some solution. For Red Hat Enterprise Linux and CentOS we recommend http://iuscommunity.org/Repos (maintained by Rackspace staff). For Debian, we hope by the time we release, Wheezy ships, but for now both Squeeze and Lenny has 5.3.10 packages at http://www.dotdeb.org/ (seems like 5.3.10 was the last for Lenny).

CommentFileSizeAuthor
#39 1800122-39.patch950 bytesamateescu
#36 1800122_36.patch368 byteschx
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JamesK’s picture

Issue summary: View changes

Include distro PHP versions

pwolanin’s picture

As much as I favor stronger hashing, I think that' no longer one of the weakest links in our security chain. At the least, it would seem hard to justify increasing the requirements for core on this basis alone?

chx’s picture

We just found that https://bugs.php.net/bug.php?id=43200 was fixed in 5.3.9 and that caused problems in #1682778: Unify DataStructureInterface and PropertyItemInterface getters. That is a worthy bugfix to rely on.

chx’s picture

Looking at the table above FreeBSD 9.0 would be a problem but 9.1 is out http://www.freebsd.org/releases/9.1R/schedule.html on Oct 24.

chx’s picture

And, this came up because we are eyeing the condition unification and EFQ conditions compared to DBNTG conditions have an optional argument and so that would require 5.3.9 no doubt.

sun’s picture

It looks like we at least have to bump to 5.3.6 due to:
#1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5

The $node parameter for DOMDocument::saveHTML() was added in PHP 5.3.6.

chx’s picture

Assigned: Unassigned » catch

From the opening table it's clear to me that once we bump from 5.3.5 there's little point in stopping below 5.3.10 and there's next to zero chance of going above 5.3.10 due to Ubuntu 12.04 only supporting that. Moving to catch to get a tentative date, there's no doubt now that we want this to happen.

catch’s picture

I'm still running 5.3.6, so my current answer has to be 'some time after I get around to updating the distro on my laptop' :P

With at least one change in PHP requirements, we set a date, but committed patches that created a soft dependency (i.e. notices/warnings in Field UI) beforehand, I'm not opposed to that as long as the test bots work and there's a notice out. That way people have time to update before they're not able to install at all, but it also doesn't hold up bug fixes that require the higher version.

Do we have any idea when Centos and RHEL will catch up?

sun’s picture

Category: feature » task

Note that I currently do not see a way to fix #1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5 without bumping the PHP requirement to >= 5.3.6.

The only viable alternative for that bug would seem to be to replace the entire DOM parsing with a user-space library (e.g., html5lib), but the existing libraries are not maintained very well, so that would most likely result in other side-effects/regressions.

chx’s picture

The next major release of Red Hat Enterprise Linux (RHEL), version 7, is targeted for release in the second half of 2013

lpalgarvio’s picture

as for Debian...

6.x (Squeeze), current:
php 5.3.3-7+squeeze14

7.x (Wheezy), TBA, probably 2013:
php 5.4.4-9

tim.plunkett’s picture

PHP 5.3.9 adds a parameter to http://docs.php.net/manual/da/function.is-subclass-of.php that seems to be affecting autoloading.

chx’s picture

Priority: Normal » Critical

OK, this is definitely we can not release without this material now.

interface A {
  function test();
}
interface B extends A {
  function test();
}

This is the simplest case of https://bugs.php.net/bug.php?id=43200 . Maybe you want to tweak the return value, you want to add an optional argument, all those won't fly.

catch’s picture

Assigned: catch » Unassigned

How about week commencing 1st March - then we can announce it now to give people to upgrade their environments if they're behind.

If there's a specific issue this one blocks please link to it from here though.

chx’s picture

#1854708: EntityQuery aggregation support is not quite blocked but it can't document the different result set formats until this is in. So dependent but not blocked, the code works, the doxygen doesn't.

jthorson’s picture

Related issue for testbot queue: #1907678: Bump PHP version to 5.3.10.

We'll target having all bots updated before the suggested March 1st deadline.

jthorson’s picture

Issue summary: View changes

Updated issue summary.

chx’s picture

Issue summary: View changes

Updated issue summary.

chx’s picture

Issue summary: View changes

Updated issue summary.

rickmanelius’s picture

FWIW, Drupal 8 will be released after the php 5.3.x branch has entered its end of life cycle (starting March 2013).

http://php.net/archive/2012.php#id2012-12-20-1

Mark Trapp’s picture

rickmanelius: that was covered for a bit in #1498574-30: [policy, no patch] Require PHP 5.4 and on before it was won'tfixed. :/

chx’s picture

We need to consider what versions are shipped in various OS and what shared hosts support (it is not impossible that Drupal 9 won't support shared hosts but that's a monumental decision to make). As we know, the PHP team has zero connection with reality as proven recently again (and again) so their policy plays no role in this decision.

alexweber’s picture

I'm all for this. Current 5.3.x branch is at 5.3.21 and a lot are already using 5.4 so upping to 5.3.10 is no biggy IMHO.

yktdan’s picture

Just a sampling of hosts I have sites on:
A2Hosting dedicated 5.2.6 (must not break D6, otherwise I can upgrade anytime) switching to D7 in next few months.
A2Hosting shared 5.3.18 use for testing all - D7 - clearly ok
Webhostingbuzz 5.2.17 small production sites mix of D5, D6 and D7 (and one 4.7) - I don't know when they will upgrade
Drupal Gardens 5.2.4-2ubuntu5.26 (my usage is trivial - but suspect others depend on this)
My laptop - Windows, runs D8 several months old, easily upgraded as no dependence on anything.

alexweber’s picture

@yktdan I don't think your problem is 5.3.10 per-se but rather 5.3.0 :)

Topcheese’s picture

If that's the highest you'll go. As chx points out

From the opening table it's clear to me that once we bump from 5.3.5 there's little point in stopping below 5.3.10 and there's next to zero chance of going above 5.3.10 due to Ubuntu 12.04

So am I to understand that Ubuntu controls Drupal? Why not use 5.13 so that it might spur some action? Ah, the unseen power of Drupal. What I love the most is discovering the power that I did not know it had, and then making use of that power.

We are not talking children's toys here, you all are leading the way in your efforts, but you might be under estimating the power you have to make a difference. Legacy systems support? Well, I guess then we should all try to make sure Drupal 7 is heaven for them. Drupal 8 needs to get with the times, as so should the rest of them. You will get drag from them of course, which in turn drags Drupal.

Still worried about market penetration?

chx’s picture

> So am I to understand that Ubuntu controls Drupal?

Is that a relevant question? The hard requirement we have is PHP 5.3.9 (5.3.6 was saveHTML, 5.3.7 blowfish, 5.3.9 the abstract bug). Beyond 5.3.9 we have no hard requirements but we want to go as high as possible just to enjoy more bugfixes. But, we want a version that is widespread. 5.3.10 happens to be in Ubuntu LTS AND the last dotdeb for Debian oldstable AND the one shipped with the latest OpenBSD. That's what makes 5.3.10 a great candidate.

Topcheese’s picture

@chx, yes it is, and I'll take that answer as a yes.

Beyond 5.3.9 we have no hard requirements but we want to go as high as possible just to enjoy more bugfixes. But, we want a version that is widespread. 5.3.10

Please forgive my ignorance, but the latest OpenBSD release I see is 5.2 Released Nov 1, 2012 with PHP 5.2.17 AND 5.3.14.

You asked for feedback, and so I'm giving it. With no hard requirements, perhaps placing such a requirement on a yet to be released product does have its limitations? Obviously Drupal 8 needs to ship with PHP 5.3.13 AND PHP 5.4. :)

chx’s picture

Obviously? Does not seem too obvious to me? Anyways the feedback we are looking for is whether 5.3.10 is going to cause problems or not, not trying to find even higher versions. Even higher version, unless we have a similarly pressing need as the three listed in the op is straight out. And, PHP 5.4 is absolutely out unless you can show us research showing widespread support (for eg hostgator has no support, site5 has partial support, bluehost is ready) AND a strong need. From what I've seen 5.4 features are nice but not mandatory. Care to link the issues you worked on and was hindered by the lack of PHP 5.4 features?

chx’s picture

So to cut the chase, here are the kind of feedback we are looking for:

  1. I am working on X and I need PHP version Y for it
  2. PHP 5.3.10 is not working because...

Everyone else is encouraged to think hard on the size and reach of the Drupal ecosystem.

droplet’s picture

Collecting from my client's site:
Godaddy: 5.3.14+
Mediatemple: 5.3.15+
Hostgator: 5.3.15+

From above comments:
bluehost 5.3 ~ 5.4
site5 5.3 ~ 5.4
A2Hosting 5.3.18+

My research:
CPanel: 5.3.21+
Lunarpages 5.3.16+

Topcheese’s picture

Where would I begin? Why was PHP 5.4 written in the first place? The only requirements I have are those that you place, and it was stated that it was pretty much set in stone.

Maybe it is not as clear and it is not as obvious that it is in how you look at it. Really it should be PHP 5.3.15, and with 5.4 it's a "won't fix" issue. Isn't there already a PHP 5.5 version released?

PHP is "PHP," and I'm honestly trying to not offend any of the great people or the great work that they have done, but when I look at the grand scheme of things--with regards to PHP I'd say that you'd rather want to be associated with the higher end of PHP.

I'm still not sure that you've convinced me it should be PHP 5.3.10. The feedback from me is please get with the times. Are you serious about the links, because I believe one of us might have lost sight on what the term "hindered" means?

I understand the issue at hand, but I still think the answer is higher. Thank you all for at least hearing me out. I don't have quite the investment into this as some of you, so it is easier for me to play with ideas, but I would like to think that I'm trying to help out.

merlinofchaos’s picture

Topcheese:

In general, you want to be as inclusive as possible while still meeting all of your goals.

The minimum software requirements are a tug-of-war between "what will work" and "what does everything you need". The current discussion has a lot to do with bugs that were fixed as of 5.3.10, and that's currently targeted as the minimum version that will do everything Drupal needs. If the *only* benefit is "being newer", then that is no benefit at all.

The PHP4 -> PHP5 update was driven by the fact that PHP4 was going EOL, so "being newer" had a reasonable argument. However, other arguments are driven by things like 3 year release cycles on major Linux distributions. So "being newer" is a hindrance when using some of those OSes. That pushes the tug of war in the other direction.

So in my estimation "get with the times" is a difficult argument. Are we talking something that is potentially dangerously old (like PHP 4 was?) Are we talking something so new that major enterprise distros won't even have it when Drupal 8 is released? Both are valid points. Any minimum that is chosen is what Drupal will be stuck with for the next 3 years. There must be a valid reason for the actual version picked, IMO. Every time we've had this discussion, we've always settled on a break point decided by features offered or bugs fixed. And I think those are excellent arguments, and we should confine the arguments to those parameters.

Topcheese’s picture

Thanks merlinofchaos and chx for your time and effort. If what you say has worked out for you in the past, then who am I to say change it, as it seems to be working out for you. There is never an easy answer, but I do find it a little unsettling settling for the minimum instead of reaching for the maximum.

I appear to be hindering this process, so I will bow out now and try to catch you all on hopefully Drupal 9.

Edit: I just wanted to be clear that I don't have any issues or any problems, and that I realized my mistake. While I'm here I'd like to note that I'm really excited and that I'm really looking forward to D8. Time and time again, you all prove at least to me why you are some of the best around.

It is really quite understandable your response when someone pushes you to do a bit more, when already what you've done is impressive enough. I'm not trying to look a gift horse in the mouth, and what you all provide for free is beyond measure.

How about if I just try again to leave it at thanks!

droplet’s picture

I think most guys in this thread wants to use PHP5.5 but no one killing his business and the community in this way. For most small potatoes, we have no powers to ask customers use a new hosting. Even said minimum version is PHP5.3.5, I have to ask my customers hosting account before coding (or discuss the site specs). It will kill Drupal & Drupal developer's life time.

Use PHP5.6 in your own module, no problem, no conflicts.

see other CMS:
http://www.joomla.org/about-joomla/technical-requirements.html
http://wordpress.org/about/requirements/

chx’s picture

By merlinofchaos' post we should pick PHP 5.3.9 however I would still go with 5.3.10 as the only difference is a security bugfix and they were released not a month apart and there is no distro that picked 5.3.9. Truly the only choice is between 5.3.9 and 5.3.10.

As for later versions, let me quote a very timely post by zeev about the now yearly released PHP 5.X versions:

there's next to nobody actually interested in consuming those releases

. Drupal core can not afford to try, either. We will have enough problems with the hosting requirements of Drupal 8 anyways.

Topcheese’s picture

@droplet, I really feel funny now, but I just knew it in my heart that Drupal was better than that. Thanks for the information.

@chx, very interesting indeed, thanks. I don't know what Drupal core can afford, but as long as it can pay the price when the time comes, then I think we're good.

+1

Damien Tournoud’s picture

I'm fine with 5.3.10, too.

fago’s picture

#12 would be indeed a big help documenting interfaces, I ran into this already with entity field interfaces extending typed data interfaces.

fago’s picture

Issue summary: View changes

Updated issue summary.

chx’s picture

Status: Active » Needs review
FileSize
368 bytes

Status: Needs review » Needs work

The last submitted patch, 1800122_36.patch, failed testing.

andypost’s picture

Status: Needs work » Needs review

Zend Server 5.3 is 5.3.14 and then moved to 5.4

amateescu’s picture

FileSize
950 bytes

Missed a spot :) The patch won't install on the testbots until we upgrade them to 5.3.10 as well.

Status: Needs review » Needs work

The last submitted patch, 1800122-39.patch, failed testing.

yareckon’s picture

Debian looks ready for a middle of the year release.... http://bugs.debian.org/release-critical/ (green line goes to zero) So this looks OK. Have to get my vms upgraded :)

rfay’s picture

Status: Needs work » Needs review

#39: 1800122-39.patch queued for re-testing.

rfay’s picture

Testbot 654 is now running 5.3.10, so wanted to give this a shot on it.

Status: Needs review » Needs work

The last submitted patch, 1800122-39.patch, failed testing.

jthorson’s picture

Status: Needs work » Needs review

Failure looks like an APC issue ... manually re-queued, and is currently past the installation phase and running assertions.

xjm’s picture

Status: Needs review » Reviewed & tested by the community

It looks to me like all the concerns around this have been addressed, and there's plenty of buy-in. And the bots are ready! So I think this is RTBC.

So, we missed March 1, but how about a week starting tomorrow, and we make a g.d.o post then if the maintainers have signed off?

xjm’s picture

Okay, I fail at reading:

Testbot 654 is now running 5.3.10, so wanted to give this a shot on it.

So the other bots still need to be upgraded?

rfay’s picture

It's trivial to update the other testbots. Was just waiting for problem reports with 654. Seems like we had some immediate issues.

jthorson’s picture

All bots should now be updated.

Dries’s picture

I'm fine with 5.3.10.

xjm’s picture

Let's schedule the commit for March 15, then? If that's alright with everyone I'll post the announcement.

xjm’s picture

DanChadwick’s picture

Windows WAMPserver 2.2e using PHP 5.3.13 (which uses PCRE 8.2) may experience pain. I certainly did:
#1917530: drupal_parse_info_format crashes with PCRE 8.12

Crell’s picture

Ironically, we JUST killed that function, I believe: #1793074: Convert .info files to YAML

webchick’s picture

Title: Bump minimum version of php required to 5.3.10 » [March 15] Bump minimum version of php required to 5.3.10

Doing something with the title so I quit seeing it at the top of my commit list and freaking out. :D

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks.

xjm’s picture

Title: [March 15] Bump minimum version of php required to 5.3.10 » [Change notice] Bump minimum version of php required to 5.3.10
Status: Fixed » Active
Issue tags: +Needs change record

We also need to update http://drupal.org/node/1800122 (Both the version number and any relevant details, I think.)

xjm’s picture

Title: [Change notice] Bump minimum version of php required to 5.3.10 » Bump minimum version of php required to 5.3.10
Status: Active » Fixed
Issue tags: -Needs change record

Actually, looking at the existing change notice, I just increased the version number there. Sorry for noise. :)

hass’s picture

There is no xampp version with 5.3.10... so I'm out. Latest 5.3 is 5.3.8

plach’s picture

@hass:

I'm using wamp instead, it works pretty well: http://www.wampserver.com

ParisLiakos’s picture

you can use 5.4..it doesnt need to be exactly 5.3.10. just the minimum
i see http://www.apachefriends.org/en/xampp-windows.html has 5.4.7

swentel’s picture

Is this also needed for update.php or not ? Filed at #1949564: Bump PHP in update.php and install.php to 5.3.10

johncs’s picture

That's nice.

I can run the about-to-release Joomla and latest Wordpress on my CentOS6 server, but not D8.

amateescu’s picture

Please keep in mind that we're *at least* a couple of months away until release..

xjm’s picture

Code freeze for Drupal 8 is not until July 1. 8.0 is not likely to be released until at least the fall.

So there's lots of time for upgrades yet. :)

hass’s picture

Have you ever heard that hosters are not providing images that are up to date? I know that server4you and others in germany are often 2 years behind. Additional suse often does not provide updated packages. S4Y has provided default vserver images that suse itself has no longer supported for about 2 years. They are mostly 1year behind on root servers, too. This hosters are no exception - this is normal. This will not allow the masses to run D8.

ParisLiakos’s picture

This will not allow the masses to run D8.

or it will force the mass of the hosts to upgrade their freaking old servers

hass’s picture

That's only a dream.

klonos’s picture

#67 ++1

If masses start to migrate away from their hosters to other ones that do provide updated images, then I'm pretty sure the hosters will be forced to upgrade. That is if they want their customers back.

hass’s picture

I would not change my hoster only for Drupal 8, but I could be a minority. The other hosters are no better.

Mark Trapp’s picture

Just to update on #16, PHP 5.3's end of life was announced in February, but it has now been redefined to be 1 year after PHP 5.5 is released. PHP 5.5 just entered its second beta, so the final countdown to PHP 5.3 EOL won't happen for a few more months.

Owen Barton’s picture

@hass - XAMPP for OS X last release was 2010-03-04, so it seems pretty close to abandoned (there are plenty of other ways to LAMP on OS X though). XAMPP for both Windows and Linux includes PHP 5.4.7.

chx’s picture

Two years behind, that's fine then two years after 5.3.10 came out, by 2014 february everyone will be up to 5.3.10. I am fine with that. With a fall release, that means even behind hosts will be able to run Drupal 8.1 if not 8.0. Perfect. Prepare your site upgrade with D8 on your devsite, push to prod in February? I am fine with that schedule.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updated issue summary.

ghalaat’s picture

Issue summary: View changes
ghalaat’s picture

Status: Closed (fixed) » Needs review

39: 1800122-39.patch queued for re-testing.

webchick’s picture

Status: Needs review » Closed (fixed)

Restoring status.