Drupal 8 will come out in late 2013 or early 2014, by that time PHP 5.4 will be at least 1.5 years old. Probably PHP 5.3 will not be supported anymore by php.net, but Linux distributions will be stuck with it as a default a bit longer (e.g. Ubuntu 12.04 LTS will use PHP 5.3 and will be supported until 2017, though there is a well respected and easily available ppa to get php 5.4+ on 10.04 or 12.04).

If we keep going with the 3 year release cycle for major Drupal versions, Drupal 8 will be supported until Drupal 10, which will probably come out in 2019 or 2020.

Are we sure that we want to go with PHP 5.3 (first released 2009) until 2020?

Issues that would be helped by requiring PHP 5.4

#2079797: Provide a trait for $this->t() and $this->formatPlural()
Iterators can't be (easily) unit tested without phpunit 3.8 which requires php >= 5.4

#1858196: [meta] Leverage Symfony Session components
Would be improved if we can rely on Native SessionHandlerInterface from PHP 5.4
http://php.net/manual/en/class.sessionhandlerinterface.php

#2129953: Abstract entity status out to an interface and #2130937: Move entities' CRUD methods to a separate interface aim to improve DX.
Taking advantage of traits (in php 5.4) in these issues will help us remove required, but unusable methods from entities without possibly adding duplicate code.

Survey of major distros to see what PHP they support in 2013

It appears that all popular Drupal environments include PHP 5.4 [or above] by 2013. (list obtained from "Page Hit Ranking" on http://distrowatch.com/)

  • Arch: php 5.5.6 : https://www.archlinux.org/packages/extra/i686/php/
  • Debian: stable: php 5.4.4 : http://packages.debian.org/wheezy/php5
  • CentOs: 6.4 : 5.3.3 http://mirror.centos.org/centos/6/os/x86_64/Packages/
  • Fedora:
  • Mageia:?
  • Mint: (uses ubuntu repo): php 5.5 : https://launchpad.net/ubuntu/saucy/+source/php5
  • openSUSE:?
  • Ubuntu 13.10: php 5.5 : https://launchpad.net/ubuntu/saucy/+source/php5 -- irrelevant, only LTS matters, 12.04 was 5.3.10, upcoming 14.04 "Trusty" will be 5.5.
  • Operating Systems / Tools

  • Acquia Developer Desktop: Provides PHP 5.4, 5.3, and 5.2 : https://docs.acquia.com/dev-desktop/whats-new
  • MacOS: Mavericks: php 5.4.17 : http://www.coolestguidesontheplanet.com/downtown/get-apache-mysql-php-an...
  • Mamp: Includes php up to version 5.5.3 : http://www.mamp.info/en/documentation/releases.html
  • Xamp: PHP 5.5.3 : http://code.stephenmorley.org/articles/xampp-version-history-apache-mysq...
  • Hosting Providers:

    • 1and1: Default to 5.4, also offer older versions
    • A Small Orange: 5.3-5.5 - with 5.3 being phased out in 2014.
    • Bluehost: 5.3-5.4
    • Dreamhost - PHP 5.2 - 5.4
    • Gaiahost.org php 5.3-5.4
    • Gandi - PHP 5.4
    • GoDaddy: 5.4 scheduled for November, 5.5 available soon after
    • Greengeeks: 5.3-5.4
    • HostGator: 5.4 targeted for early 2014
    • Inmotion Hosting - PHP 5.2 - 5.4
    • OVH - PHP 5.3, 5.4, 5.5
    • Purley Hosting - PHP 5.4
    • Site5: 5.3-5.4
    • Vevida - PHP 5.3 - 5.5
    • Webfusion - PHP 5.3 - 5.5 (on request)
    Files: 
    CommentFileSizeAuthor
    #159 interdiff_1498574_158.txt2.44 KBcosmicdreams
    #159 drupal_1498574_158.patch10.55 KBcosmicdreams
    FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
    [ View ]
    #139 drupal_1498574_139.patch10.54 KBXano
    FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
    [ View ]

    Comments

    I'm 99.9% sure at 2013 all new linux dist support PHP 5.4 by default.

    However, HOSTING aren't.eg. a big hosting, Bluehost supports PHP5.3 recently (this year I think). PHP 5.3 is not the default PHP version for most companies.

    Status:Active» Needs review

    @droplet - they will not. As @klausi said, Ubuntu 12.04 will ship with 5.3. The next LTS release of Ubuntu will get released in 2014 and that will have PHP 5.4. I think it would be foolish to release D8 without support for 5.3.

    @skottler,
    Yes. that's LTS version, I also counted other releases. (of course this is a great point to not depend on PHP5.4).

    D8 depends on PHP5.3 now.

    Thanks your remind :P

    We should probably focus this decision on who will support PHP 5.4 when Drupal 8 is released, not what the situation will be in 2020. If many hosting companies or distros don't support PHP 5.4 at release time, we'll exclude a large segment of the market just because a few developers wanted to pull in the latest major version of PHP.

    Coment #2 by skottler already raises a huge red flag in my mind about requiring PHP 5.4 if the current LTS version of Ubuntu won't support PHP 5.4 when we release Drupal 8.

    To install D8, which currently requires PHP 5.3.3, I had to do a minor upgrade from the current Ubuntu LTS, Ubutu 10.04, which supports 5.3.2, to Ubuntu 10.10 to pull in PHP 5.3.3.

    Drupal is the kind of product than push the hosting company to update their PHP version. My experience with Linux is than I always and up getting LAMP from unofficial repository like http://www.dotdeb.org. Also don't forget than when D8 will get out it will take some time before his wildly used.

    What we have to know it's if new features will be really useful for D8. Closure can be interesting.

    see http://www.php.net/manual/en/migration54.new-features.php

    My opinion is when you release a product you better to use the last possible technologies or you going regret it after. Software is already obsolete fast enough...

    Which features of 5.4 that are not also present in 5.3 do we want to create dependencies on?

    I would say if it's easy to keep 5.3 support we should certainly do so, just to include as many hosting companies as possible, but we do need to evaluate whether we will be disadvantaged by not taking advantage of 5.4 features, so I'd think this discussion needs to be driven by which features of 5.4 if not used in D8 would cause the project pain.

    If we can list those and evaluate the importance of each, then the decision should be fairly clear. (Say, if there's one or more seriously important feature on the list, then we need to go 5.4). I think this discussion would benefit from breaking the problem down a bit and looking at the pieces.

    The biggest benefit we'd get our of PHP 5.4 is better memory usage and Traits. We can accomplish what traits gives via interfaces and a well outlined abstract class hierarchy, so we don't really NEED them at this point, but it it worth considering.

    The better memory usage would be nice to have when it's there but we don't need to create a dependency on it, as our code wouldn't change with the memory management ... traits is an interesting point, not sure whether it's worth excluding 5.3 for that though and I'd agree most of what traits is offering can be achieved by other means. Dependency injection? ;)

    Doesn't sound like we have a solid case for a dependency on 5.4 yet given what we'd need to exclude.

    @heyrocker mentioned that in PHP 5.4 we would have the ability of disabling UTF-8 escaping for json_encode(), which would restore JSON as a valid CMI serialization format.

    The memory usage stuff is the most compelling feature IMO. The difference is drastic. However if the hosts don't support it then they don't support it and we can't move. I think we can see what the situation looks like in 9 months or so, but I would love to see this happen.

    The improvements in memory management have been mentioned in a few places and a couple of tests promise pretty amazing improvements. I still don't see how that constitutes a dependency though ... am I missing something? If 5.4 is available on the environment we're installing D8 on, then we get to take advantage of those improvements. If it's not, then PHP might need to be configured to have a higher memory limit, and that might limit the number of PHP processes that we can have on that machine. The user would be "penalized" a bit for not using 5.4, but it would still work, so where do we get the explicit dependency from?

    Do we want to get into the habit of creating dependencies on nice-to-haves?

    This is the second instance of "memory usage" in this thread as grounds for a dependency on 5.4 so I have the distinct impression I must be missing something ... someone please let me know if this is the case.

    When I profiled 5.4 vs 5.3 I didn't see a significant memory savings at all. The benchmark that was published was not really a great test. Performance should not be factor if we're considering a dependency on 5.4.

    Traits on the other hand are worth a dependency IMO.

    If @msonnabaum at #12 is correct, then 5.3 would be the best option IMO. Performance would offer a nice benefit for all Drupal sites and the people who use them, but language features are only useful for developers.

    If the only advantage is a language feature for developers, then we should be more worried about adoption of Drupal 9 then we should be worried about adoption of traits.

    Status:Needs review» Postponed

    Until we actually have an absolute need to use Traits, this should just be postponed. Traits, the short-hand array definitions, and the other things PHP 5.4 bring are nice to have, but in no way an absolute requirement to what we're trying to accomplish currently.

    Sounds like a good approach ... there are other ways to do similar things to traits, and we can weigh those against traits when concrete needs surface. If the need for traits is high enough (or not), then we have an answer.

    fwiw I agree with postponing this, the only thing that'd really tempt me would be JSON as CMI storage, but it's been my impression that that's by no means impossible to resolve on 5.3 either even if it wouldn't be as nice. Any contrib module can add a PHP 5.4 requirement if they want.

    Also I don't see a link here to #1463564: Drupal 8 does not work with PHP 5.3.2 (the version shipped with Ubuntu 10.04 LTS) where there was some pushback against raising the requirement to PHP 5.3.3.

    PHP 5.4 is necessary because it is a critical step towards PHP 6, which will be the new norm in a year or so. Let's push PHP 5.4 for D 8.

    Citation needed! There is no PHP 6 planned, or did I miss something?

    @webmaster-eddie, that information is simply not right - PHP6 is not anywhere near coming into fruition. It will not be the norm in a year or so since it won't be released in the next year. The jump from 5.2 to 5.3 has taken around 2 years and we are *finally* getting people to update.

    Responding to #1 I have the feeling that hosting companies are moving fast to 5.4, for example in bluehost is available now

    hmm suhosin support for php 5.4 wont come any time soon and many hosting companies run it:/
    eg dreamhost: https://discussion.dreamhost.com/thread-134403-post-156663.html

    i guess D8 + php 5.4 is a dream

    The question is not so much if we want to depend on 5.4 (which we likely don't want, for all reasons listed above), but if we want to support it, which we very much want because high-profile deployments, like the companies which currently provide most of the actual business to Drupal bigger companies, are already preparing that move, and would downgrade Drupal if it could not run on the then-current version, which has been 5.4 for a few months already.

    Actually, I already get critics at that type of customers, who do not understand why we do not already support it officially on D7.

    The question is not so much if we want to depend on 5.4 (which we likely don't want, for all reasons listed above), but if we want to support it,

    Not really.this actually is for depending on php 5.4

    What support 5.4 means? Drupal can already run on 5.4 and i am 100% sure that drupal 8 will "support" php 5.4.
    Right now i have 5.4.4 in my dev enviroment and run drupal 7.16

    Support 5.4 would mean there are tests to ensure 5.4 works and that existing test were run on a php 5.4.x environment and all pass. Plus, getting rid of all the warnings and such (there's actually quite a lot from the upgrade). On that note, #23 do you have a patch for running on your 5.4.4 environment?

    We don't have support for multiple environments with qa.drupal.org yet. It would be possible to upgrade all test bots to 5.4 to make support explicit - although then some contrib tests would start failing too so we'd need to schedule this for a specific date or something.

    I fully support moving testbots to PHP 5.4, as we don't want there to be a large lag time where lots of code breaks noisily on 5.4 like there was for 5.3.

    At our current development rate and PHP's current development rate, Drupal 9 may require PHP 5.5. :-)

    At this time I would definitely say PHP 5.3. However, as we all know memory is a major factor, especially for hosting companies. I don't know exactly how much you would gain off-hand, but I would think that any gain would be beneficial, and the faster they adopt PHP 5.4 the sooner they can see those benefits.

    I would wait a bit to gauge the momentum and to get a feel of what the big players are doing , and then make my decision. The bottom line PHP 5.3 is here and is being used now, but that alone should not tie us into the past as a hindrance to growth. If 5.4 if going to be prevalent enough when D8 is released, then I 'm not so sure it would wise to gamble on hacking on 5.3 to try to achieve similar results.

    Also isn't Symfony suppose to be a part of D8 and has it's own PHP requirement?

    Edit: I forgot to add that hosting companies usually won't upgrade right away until the new release has been out in the wild and well tested. That happens to be a necessary process for them, but it is also detrimental for trailblazers leading the way.

    Symfony2 requires PHP 5.3.3 or so, I believe. Drupal 8 already has a higher PHP requirement than Symfony. Symfony is also not going to drop PHP 5.3 support until Symfony3, which isn't even on the radar for quite some time. (Like, ask in 2015.)

    By the time Drupal 8 ships, developers will have a harder time finding a PHP 5.3 dev box than a 5.4 dev box. That's not the issue. The production environment is the challenge, which is generally more conservative.

    Much as I'd like to go 5.4 now, I don't think that's feasible for Drupal 8. We don't have much time left to even take advantage of it at this point, so let's save that for a big Drupal 9 Traits Initiative or something.

    They kind of snuck this in, but PHP 5.3 will reach end of life in March 2013 (http://php.net/archive/2012.php#id2012-12-20-1). That's before Drupal 8's release date. I don't know if that should play a part in the decision.

    Hostgator is 5.2 default with 5.3 optional http://support.hostgator.com/articles/hosting-guide/hardware-software/ph... They might switch to 5.3 Godaddy is now 5.3 default http://support.godaddy.com/help/article/7804/updating-to-php-53 and site5 said last fall they are 5.3 default soon as well https://twitter.com/site5/status/248605481969524737 I suspect Hostgator will follow. Perhaps 5.4 optional will be added, perhaps it won't -- I would say unless we have a compelling reason to enforce 5.4, don't.

    Yep, I agree with PHP 5.3 as long as people will get security fixes somehow (keeping in mind that some people might build their PHP installations from source).

    They kind of snuck this in, but PHP 5.3 will reach end of life in March 2013 (http://php.net/archive/2012.php#id2012-12-20-1).

    That doesn't say it will reach end of life then; it says it will enter the end of life cycle. And it also says critical bugs (i.e., security issues) will still get fixes after that.

    What it doesn't say is when the end of life cycle ends, which would be nice information :) I couldn't find any information about it anywhere. Maybe no one knows.

    On the php.internals list, there was an initial announcement that it'd be 1 year of security fixes, but after some discussion, the consensus seemed to be converging on "at least wait until 5.5.0 is out". But yeah, I don't think anyone knows a firm date yet.

    "Hindsight," I love it. Hey, let's consider the way it was in 2006 against were it will be in 2014. Much has changed since then, and also what "they" have to consider is also tied into their infrastructure. Now, companies of all sizes come and go, but I'm sitting right now in 2014 looking back at the companies I didn't know was going to make it--thinking to myself--I'm sure glad I bet on that flexibility rather than the wrong
    "they."

    "They" might be hip today, but not be hip tomorrow, who's to say? All I'm saying is that it is really not that clear cut. Yes, Drupal is tied into that very same infrastructure, but just by it's very nature it has more grit. What I mean by that is Drupal has more leeway and is more flexible of a product in what can be done with it. You can flavor it in many ways.

    I understand the need to support legacy systems, uh err, no wait I don't understand remember? I'm in 2014. You also might want to ask Microsoft or some of your favorite Linux distro's about legacy systems ... especially since they're suppose to be some mobile OS's coming out from some of them.

    Seems it would depend on how much 5.4 favors that change that is going on. I do believe upgrade was invented for that reason, and if I'm not mistaken isn't 5.4 built off of 5.3, so the point seems moot.
    I know, nobody asked me.

    Topcheese: I have no clue what you just said, other than the grammar flow sounded like an under-paid Indian kid working in a spam sweatshop.

    @Crell, gee, thanks for pointing that out. I'm guessing you won't have much luck with my prediction for 2013 either, so perhaps I should make that a bit more academic for this type of vehicle. Duly noted. :)

    Edit: Sorry, I forgot to try to help you out with my last post. I know of course there is more to the story that should be spelled out. The hindsight question is really a long story that needs to be told in blog form, but what I did was tried to condense it while still trying to make it meaningful. It is no easy task I'm sure to make multimillion dollar decisions, but I can imagine that it takes imagination to run such a company. Imagine that, a company with no imagination? From your reference we can get a glimpse of yours Crell.

    Topcheese: I still have no idea what you're saying. I can't tell if you're saying stick with 5.3, go to 5.4 now, or saying that my hosting company has no imagination. (Which makes even less sense, because I don't work for a hosting company and haven't mentioned my employer at all in this thread.)

    Status:Postponed» Closed (won't fix)

    I think it would be foolish to release D8 without support for 5.3

    Much as I'd like to go 5.4 now, I don't think that's feasible for Drupal 8. We don't have much time left to even take advantage of it at this point, so let's save that for a big Drupal 9 Traits Initiative or something.

    I would say unless we have a compelling reason to enforce 5.4, don't

    I cant find a major hosting company supporting 5.4 right now..only way to get 5.4 is vps or dedicated server..and i am pretty sure things will be more or less the same in a year.
    I think we can safely wont fix this issue..shipping drupal without support for 5.3 would be a huge loss in shared hosting market and would significantly slow down d8's adoption rate

    Should this be revisited before release a la #1463564: Drupal 8 does not work with PHP 5.3.2 (the version shipped with Ubuntu 10.04 LTS)?

    If PHP 5.3 is entering the EOL cycle (meaning no bugfixes), requiring PHP 5.4 still may be beneficial in case a PHP bug that significantly affects Drupal is discovered after release (unless making PHP 5.4 a requirement is possible for a Drupal 8 point release, which seems unlikely). There's still close to a year left before Drupal 8 is released, and the landscape may significantly change: no sense in predicting the future.

    well i dont think landscape there changes significantly..if you consider how hard was to get rid of php4, and that many hosts are still stuck to php 5.2 even 5.2 reached its EOL quite sometime now, i dont think i am predicting anything.
    btw there is also #1800122: Bump minimum version of php required to 5.3.10

    @Crell, I know I always get long-winded, so I'm working on something to help better explain which I will post. I'm guessing one could infer your host lacks imagination if that's what one wants to imagine, I couldn't say. Imagination is not Deja-vu as some would beg to differ. So, it is not about lacking imagination, but more about not doing the Deja-vu dance--you know don't reinvent the wheel, cross-platform, etc. Because of changelog and every living persons affinity for history. You will have people that hang on and are tied into that past. 5.2/5.3, classic cars, Elvis.

    To be honest When I see the issue title my first response is no way, but I'm beginning to think that the gains far outweigh the losses, which I don't perceive to be great, because just look at the industry as a whole and how it's moving. Let me ask you this.. Do you think your tablet or mobile phone cares which version it runs, and if it did, would it be the faster or the slower version? How about the end user? This much I can say with so many "Benchmark Bennie's" out there, I'm not so sure I'd chance it on an ISP/Host model. which one? Sure I'd take it in consideration because there are some good ones, but in 2013/14 "they" will probably need it just as bad or possibly ending up going the way of the dinosaur.

    No disrespect intended to those of you that keep the Benchmarks. You are our unsung heroes, but your time is coming 2013/2014. Well, I guess you can call that a prediction.

    Okay, I may not have enough credentials to answer such as million dollar question. That's probably why I don't have a million dollar business right now, but again I digress. I will however with my little bit of cred state this. I'm just wondering how can you release something knowing that the improvements from 5.4 would benefit all? There my be aches and pains, but televisions today come with Internet access, and now let's flash forward a bit ... with all those various ways to display information vs. all the various ways to serve it up?

    I been wanting to find and appropriate place for this topic, so please don't make me explain just yet here. I will hopefully find correct spot for it some day, but it is definitely a more academic subject matter. The topic that comes to mind here is bootloader. I don't know what I'm talking about, so I don't have an answer yet because I haven't put much thought into it. Again for some reason that's just what comes to mind when I think of those things I mentioned.

    And if the age-old adage does not ring true "Speed Kills." Then I guess Drupal had better come to the table with less filling tasting great! I'm not sure good looks alone will win you over when your fridge is taking longer to deliver the ice than it did freezing it.

    Drupal refrigerators? Surely I jest with the creators, but I do have to quote a song here "Just My Imagination." ;)

    Small update from #30-34: PHP 5.3's EOL has been given a reprieve and has 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.

    Ah, good we went with 5.3 then.

    Is Drupal 8 intended to run on PHP 5.4 if it's available (and maybe use some of the performance-enhancing features)? Perhaps this isn't the place for the question, so happily ignore it if not.

    Of course, same as Drupal 6 and 7 run on PHP 5.4 right now.

    Status:Closed (won't fix)» Active

    PHP 5.5 came out this week, and that officially put 5.3 into a limited support status. Security patches will only be committed for one year, and then PHP 5.3.x will no longer be supported. Given that, I think we should bump the minimum PHP version for Drupal to 5.4. Most shared hosts allow you to manually specify PHP 5.4, and I imagine that 5.4 will soon be the default.

    Site 5 allows for 5.4 as an option (http://kb.site5.com/php/how-to-change-your-php-version/)
    Hostgator allows for 5.4 as long as your hosting account was provisioned after May 1, 2013 (http://support.hostgator.com/articles/hosting-guide/hardware-software/ph...)
    Supported by Greengeeks as an option (http://kb.greengeeks.com/1838/what-version-of-php-does-greengeeks-use/)
    Supported by Bluehost as an option (https://my.bluehost.com/cgi/help/386)
    Apparently, Dreamhost lets you install your own PHP (http://wiki.dreamhost.com/Installing_PHP5), and there's a script to install PHP 5.4

    ...and it's not too hard to install it on a VPS.

    So difficulty and compatibility aside, I think it would be kind of bad to have an unsupported version of PHP as our minimum version requirements because that could be viewed as some kind of endorsement of that version. We should not be encouraging people to use outdated PHP installations. The situation with shared hosts has improved over the past few months, and it's only going to get better.

    I feel very strongly that we should bump the PHP version requirements for the D8 release.

    Feelings is not enough. We are close to an API freeze. Do we really have the time to refactor using Traits? Do we really need it? We need strong very arguments. Remember why we went to 5.3.10: we had genuine bugs (we had functions committed commented out because of it) and features (HTML5 parsing) that mandated 5.3.9 and 5.3.10 was just a secfix on top of that. I do not feel the same unbearable pressure to go 5.4.

    Okay, here's one: The session extension can now track the upload progress of files. We get file upload progress out of the box with no additional software/configuration needed (sure, we'll need a minor code change to use this, but that's easy and I'll volunteer to write it).

    Here's another: you can instantiate and then use a class on one line:

    $myCar = (new Car)->setSpeed(100)->setColor('blue');

    Another is that we now have callable typehints:

    function foo(callable $cb) {
        $cb();
    }

    Array dereferencing support:

    function fruit () {
        return array('a' => 'apple', 'b' => 'banana');
    }
    echo fruit()['a'];

    There's also "Improved performance of @ (silence) operator.", and safe_mode, magic quotes, and register_globals are gone.

    And again, it's not really about features - those are just a pleasant side effect. It's about not endorsing an unsupported version of PHP when there are supported alternatives available.

    Status:Active» Closed (won't fix)

    It's too late for core to take advantage of any of PHP 5.4's advantages, and contrib modules have been able to specify their own version requirements since Drupal 6 so they're free to do what they want.

    Given the current market penetration of 5.3 vs. 5.4, I really don't think we can justify it at this point. It would be nice, but 5.3 has another year of security support in it so it's only mostly-dead. :-) And there's enough servers running it (hello major Drupal hosts...) that it's barely even to zombie state.

    Title:Decide whether Drupal 8 should depend on PHP 5.4Decide when Drupal 8 should depend on PHP 5.4
    Status:Closed (won't fix)» Active

    5.3 has another year of security support in it so it's only mostly-dead.

    So basically, we'll lose security support for 5.3 when Drupal 8 is released. If we're not going to make this change now, we're going to need to make it in the future. At that point, we can't endorse 5.3 as the "minimum" when 5.4 really should be the minimum - not because of new features, but because 5.3 isn't supported anymore.

    I really don't think this is a question of whether or not we should bump the requirements - it's a question of when. Even if we can't use all that cool new stuff in Drupal core, saying that PHP 5.3 is the minimum would be like releasing Drupal 8 with a IE6 being the minimum. We will still have to support 5.3 for a while if we make it the minimum, and 3-5 years from now, that's going to be as ridiculous as trying to support PHP4.

    In just six months from when this issue was originally closed, most of the major hosting companies added support for PHP 5.4 as an option, and as support for 5.3 ends, PHP 5.4 will become the standard. We're not losing anyone by bumping the version requirements, and it opens the door for contrib to use all of the fancy new 5.4 features without have to declare a PHP version dependency.

    Status:Active» Postponed
    Issue tags:+revisit before beta

    ...I agree with Cameron.

    Status:Postponed» Active

    Ideally, this version bump would happen now. We need to definitively decide that this is not possible before postponing this issue.

    So in April I went to a talk by Andrew Nacin (one of the lead Wordpress developers); it was an early version of this keynote talk from php[tek] in May. Wordpress collects a lot of data on PHP hosting environments (since sites phone home to wordpress.org with this information), and given how ubiquitous Wordpress installs are they have a rich set of real world data about this.

    I do not remember the exact numbers but I believe it was roughly something like this:

    ~65% on PHP 5.2
    ~33% on PHP 5.3
    ~2% on PHP 5.4

    I'm sure the PHP 5.4 numbers will only go up with time, but still, feel free to draw your own conclusions :)

    Also, Drupal 7.0 was released on January 5, 2011 and one day later PHP 5.2 stopped being supported so we have plenty of history with this. I definitely don't think it was a mistake for Drupal 7 to support PHP 5.2 or to continue to support it now, though. First, just because the PHP team itself doesn't provide security support doesn't mean much (many Linux distros backport security patches way after that); second, I don't think it's Drupal's responsibility to try to enforce server security. If the code works, it should run. It's up to the server administrator to keep the environment secure.

    Status:Active» Closed (works as designed)

    I do not think we endorse. We endure. Endorsing was gophp5 's task. So no, I do not think this is going to happen.

    Title:Decide when Drupal 8 should depend on PHP 5.4Require PHP 5.4
    Version:8.x-dev» 9.x-dev
    Priority:Normal» Major
    Status:Closed (works as designed)» Active
    Issue tags:-revisit before beta

    Let's do this for the status instead.

    I don't see any point in raising the requirement unless there's a serious effort to remove the cruft as well, which would ideally some of which would be included in the initial patch. There's no reason not to do that for 9.x as soon as it opens up, but can't see any point before that.

    I don't agree that 'supporting' PHP 5.3 is endorsing it at all, Drupal 6 technically 'supports' PHP4 but the numbers running that now must be tiny (and we broke that support by accident a few times).

    If we ended up with a security issue that can only be fixed by requiring PHP 5.4, we could add a hook_requirements() warning, issue a PSA etc.

    Title:Require PHP 5.4Require PHP 5.5

    Well, I want generators.

    Generators don't allow you to do anything new. Iterators exist now…

    PHP 5.5 has an opcode cache component in core https://wiki.php.net/rfc/optimizerplus, which is a drop-in replacement for APC

    Issue tags:+revisit before beta

    We will still have to support 5.3 for a while if we make it the minimum, and 3-5 years from now, that's going to be as ridiculous as trying to support PHP4.

    This argument is strong enough to make the change on D8. PHP 5.3 will have its final death in 1 year... then, we will keep giving support after its final death for 2~4 years after its final death.

    Issue tags:-revisit before beta

    This argument is strong enough to make the change on D8.

    You are hilarious. http://w3techs.com/technologies/details/pl-php/5/all

    We're already dropping support for 41% of all PHP installations by requiring PHP 5.3. Let's not drop support for an additional 51.5%. Drupal 8 will have enough adoption challenges without being relegated to 5.3% of all PHP installations in the world. :P

    I'm removing "revisit before release" because given those statistics, this is a done deal, as far as I'm concerned.

    @webchick, the issue is already filed against 9.x, so I was adding the tag to revisit before the 9.x release. ;)

    Well, no need to revisit something that hasn't happened yet. :) And if those stats don't pick up significantly, this may not even be viable in D9. :\ Time for a GoPHP5.5 movement? :P

    webchick: I've already been giving thought to that. ;-) Give me a few weeks...

    Title:Require PHP 5.5Require PHP 5.4
    Version:9.x-dev» 8.x-dev

    Sorry, but I'd like to reopen the discussion for PHP 5.4 for D8.

    Reason: traits. ControllerBase and FormBase introduced a bunch of protected functions like t() and wrappers around injectable services. Which is great, except that there's a lot of classes in Drupal that don't inherit from one of these two. So we either need to duplicate all that boilerplate code throughout a bunch more classes, or we end up using different patterns in those other classes than in controllers/forms. Both options: boilerplate and inconsistency, are bad DX. Or, we do what I suggested in #2079797-11: Provide a trait for $this->t() and $this->formatPlural() and pull back on our goal of "inject all services", but that's also a type of inconsistency (e.g., we don't inject the translation manager, but we inject other services). However, with traits, we can have the best of all worlds: injectability everywhere, standardization on $this->SERVICE() as the invocation pattern everywhere, and no duplicated boilerplate.

    Drupal 8 will have enough adoption challenges without being relegated to 5.3% of all PHP installations in the world

    I think this is worth more analysis. Drupal currently only powers 1-2 % of websites worldwide. So 2% of websites having a choice of 5% of total hosting providers doesn't seem like an unworkable supply/demand mismatch. If someone has a reason to use Drupal 8 (i.e., something about Drupal 8 is compelling for that person), then finding a hosting provider that runs PHP 5.4 isn't hard. Even if it's only 5% of hosting providers, that's 5% of a very large number. The question is more like: how many site builders are stuck in organizations with recalcitrant IT departments who both refuse to run PHP 5.4 and disallow the site to be hosted externally? And that's with Ubuntu 14.04 LTS scheduled for release in April.

    For what it's worth, the organization that I'm working with right now has 5.4 available as an option from Red Hat SCL (a Red Hat supported repository with updated software versions). However, SCL doesn't include many PHP extensions, so for the project I'm working on, we're going to have to downgrade back to 5.3. However, this will not be the norm when this organization moves to D8 in a few years.

    Also, 5% of hosting providers provide PHP 5.4 as a default. This is not representative of the providers that have it available. I pointed to a few big hosting providers in #49 that allow 5.4 as an option (even though it's not the default). My opinion is: if you want the latest and greatest version of Drupal, you need to make sure your environment supports it. If you're unable or unwilling to upgrade to 5.4, then you get D7.

    all my dedicated servers have Debian 7 which come with PHP 5.4.4 so no problem at all for me.

    but i cant see many shared hosts support it..
    On one hand Drupal would force them to upgrade, on the other hand it would slow down the adoption rate significantly.

    Also:
    php 5.4 would make our life a lot easier in #1858196: [meta] Leverage Symfony Session components

    i cant see many shared hosts support it..

    Please stop saying this. It's demonstrably false (again, see #49, and that was months ago). It's supported, it's just not the default.

    Let's not forget that we're talking about core here. It's just not going to happen for D8. You can't win them all!

    The topmost reason for revisiting this is:

    You should bump the minimum PHP version to 5.4 either way, since 5.3 entered EOL in March 2013, limiting updates to security fixes. I wasn't able to find a clear statement on when 5.3 will be discontinued, but the majority of PHP core devs seem to prefer 1 year after entering EOL cycle, which appears to be in line with the PHP Release Process RFC.

    In short, it's probably safe to expect 5.3 to be dead (and insecure) as of March 2014 (→ 5.5 months from now).

    Sadly, companies like Red Hat are going to support PHP 5.3 with security patches until 2020. That doesn't mean that we should too, but just thought I'd throw it out there :)

    I think requiring a PHP version that hasn't been EOLed at the time of D8 release is a perfectly reasonable thing to do.

    I say be bullish about this like we are being about IE8.

    Additional info to #49.

    This is the answer from Hostgator Live Chat:

    You would have to purchase a new hosting package in order to change servers

    http://support.hostgator.com/articles/hosting-guide/hardware-software/wh...

    All old clients unable to use PHP 5.4. No free migration to new server.

    Just a sidenote: We are currently using phpunit 3.7, as phpunit 3.8 requires php >= 5.4, see https://packagist.org/packages/phpunit/phpunit

    You can/should run PHPUnit tests independently of Drupal, however. In either case, we should be updating the test bot.

    $ phpunit

    It is VERY CONTRADICTORY to state Drupal8 is going to be an enterprise system while not adopting PHP5.4 (or newer) thinking about shared hosts.

    "I think when people think big websites, they usually think Drupal, and when they think small blogs or limited small websites in complexity then they think WordPress," Buytaert said.

    source: http://www.computerworld.com.au/article/455954/drupal_8_re-architecting_...

    Drupal, please make up your mind! Are you going to be only enterprise or good for everyone?

    @sun on comment #74:

    In short, it's probably safe to expect 5.3 to be dead (and insecure) as of March 2014 (→ 5.5 months from now).

    Enterprise system running on EOLed (insecure) PHP, that's hilarious.

    Whose going to install and use it, and if you don't do the updates now, then you really going to have to do them later. Good luck with that as we know how fast vendors update software. To be enterprise level you really do need to raise the requirement here. Imho that is.

    this has nothing to do with security here.
    Drupal will not make your server secure, your sysadmin will.
    Requiring 5.4 with this reasoning is just wrong.

    What we should decide here is whether we want traits in Drupal 8 that bad, that we are willing to sacrifice losing some (not sure exactly how big this number is) installations in the first year of release..

    Yes, it has to do with security as we probably won't launch D9 before PHP5.3 stop supporting security fixes (1 year after EOL).

    Note that PHP 5.3 is our minimum requirement, of course you will be able to run D8 on 5.4, 5.5 and later versions.

    We are in API freeze now for several months and changing our minimum requirement is quite a severe API change.

    The EOL date of PHP 5.3 is no technical reason to make such an API change now. Although 5.4 seems to be widely supported now we should not throw off D8 testers now on 5.3 for no reason.

    We should discuss if PHP 5.4 traits give us the major benefit we need to improve our code base. @effulgentsia: could you provide some example code snippets before/after a possible transition to traits?

    I think at a minimum, if PHP 5.3.x is the minimum version, we need to *strongly* recommend PHP 5.4.x. That said, I fall on the side of having 5.4.x as the minimum version. Traits are awesome.

    I think a reasonably criteria is the Drupal 8 release date - if we say we are releasing after April of next year, that will put us after the release of Ubuntu 14.04 - the next LTS release that will contain PHP 5.4 by default. That will go a long way to changing the numbers webchick quotes in #65:

    You are hilarious. http://w3techs.com/technologies/details/pl-php/5/all

    We're already dropping support for 41% of all PHP installations by requiring PHP 5.3. Let's not drop support for an additional 51.5%. Drupal 8 will have enough adoption challenges without being relegated to 5.3% of all PHP installations in the world. :P

    I'm removing "revisit before release" because given those statistics, this is a done deal, as far as I'm concerned.

    As mentioned elsewhere on this thread, while PHP 5.3 and 5.2 are still *used* for the majority of PHP websites according to these statistics, what these numbers don't tell us is what percentage has PHP 5.4 *available*. I think it's fair to say that many of these websites just haven't had a major rebuild since March 2012 when PHP 5.4 became available, or don't have any software that requires PHP 5.4, and haven't bothered to upgrade.

    To me, I think there is an implication that if you want to run the latest, cutting edge software, you need have have a relatively recent platform. If people don't want to upgrade their platform, they don't get the toys.

    Klausi is right. Besides, the minimum version for Symfony 2 is 5.3, so they are not in it alone.

    +1 for PHP 5.4 as minimum version

    Issue summary:View changes

    Updated issue summary to include specific version numbers of distributions, operating systems and tools.

    Issue summary:View changes

    added mint OS

    Issue summary:View changes

    Updated issue summary.

    Issue summary:View changes

    Updated issue summary.

    Issue summary:View changes

    Updated issue summary.

    I'm using A2hosting.com and it offers PHP 5.2.17 thru PHP 5.5.0beta2

    It can draw a clear line to drop PHP 5.x at some point. let's say 2 years soon. It's always better than release a future product.

    During the time, hosting companies will update their systems. It's also giving time to customers to change their hosting on next bill year. Self-hosted users, they can start with PHP 5.5 now.

    Issue summary:View changes

    Fix Fedora link.

    I'll give another +1 for 5.4 as a minimum for D8, though my only argument is related to encouraging secure behavior and I agree that's not a super strong argument. The chart that webchick cited in comment #65 on August 3rd as showing 41% of PHP on 5.2 now shows 36.7% on 5.2. A fall of ~5.5% in 3 months sure seems like a strong/fast trend.

    Perhaps a way forward is for some 5.4 specific patch to be proposed - if we agree that it's worthwhile then this issue gains merit. So, someone have something like that they can add?

    The biggest win we'd get in D8 from PHP 5.4 far and away would be traits. See #2079797: Provide a trait for $this->t() and $this->formatPlural() as an example. Then, we could simply reference these traits in base classes as opposed to copy/pasting a bunch of methods and docs and crap 12+ times.

    This approach was discussed for about 2 seconds and then immediately dismissed during the DX discussions in Prague by alexpott, however, because the various LTS Linux distros out there do not and will not support PHP 5.4 until 2017 or so. :\

    Issue summary:View changes

    Updated issue summary.

    Thanks - updated the summary to include a link to that issue. If there are any others folks should definitely add them so we get a sense of the scale of the issue.

    because the various LTS Linux distros out there do not and will not support PHP 5.4 until 2017 or so

    Hmmm, it would be good to capture that into the issue summary because that's not what I see there now (I just reorganized it a bit, though I did not review/research them myself). For at least one data point contrary to the 2017 perspective: PHP 5.4 will be in Ubuntu LTS as of 2014, but it's also already available on 12.04 and 10.04 via alternate repositories.

    I agree that in theory the major distros backport security patches for php, but in reality there's been at least one case for Ubuntu where they didn't (it came up in a PCI scan that I don't have access to now - the servers were the Ubuntu LTS from 2008).

    Assigned:Unassigned» alexpott

    I don't really feel qualified to update the issue summary since I don't use any Linux distro, but tentatively assigning to Alex to provide more background. If this is to go forward, however, it needs to be a Dries decision IMO, since it will definitely affect D8 adoption, at least in the short term.

    Issue summary:View changes

    re-organizing and adding a link to an issue that would be helped by php 5.4+

    The chart that webchick cited in comment #65 on August 3rd as showing 41% of PHP on 5.2 now shows 36.7% on 5.2. A fall of ~5.5% in 3 months sure seems like a strong/fast trend.

    Probably more important to look at the trend for PHP 5.4. That shows:

    • ~2% in April (based on my comment in #56, though that is from a different source than the others)
    • 5.3% in August (from #65)
    • 8.7% today

    It's going up, but hard to tell where it will be when Drupal 8 is released.

    Issue summary:View changes

    added dreamhost

    Issue summary:View changes

    Updated issue summary.

    I don't see why that chart is relevant here, it says:

    This diagram shows the percentages of websites using various subversions of PHP 5.

    Shouldn't we care about support rather than usage?

    Most everyone misses my (and webchick's point): that Drupal requires PHP 5.3 does not mean your enterprise site must run with 5.3. It means Drupal can run with 5.3.10. Traits would be nice. phpunit 3.8 would be nice. These are niceties. The under 10% spread of 5.4+ is the hard reality.

    That ^^

    What we can do is set a warning in hook_requirements() when people use unsupported PHP versions, once they stop receive receiving support over time. We can do the same for PHP 5.4 when it will no longer receive support in 2015. However, I do not think we should place hardcoded limitations on the supported PHP version just for security reasons, especially if some OSs backport patches to the older PHP versions they ship with.

    As far as I can see it, the dilemma is What are the adoption rates? (see @chx's and @webchick's comments) versus What does Drupal need? With the likely adoption of Semantic Versioning and the addition of new features during Drupal 8's lifetime, our requirements for sustainable development will change. If we look ahead 1, 2, or 3 years, will PHP 5.4 allow us to make Drupal 8 even better after the 8.0 release without breaking backwards compatibility? Note that this applies to core only. Contributed modules are and always have been free to set their own PHP compatibility.

    Hell, we can (should?) add some well known exploits to the installer and if they succeed then spit out a requirements warning (error?). Drupal: white hat hacking your sites since 2014.

    I will preface this by saying that I think traits would be great, but are not enough of a reason to bump the version. I don't think we have enough concrete use cases besides translation.

    We have a history of supporting insecure versions, in a manner of speaking, but it could be interesting to take a more proactive security approach.

    That said, the arguments about existing installs seem entirely invalid. Didn't we kill the idea of using existing installs when we killed the upgrade path? It seems, without some hoop-jumping, that any existing install will require an additional server to upgrade. Judging by the issue summary, the majority of cheap hosts support 5.4 already. Ubuntu 12.04 is the only (non-enterprise) distro lacking, and 14.04 will be out before Drupal 8 anyway. Anyone using RHEL is compiling their own version.

    So...

    1. Cheap installs: covered. (need more data)
    2. Medium installs: covered.
    3. Enterprise installs: have the resources to do whatever they want.

    Just trying to break the argument into manageable parts so that it can be dealt with. It would be great to know the criteria we base these decisions on.

    All security and hosting concerns aside, I think it can be a good idea to keep in sync with Symfony 2 requirements in the case nobody would come to an agreement, as of today SF2's requirement is PHP 5.3.3. Even if they can bring some goodness PHP 5.4 features are not essential for Drupal. Meanwhile Drupal can run on 5.3 people will still be able to benefit from 5.4 and 5.5 security and performance gains anyway. Note that I am not personally affected if Drupal bumps to 5.4 since I'm used to work for decicated servers/VMs as targets, so I obviously don't care about what will be the final choice.

    Issue summary:View changes

    Updated issue summary.

    As has been said, but is worth reiterating: The 5.4 usage may be low, but 5.4 availability is high. I'll note that 5.4 usage is growing, as well.

    #102 mentions that Ubuntu 12.04 is php 5.3, but please remember that php 5.4+ is available for 12.04 from a well respected ppa.

    We have been proactive about server security as early as April 2006 #59378: Possbile security problem with $base_url and then again in January of 2008 we were more agressive. In other words: Drupal: white hat hacking your sites since 2014 2006.

    Issue summary:View changes

    clarify opening sentences

    So we have a bunch of "nice" (read: great, some badly needed) things on one side:

    • performance - we damn well need every bit of it
    • traits - cleaner codebase
    • security - D8 will probably be released around the time when PHP 5.3 won't receive security updates anymore
    • high availability

    and on the other side:

    • Ubuntu 12.04
    • low usage

    Given the lists above, shouldn't the question be: why do we still need to support 5.3?

    why do we still need to support 5.3?

    This is a better title so we don't gather reason for PHP 5.4, we gather reasons for not using PHP 5.3!

    This is a better title so we don't gather reason for PHP 5.4, we gather reasons for not using PHP 5.3!

    Pragmatically, it's the only reasons to switch to PHP 5.4 that has been revelant to this thread is the use of traits.

    If we can proceed without traits then it's PHP 5.3, if we can't then it's 5.4. so I think the question that should answered here is: "can we live without traits?".

    Security level is up to the hoster, which may or may not either patch its PHP binary, or upgrade it. You can't enforce the minimum requirement only with the only argument of the security: as long the code is 100% valid with PHP 5.3: doing this would mean block some users (even if it's only a minority of them). Facing this point you can only recommend that people should upgrade, but not enforce them to do so.

    Performance is not an valid point too: people may host a slow Drupal on PHP 5.3 but do excessive caching at higer levels (varnish, nginx, any other) which totally anihilates this point for those kind of sites. Once again, you can only recommend that people should upgrade, but not enforce them if they are happy with their PHP 5.3.

    I think actual usage is more important to look at than availability, since "availability" doesn't take into account the reality of costs, internal IT department issues, other software hosted on the same server, etc.

    1. Cheap installs: covered. (need more data)
    2. Medium installs: covered.
    3. Enterprise installs: have the resources to do whatever they want.

    I don't think this is accurate, or the right way to look at it. Rather I'd categorize things as follows:

    1. Sites hosted externally, e.g. via a commercial hosting provider: covered (at least for new installs).
    2. Sites hosted internally, but with the power, money, resources, technical ability, etc., to set up the hosting environment however they want: covered.
    3. Sites hosted internally, but without the above: not covered.

    The problem is that the third category encompasses a lot of organizations, including so-called "enterprise" organizations, that fall right into Drupal's current sweet spot (governments, universities, etc).

    That said, the arguments about existing installs seem entirely invalid. Didn't we kill the idea of using existing installs when we killed the upgrade path? It seems, without some hoop-jumping, that any existing install will require an additional server to upgrade.

    I'm not sure what that means, but it sounds scary....

    We don't need another server to upgrade with migrate; we just need a second Drupal site which can read the database of the first and if you have user uploaded files, then the files too. That's not relevant here anyways.

    Issue summary:View changes

    Added info for a new hosting company: A Small Orange.

    @chx Ehm… wrong issue? :D

    Nope I was answering "It seems, without some hoop-jumping, that any existing install will require an additional server to upgrade."

    The only exception with migrations would be if you had a Drupal 5 site that fatals or throws other serious errors on PHP 5.4, in that case the 5.4 requirement would mean you have to fix the compatibility issues, upgrade PHP version, then migrate - assuming you want to keep the old site live while working on the migration. Sites that actually fail on 5.4 should be very rare, so I don't think this is a real issue.

    There's also nothing stopping people from uploading patches to fix Drupal 5 on PHP 5.4, and in fact people do that. :) #1016008: Drupal 5 PHP 5.3/5.4 compatibility patch

    I don't think we have enough concrete use cases besides translation.

    We do. #2079797: Provide a trait for $this->t() and $this->formatPlural() is the canary issue, but if you look at ControllerBase, you'll see ~300 lines of code (currently, it might still grow) exposing the ability to dependency inject a dozen other low-level services. Half of these have been copied to FormBase already, and some of the others will probably need to be as well. Other than translation, none have yet been copied to PluginBase, but many will likely need to be.

    I think the question that should answered here is: "can we live without traits?"

    When a bunch of us were discussing this in Prague, we agreed that we can live with a dozen functions duplicated among 3 base classes. However, this might grow to two dozen functions duplicated among 6 base classes. Or more. We decided to keep proceeding with adding what's needed to every base class that needs it, and then switch to traits whenever that's approved (whether that's D8 or D9 is still uncertain).

    [PHP 5.4] was discussed for about 2 seconds and then immediately dismissed during the DX discussions in Prague by alexpott, however, because the various LTS Linux distros out there do not and will not support PHP 5.4 until 2017 or so.

    Sort of. What alexpott said is that Ubuntu 12.04 LTS will be supported until 2017, and while people can choose to upgrade to 14.04, many won't.

    Ubuntu 12.04 is php 5.3, but please remember that php 5.4+ is available for 12.04 from a well respected ppa

    Well, this issue is assigned to alexpott already, so I'll leave it to him to provide thoughts on that before we ask Dries to weigh in.

    #1858196: [meta] Leverage Symfony Session components would be improved if we can rely on Native SessionHandlerInterface from PHP 5.4

    Can someone familiar with that issue please provide a little more detail in either this issue's summary or that one as to what the improvement would be?

    PHP 5.4 introduced a new entirely-OO way of adding a session handler: http://www.php.net/manual/en/class.sessionhandler.php

    Symfony tries to model that in a way that you can define a Symfony session handler as an object but have it still work in 5.3, but attempts to make that work well in Drupal have been bumpy. At this point, I believe many of the remaining issues with that patch relate to the fact that testbot runs 5.3, but everyone working on it runs 5.4 so it's really hard to replicate the failures that testbot is reporting. Moving to 5.4 would not magically make that issue green (although in my dream world it would), but it would make completing it easier.

    in addition to #115 PHP 5.4 provides http://php.net/manual/en/function.session-status.php
    which would make fixing testbot's "session already started" errors a piece of cake (i have already tried successfully so thats not just an assumption)

    #114, you've convinced me. It does quickly spiral, especially when you add in contrib.

    Allow me to clarify my argument: There are basically 3 types of hosting options.

    1. Shared hosting
    2. Some kind of server. VPS, raw hardware, other
    3. Managed hosting.

    Shared hosting: The only drawback seems to be that some companies require a new site, install, server, docroot, whatever to upgrade. This doesn't strike me as such a problem, since to upgrade, at a minimum you will need another database. Some hosts allow more than one root, and you can do it side-by-side. So maybe a new server isn't technically required, but at least a new docroot and database is. Basically, you can't FTP a new version of your codebase and run update.php.

    Some kind of server: If you have the resources to manage a server, then you have the resources to upgrade PHP. Or are we assuming that these servers have no maintenance whatsoever? Going from 5.3 to 5.4 is trivial. As mentioned, there is very solid support for 5.4 on Ubuntu 12.04. You can literally switch from 5.3 to 5.4 to 5.5 and back in minutes.

    Managed host: Seems moot. Anyone offering managed hosting for Drupal will do whatever is necessary.

    All of this seems beside that fact. Upgrading Drupal is a costly endeavor. I know there's work being done on that front, and I applaud it. But re-configuring a server to support a different PHP version, even multiple versions, pales in comparison to the cost of updating custom code/themes. It doesn't seem reasonable that an organization will be willing to pay for an upgrade to Drupal 8, and then stop because their server runs 5.3. (Caveat: there are some organizations that are unwilling to change versions because of strict internal rules, but then that applies to Drupal as well.)

    Assigned:alexpott» Dries

    So reading the most recent arguments on this issue had me nodding. And looking at shared hosting company support and the availability and ease of using PHP5.4 on Ubuntu 12.04 I'm coming round to the point of view that moving to a supported version of PHP makes a lot of sense. I very much like changing the argument from usage to availability.

    There are a number of factors to consider here, on the plus side:

    On the negative side:

    • Internal hosted sites without the resources to upgrade #108 (@twistor's answer in #117 is a good one though)
    • We're freezing our APIs and this represents a huge change #84

    I think @klausi's comment about API freeze and @catch's comment about cruft removal means that we can not take this decision lightly but on balance of the arguments and weighing length PHP5.3's security support I'm changing my position to support adoption of PHP 5.4 as a minimum for Drupal 8. However, only Dries can take the final decision.

    Also, I started this conversation earlier today:
    https://groups.google.com/d/msg/php-fig/ogp03OHbVJ0/h9uoHKXvoYQJ

    In the first few hours the feedback is tentatively positive.

    Issue summary:View changes

    Updated issue summary.

    > Going from 5.3 to 5.4 is trivial.

    This is not true. There are seven core commits that has 5.4 in the commit mention.

    But 5.4 needs to be supported anyway, even if it's not required?

    The "Going from 5.3 to 5.4 is trivial" was about upgrading an Ubuntu server.

    Going from 5.3 to 5.4 is trivial.

    I read this as being with regard to server upgrade, not drupal upgrade as well (for the record).

    I was asked to weigh in on this with regard to plugins. I think there are a number of places we could really benefit and stream line the plugin system if we adopted traits. I've not played with traits at all yet, but I've done a little research.

    As the plugin system sits currently, there's a lot of inheritance. PluginBase in Core inherits from PluginBase in Component, ContextAwarePluginBase in both of those as well, with slightly different inheritance patterns, various plugin implementations with their own base classes and specifically configuration handling has been a big chore in this regard. Trying to figure out how to adapt, and inherit at these various levels, while not impossible, has certainly required a lot of thought and planning and rethinking.

    If we're seriously considering 5.4 at this point, I'd be really thrilled to attempt a demo-cleanup of some of the plugin system. Another place that would benefit is PluginManagers since they all inherit mappers and only like 2 of them need mapping. I don't think traits could actually clean up that problem completely, but they might mitigate some of the issues that I've always found a little "wtf-ish".

    Eclipse

    I just opened #2129953: Abstract entity status out to an interface and #2130937: Move entities' CRUD methods to a separate interface to improve DX by removing required, but unusable methods from entities and realized that traits will help us do this without possibly adding duplicate code.

    Most people are already convinced by the use cases of traits, but I wanted to show an example of how traits can benefit DX for code that is less-frequently used than t() as well.

    I know D6 has issues with PHP 5.4. So the other question is, if Drupal 7 recommended PHP 5.3.10 or great, will it also be guaranteed to work with PHP 5.4.x?

    If I try to install D6 with PHP 5.3.3, I get the message: "Your PHP installation is too old. Drupal requires at least PHP 5.3.10. See the system requirements page for more information."

    Does this mean I can use PHP 5.4.x? What about PHP 5.5.x?

    iantresman: If Drupal 6 or Drupal 7 don't work correctly on PHP 5.4 or 5.5, that's a bug and should be filed as one. But that's really off topic for this thread which is exclusively about the minimum version for Drupal 8.

    Issue summary:View changes

    Some more host data, courtesy of a WordPresser. (Is that the right term?)

    https://groups.google.com/d/msg/php-fig/ogp03OHbVJ0/J52R8vpsstoJ

    I've updated the summary as well.

    Short version: I think the dam has broken on 5.4, and given that Drupal 8 is still only in alpha I will add my voice to those saying 5.4 is "safe enough", especially given the DX benefits it has.

    *goes back to the FIG list to try and coordinate pushing for 5.5...*

    I'm curious if there's anyone following this issue who works for a university or other organization that manages websites internally and with restrictive IT rules or restricted resources, and if so, whether you agree or disagree with the conclusion of #117: that if you have the approval/resources to use a new major version of Drupal, then it's not much additional burden to use a PHP version that might not be the one your LTS Linux distro is running by default but is available through a well respected ppa.

    Did anyone read #120? If you did, did you understand what it means? It means that even the highest quality codebases need a lot of fixes to be 5.4 compatible. If you nilly-willy upgrade to 5.4 someone's script is going to break. Guaranteed.

    To be blunt: it isn't risk enough for you fine people to release a version which is developer hostile, slow, broken, haphazardly stiched together from all sorts of broken trash but you want to make it hosting hostile as well. Got it.

    Assigned:Dries» Unassigned
    Priority:Major» Critical

    Having read the different pros and cons in this issue, and keeping the Drupal 8 timeline into account, I believe it is safe for Drupal 8 to require PHP 5.4.

    The only caveat is that I'd propose that we need to make Drupal 6 core run on PHP 5.4 so people can migrate from Drupal 6 to Drupal 8. If Drupal 6 doesn't run on PHP 5.4, we should create critical bugs for that, and these critical bugs should prevent Drupal 8 from being released.

    Given that PHP 5.3 will be end-of-life in about 8 months and that the PHP team won't provide security fixes for PHP 5.3, we'll have to start making PHP 5.4 compatibility bugs critical security bugs. We can't ask people to run on an insecure version of PHP to get/keep Drupal 6 working.

    I also encourage Contrib module maintainers to fix any PHP 5.4 compatibility bugs on their Drupal 6 branches. It's the correct thing to do from a security point of view as well as in making sure people can migrate from Drupal 6 to Drupal 8.

    We should make this requirement change and announce it broadly as soon as possible, so that core developers can begin to use 5.4-only features and so that site owners who are interested in adopting Drupal 8 can plan to upgrade their PHP version.

    Thanks, Dries! And I agree, all currently supported versions of core need to run successfully on 5.4 and 5.5.

    I think step 1 then is to ensure that 8.x runs on 5.4 cleanly so we can get testbot upgraded to 5.4. Right now, any 5.4-specific code will still break the testbot linter. Once testbot is running on 5.4 we can begin posting patches, and that will also act as a good test to ensure that Drupal 7 is also fully 5.4-friendly.

    (We may want to keep an old bot around to ensure no 5.4-specific features sneak into Drupal 7, but I guess we don't do that now and we've been OK so maybe it's not necessary.)

    Status:Active» Needs review
    StatusFileSize
    new3.04 KB
    FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
    [ View ]

    Status:Needs review» Needs work

    The last submitted patch, 131: drupal_1498574_130.patch, failed testing.

    lets all get started on array dereferencing patches!

    Issue summary:View changes

    ...adding the issues from #123 to the list of issues mentioned in the issue summary that would be helped by requiring PHP 5.4.

    @Xano: could you please double-check that I got everything right?

    At some point,
    https://drupal.org/requirements
    will have to be updated.

    HEAD is passing on 5.4: https://qa.drupal.org/pifr/test/600303

    So this is now an infra issue.

    If a distro supports php 5.4 does not mean that vserver and other hoster will do. I was often in situation that these provide very old images. Often 2 years old and you cannot upgrade yourself.

    Is't it not godaddy that still runs on apache 1.x? At least they had 1-2 years ago. Availability does not automatically mean that users are able to use it.

    StatusFileSize
    new7.25 KB
    new10.54 KB
    FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
    [ View ]

    I removed all additional references to safe_mode, magic_quotes, and register_globals. I did not touch the tar archiver, because even though it is part of core, it really is a third party library that was included verbatim and should perhaps move to the vendor directory?

    So we are willing to even consider not adopting a newer/better/faster/safer/supported version of php simply because some hard-headed hosting companies refuse to regularly update the distros they offer. Is that it? So then, we what we do is babysit these companies by acting in their interest instead of acting for the benefit of our customers/end-users/developers. Yeah, that's the way to go.

    IMNSHO, I think that the answer to the people coming to us saying that they cannot run D8 in hosting company X because they only offer outdated distros/software is to suggest other hosting companies. I'm pretty sure that it won't be too long before these hosting companies will change their mind about how often they upgrade their software once the see their customers moving to other hosters.

    Bottom line is that the right thing to do is base our decision on availability of php 5.4 (or rather ease of availability) rather than usage stats.

    Status:Needs work» Needs review

    Status:Needs review» Needs work

    The last submitted patch, 139: drupal_1498574_139.patch, failed testing.

    *bows head*

    So it mote be.

    Making D6 run with PHP 5.4 is not even possible as D6 supports PHP4 and you can't make things like Views support both. Even for core, I have no idea how we would achieve that when we do not have a test suite.

    Migrate will work with the http file wrapper, there's no reason not to so files can be copied from remote. You just need a db connection. Or a server with multiple PHP versions which many hosters support.

    Also, a friendly note: I will begin deleting comments who continue the debate on whether we should support PHP 5.4 or not. The decision is made.

    please can we not couple requiring 5.4 for D8 and the D7 and D6 suggestions.

    to be clear, i support 5.4 as a requirement for D8.

    however, i don't see any reason to force the D6 code base to run on 5.4 for the migration. there are other ways to skin that cat, and we should stop and think about that before we declare that we need critical bugs in D6 for incompatibilities with php 5.4.

    Yup, 100% agree with chx and beejeebus here. Running on the same server is not even mildly a requirement. The only real requirement is access to the same database. So long as our mysql driver supports D6 era mysql, we should be just fine. (I recently used migrate to do a d5-d7 upgrade w/o problems, so I think we're covered, but we should dot those i's and cross those t's.

    Eclipse

    PHP 5.4.0 or PHP 5.4.21?

    Since security was one of the reasons here, we should target at least 5.4.2.

    @chx, #144: I'm with you in the "The decision is made." part (I was in favor of raising php version requirement almost since day 1 to start with), but we shouldn't mute people from expressing their opinion. That was not a friendly note at all :p

    And a followup for the D6 problems pointed out by chx.

    Running D6 on 5.4 isn't very complicated. I have multiple sites running it now. These are large ubercart sites, so not trivial. You just have to fuss with the error reporting, to hush up views, and I believe the dev version of ctools is required for something.

    Status:Needs work» Reviewed & tested by the community

    Decision made, follow ups created. Anything else to do here?
    Time to close this issue.

    Status:Reviewed & tested by the community» Needs work

    This isn't anywhere near RTBC until at least the patch in #139 is reviewed and confirmed to work, which is impossible to do automatically, unless we keep needs-reviewing this issue until a PHP 5.4-powered testbot happens to pick up the patch.

    #149 is wrong , the time for opinions on this topic is past. We will never make progress if we try to second guess every decision Dries makes. This project is such that he calls the shots. We have voiced the pros and cons and he made a decision. If you don't like it, I pray, there are other projects where he is not calling the shots. I deleted the irrelevant comments.

    Status:Needs work» Needs review
    StatusFileSize
    new10.55 KB
    FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed.
    [ View ]
    new2.44 KB

    rerolled 138

    Status:Needs review» Needs work

    The last submitted patch, 159: drupal_1498574_158.patch, failed testing.

    We will never make progress if we try to second guess every decision Dries makes.

    That's happened lots of times over many years without completely halting progress.

    For example pretty much every module that was removed from 8.x (and one or two from 7.x) had previously been firmly refused by Dries in previous versions, all the way back to 2005/6 or so. Lots of people, including me, ignored that and kept pushing every few months, and eventually those decisions were reversed. It's entirely OK for people to disagree with a decision after it's been made and continue to state so in issues around that. When people disagree with things then bring it up in unrelated issues all over the place that's less conducive to being able to discuss things usefully.

    ...exactly what catch said above. I'm not saying we should revert the decision, but do let people express their opinions freely.

    Drupal 8 with PHP 5.4+ is great news but what is limiting D8 to be on PHP 5.5+?
    Next Ubuntu LTS is coming in 5 months (that is also a possible date for D8.0 release) will have PHP 5.5 installed.

    Issue tags:+beta blocker

    re #163, I think we're probably pushing it as hard as is advisable with a 5.4.x dependency, and that should give us a pretty good long life of php support as well.

    Eclipse

    Well then. I will not try to police our regular trolls.

    One, as it begins to emerge, requiring 5.4 will require D6 work. Either we somehow make the whole Drupal 6 ecosystem PHP 5.4 compatible or we will need to make migrate work over HTTP requests which is doable but certainly involves D6 development.

    Two, you wanted opinions? My problem is this: I do not know. I am constantly trying to put myself of others shoes who might or might not exist. But they might and as https://drupal.org/comment/8173465#comment-8173465 points out we have no way to communicate with them.

    This is killing me. This has been killing me the whole cycle. We are operating in an echo chamber and we have zero input from real people. We are changing so much, what will happen? Will this be a great Drupal release which has REST support and whatnot? Will this be a patchwork monster of old procedural code and modern OOP code from Symfony that noone will touch? We have added so many patterns to D8, is it too much to learn? Or is it just the right tool for the job?

    If I am a Drupal core developer who deals with code only then dealing with only two PHP branches for the years to come is delightful and using Traits will be helpful. If I am a Drupal community member worried senseless about Drupal 8 uptake then this worries me even further.

    I do not know whether requiring PHP 5.4 is a good idea or not but I do not think adding additional risk is worth. Dries thinks otherwise. I do not have proof that this will hinder uptake. You do not have proof that it won't. Cos we don't see the future.

    Great news that a decision has been made. People can now forward plan and just get on with it. However could someone update the requirements page please? It currently just states "Drupal 8: PHP 5.3.10 or higher.".

    https://drupal.org/requirements

    This page should also be updated https://drupal.org/requirements/php.

    This was the key that one of our project managers used that lead to nearly a weeks worth of work testing and migrating problematic sites to another server so we could upgrade to PHP 5.3 for Drupal 8.

    @chx
    There may be some head banging for a month or two after D8 is out from old crusty procedural developers (like myself) as we catch up with things, but I think the majority will learn to love it much more than the old procedural core and will be eternally grateful to the work of the core team.

    BTW. The learning curve is not that bad. Within a day, I had ported the Diff modules admin settings and hooked into the new router system to do the crazy diff 5.x style menu overrides for the revisions listings page, etc, while writing some blog posts on the process. :)

    The requirement page should also indicate which subversion of PHP 5.4. No point telling people to install PHP 5.4 minimum, if they actually need, for example, PHP 5.4.10.

    @chx, please stop by the Drupal community on G+ for a whole bunch of great people that you can ask questions to: https://plus.google.com/u/0/communities/111161359890617128846

    I do Coworking Hangouts on most Fridays and you're welcome to stop by and ask anyone who drops in the questions that concern you.

    Since this is already 171 comments of mostly people shouting over each other, I wonder if we want to close this as a [policy, no patch] issue, and start a new one to actually bring D8 into compliance, since that sounds like that might be another 30+ comments worth of work.

    I updated the page to say 5.4. I agree we should say which specific version, but it doesn't seem to me like we've reached consensus on a specific version of 5.4. I disagree a bit with #168: the most important thing in terms of compatibility is the 4 of 5.4 - the version beyond that will be much simpler to manage. Besides, better to have *something* about the big change now than leave it at 5.3 until we decide on an exact 5.4 version.

    I still think we can just commit the initial patch with 5.4.2 and maybe open a followup to discuss if we want something higher than that.

    We should also really prioritize getting test bot running 5.4 for all bots. There are some outstanding issues that could potentially benefit from this today.

    Eclipse

    How many testbots do we have? I don't want to derail this, but wouldn't it be a good idea as a follow-up to leave a bot running on 5.3 (the one currently recommended for D7) and another on 5.2 (the one currently recommended for D6)? Then we could figure a way to send tests to these bots specifically (perhaps a token in the patch filename) in order to test php-version-specific issues. If there is no specific php version defined in the uploaded patch filename, then the test should default to run against the php version that is set as the branch's recommended.

    Related to that idea - not to this issue: #66484: Allow issues to be filed against multiple versions/branches. / #1171958: Allow patches to be assigned to a certain branch/version and thus tested against it.

    #175:
    Testbots need to support D6, D7, and D8 testing, so it isn't simply a matter of 'upgrading PHP' on the servers. I recognize and am aware of the urgency, but to date have put my priority into helping address the release packaging issues on d.o D7, which I felt was slightly more critical.

    #176:
    We want to stay away from 'magic file naming' test parameters. We can easily add a test attribute to the definition passed to qa.d.o, but the major hurdle is getting the bots to do something with that, without breaking everything they already do today. I suggest further testbot-related discussion be moved over to #2135199: Provide php 5.4 testing on testbots for D8 code without breaking everything else.

    @jthorson,

    That was not intended to be condescending or anything. I realize you test bot guys work your asses off. ;-)

    Eclipse

    We support php 4 up to 6 years after EOL, but now we force php 5.4 that is currently only on 7% webservers installed (per WP stats) and php 5.2 (56%) + 5.3 (38%). Really interesting... This will become a clear fail for D8 deployment

    http://wordpress.org/about/stats/

    That's why I wrote this comment... 6 years after 4.x EOL, not ~6 months before 5.3 EOL and i guess 5.2 is already EOL, but still used on 56% of the websites. People cannot upgrade or do not care or disries patch EOLs themself with backports.

    PHP 4 went EOL on August 2008: 6 months *after* Drupal 6 was released. PHP 5.2 went EOL on Jan. 6, 2011: one day *after* Drupal 7 was released. Here we have a situation where PHP 5.3 will be EOL *before* Drupal 8 will be released.

    5.2 is already EOL, but still used on 56% of the websites. People cannot upgrade

    All the hosting companies listed in the issue summary will provide a PHP 5.4 option by the time Drupal 8 releases. Do you have a list of ones who won't?

    Issue summary:View changes

    By the way. . . just got off the phone with Bluehost. . . they are going to force us to PHP 5.4 very soon. There will be no support for version 5.3 or earlier. I also believe from the phone conversation that 5.3 or earlier will not even be a choice for us in C-Panel php.config for choice of engine. So even for D7, if we need to have 5.4 be standard for core and modules. Sorry for not reading through all 183 posts above but we need to make sure for D7 users.

    @AimAdvantage: thanks for the info on Bluehost. For D7 (and D6), the issue you might want to follow is #2135203: Compile a list of all known PHP 5.4 incompatibilities D6 and D7.

    Issue summary:View changes

    Added Gandi and OVH to the hosting providers in the issue summary. Reorganized hosting providers as well (ASC). Please keep it that way for readability. (see revision)

    Issue summary:View changes

    For the record, DreamHost, which I'm still on, allows use of PHP 5.4 as well. I just found out about this because I accidentally installed Drupal 8 on PHP 5.3.27 because this patch is not in yet. ;)

    Should we maybe close this as fixed, since the policy is decided, and split off cosmiscdream's fix into a dedicated issue without all of the opinions?

    Title:Require PHP 5.4[policy, no patch] Require PHP 5.4
    Status:Needs work» Fixed

    I created #2152073: Bump Drupal core's PHP requirement to 5.4.2 to add the actual hard requirement. Setting this issue to fixed as per @webchick in #189.

    There may be an issue with testing traits. See [#https://drupal.org/node/2159845].

    Status:Fixed» Closed (fixed)

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