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/)
- 18: 5.4.20 https://apps.fedoraproject.org/packages/php
- 19, 20, rawhide(dev): 5.5 https://apps.fedoraproject.org/packages/php
Operating Systems / Tools
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
- PHPnet - 2015-04: PHP 5.2, 5.3, 5.4, 5.5, 5.6
- Purley Hosting - PHP 5.4
- Site5: 5.3-5.4
- Vevida - PHP 5.3 - 5.5
- Webfusion - PHP 5.3 - 5.5 (on request)
Comment | File | Size | Author |
---|---|---|---|
#159 | interdiff_1498574_158.txt | 2.44 KB | cosmicdreams |
#159 | drupal_1498574_158.patch | 10.55 KB | cosmicdreams |
#139 | drupal_1498574_139.patch | 10.54 KB | Xano |
Comments
Comment #1
droplet CreditAttribution: droplet commentedI'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.
Comment #2
skottler CreditAttribution: skottler commented@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.
Comment #3
droplet CreditAttribution: droplet commented@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
Comment #4
Mike Wacker CreditAttribution: Mike Wacker commentedWe 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.
Comment #5
gagarine CreditAttribution: gagarine commentedDrupal 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...
Comment #6
Alan Evans CreditAttribution: Alan Evans commentedWhich 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.
Comment #7
RobLoachThe 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.
Comment #8
Alan Evans CreditAttribution: Alan Evans commentedThe 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.
Comment #9
plach@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.Comment #10
gddThe 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.
Comment #11
Alan Evans CreditAttribution: Alan Evans commentedThe 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.
Comment #12
msonnabaum CreditAttribution: msonnabaum commentedWhen 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.
Comment #13
Mike Wacker CreditAttribution: Mike Wacker commentedIf @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.
Comment #14
RobLoachUntil 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.
Comment #15
Alan Evans CreditAttribution: Alan Evans commentedSounds 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.
Comment #16
catchfwiw 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.
Comment #17
webmaster-eddie CreditAttribution: webmaster-eddie commentedPHP 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.
Comment #18
klausiCitation needed! There is no PHP 6 planned, or did I miss something?
Comment #19
skottler CreditAttribution: skottler commented@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.
Comment #20
rodrigoaguileraResponding to #1 I have the feeling that hosting companies are moving fast to 5.4, for example in bluehost is available now
Comment #21
ParisLiakos CreditAttribution: ParisLiakos commentedhmm 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
Comment #22
fgmThe 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.
Comment #23
ParisLiakos CreditAttribution: ParisLiakos commentedNot 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
Comment #24
coderintherye CreditAttribution: coderintherye commentedSupport 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?
Comment #25
catchWe 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.
Comment #26
Crell CreditAttribution: Crell commentedI 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. :-)
Comment #27
catchOpened #1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7.
Comment #28
Topcheese CreditAttribution: Topcheese commentedAt 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.
Comment #29
Crell CreditAttribution: Crell commentedSymfony2 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.
Comment #30
wizonesolutionsThey 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.
Comment #31
chx CreditAttribution: chx commentedHostgator 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.
Comment #32
wizonesolutionsYep, 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).
Comment #33
David_Rothstein CreditAttribution: David_Rothstein commentedThat 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.
Comment #34
Mark TrappOn 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.
Comment #35
Topcheese CreditAttribution: Topcheese commented"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.
Comment #36
Crell CreditAttribution: Crell commentedTopcheese: 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.
Comment #37
Topcheese CreditAttribution: Topcheese commented@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.
Comment #38
Crell CreditAttribution: Crell commentedTopcheese: 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.)
Comment #39
ParisLiakos CreditAttribution: ParisLiakos commentedI 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
Comment #40
Mark TrappShould 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.
Comment #41
ParisLiakos CreditAttribution: ParisLiakos commentedwell 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
Comment #42
Topcheese CreditAttribution: Topcheese commented@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.
Comment #43
Topcheese CreditAttribution: Topcheese commentedOkay, 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.
Comment #44
Topcheese CreditAttribution: Topcheese commentedAnd 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." ;)
Comment #45
mgiffordAdding link to - http://drupal.org/requirements
Comment #46
Mark TrappSmall 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.
Comment #47
wizonesolutionsAh, 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.
Comment #48
klausiOf course, same as Drupal 6 and 7 run on PHP 5.4 right now.
Comment #49
cweagansPHP 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.
Comment #50
chx CreditAttribution: chx commentedFeelings 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.
Comment #51
cweagansOkay, 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:
Array dereferencing support:
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.
Comment #52
Crell CreditAttribution: Crell commentedIt'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.
Comment #53
cweagansSo 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.
Comment #54
klonos...I agree with Cameron.
Comment #55
cweagansIdeally, this version bump would happen now. We need to definitively decide that this is not possible before postponing this issue.
Comment #56
David_Rothstein CreditAttribution: David_Rothstein commentedSo 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.
Comment #57
chx CreditAttribution: chx commentedI do not think we endorse. We endure. Endorsing was gophp5 's task. So no, I do not think this is going to happen.
Comment #58
catchLet'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.
Comment #59
chx CreditAttribution: chx commentedWell, I want generators.
Comment #60
msonnabaum CreditAttribution: msonnabaum commentedGenerators don't allow you to do anything new. Iterators exist now…
Comment #61
tstoecklerMarked #2029885: Bump minimum PHP requirement to 5.4.0 as a duplicate.
Comment #62
skyredwangPHP 5.5 has an opcode cache component in core https://wiki.php.net/rfc/optimizerplus, which is a drop-in replacement for APC
Comment #63
xjmComment #64
Mac_Weber CreditAttribution: Mac_Weber commentedThis 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.
Comment #65
webchickYou 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.
Comment #66
xjm@webchick, the issue is already filed against 9.x, so I was adding the tag to revisit before the 9.x release. ;)
Comment #67
webchickWell, 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
Comment #68
Crell CreditAttribution: Crell commentedwebchick: I've already been giving thought to that. ;-) Give me a few weeks...
Comment #69
effulgentsia CreditAttribution: effulgentsia commentedSorry, 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.
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.
Comment #70
cweagansFor 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.
Comment #71
ParisLiakos CreditAttribution: ParisLiakos commentedall 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
Comment #72
cweagansPlease stop saying this. It's demonstrably false (again, see #49, and that was months ago). It's supported, it's just not the default.
Comment #73
Topcheese CreditAttribution: Topcheese commentedLet'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!
Comment #74
sunThe topmost reason for revisiting this is:
Comment #75
cweagansSadly, 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 :)
Comment #76
jbrown CreditAttribution: jbrown commentedI 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.
Comment #77
droplet CreditAttribution: droplet commentedAdditional info to #49.
This is the answer from Hostgator Live Chat:
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.
Comment #78
dawehnerJust a sidenote: We are currently using phpunit 3.7, as phpunit 3.8 requires php >= 5.4, see https://packagist.org/packages/phpunit/phpunit
Comment #79
RobLoachYou can/should run PHPUnit tests independently of Drupal, however. In either case, we should be updating the test bot.
Comment #80
Mac_Weber CreditAttribution: Mac_Weber commentedIt is VERY CONTRADICTORY to state Drupal8 is going to be an enterprise system while not adopting PHP5.4 (or newer) thinking about shared hosts.
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:
Enterprise system running on EOLed (insecure) PHP, that's hilarious.
Comment #81
Topcheese CreditAttribution: Topcheese commentedWhose 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.
Comment #82
ParisLiakos CreditAttribution: ParisLiakos commentedthis 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..
Comment #83
Mac_Weber CreditAttribution: Mac_Weber commentedYes, it has to do with security as we probably won't launch D9 before PHP5.3 stop supporting security fixes (1 year after EOL).
Comment #84
klausiNote 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?
Comment #85
jibran@klausi see #2079797-5: Provide a trait for $this->t() and $this->formatPlural()
Comment #86
brianV CreditAttribution: brianV commentedI 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:
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.
Comment #87
Topcheese CreditAttribution: Topcheese commentedKlausi is right. Besides, the minimum version for Symfony 2 is 5.3, so they are not in it alone.
Comment #88
claudiu.cristea+1 for PHP 5.4 as minimum version
Comment #89
cweagansFWIW: https://twitter.com/cweagans/status/392784327781543936
Comment #89.0
cosmicdreams CreditAttribution: cosmicdreams commentedUpdated issue summary to include specific version numbers of distributions, operating systems and tools.
Comment #89.1
heddnadded mint OS
Comment #89.2
cosmicdreams CreditAttribution: cosmicdreams commentedUpdated issue summary.
Comment #89.3
cosmicdreams CreditAttribution: cosmicdreams commentedUpdated issue summary.
Comment #89.4
cosmicdreams CreditAttribution: cosmicdreams commentedUpdated issue summary.
Comment #90
BeachsidePaul CreditAttribution: BeachsidePaul commentedI'm using A2hosting.com and it offers PHP 5.2.17 thru PHP 5.5.0beta2
Comment #91
droplet CreditAttribution: droplet commentedIt 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.
Comment #91.0
droplet CreditAttribution: droplet commentedFix Fedora link.
Comment #92
amateescu CreditAttribution: amateescu commentedYet another FWIW: https://twitter.com/ircmaxell/status/395293306097106944
Comment #93
gregglesI'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?
Comment #94
webchickThe 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. :\
Comment #94.0
webchickUpdated issue summary.
Comment #95
gregglesThanks - 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.
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).
Comment #96
webchickI 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.
Comment #96.0
webchickre-organizing and adding a link to an issue that would be helped by php 5.4+
Comment #97
David_Rothstein CreditAttribution: David_Rothstein commentedProbably more important to look at the trend for PHP 5.4. That shows:
It's going up, but hard to tell where it will be when Drupal 8 is released.
Comment #97.0
David_Rothstein CreditAttribution: David_Rothstein commentedadded dreamhost
Comment #97.1
chx CreditAttribution: chx commentedUpdated issue summary.
Comment #98
amateescu CreditAttribution: amateescu commentedI don't see why that chart is relevant here, it says:
Shouldn't we care about support rather than usage?
Comment #99
chx CreditAttribution: chx commentedMost 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.
Comment #100
XanoThat ^^
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.
Comment #101
chx CreditAttribution: chx commentedHell, 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.
Comment #102
twistor CreditAttribution: twistor commentedI 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...
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.
Comment #103
pounardAll 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.
Comment #103.0
pounardUpdated issue summary.
Comment #104
gregglesAs 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
20142006.Comment #104.0
gregglesclarify opening sentences
Comment #105
amateescu CreditAttribution: amateescu commentedSo we have a bunch of "nice" (read: great, some badly needed) things on one side:
and on the other side:
Given the lists above, shouldn't the question be: why do we still need to support 5.3?
Comment #106
yannickooThis is a better title so we don't gather reason for PHP 5.4, we gather reasons for not using PHP 5.3!
Comment #107
pounardPragmatically, 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.
Comment #108
David_Rothstein CreditAttribution: David_Rothstein commentedI 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.
I don't think this is accurate, or the right way to look at it. Rather I'd categorize things as follows:
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).
I'm not sure what that means, but it sounds scary....
Comment #109
chx CreditAttribution: chx commentedWe 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.
Comment #109.0
chx CreditAttribution: chx commentedAdded info for a new hosting company: A Small Orange.
Comment #110
yannickoo@chx Ehm… wrong issue? :D
Comment #111
chx CreditAttribution: chx commentedNope I was answering "It seems, without some hoop-jumping, that any existing install will require an additional server to upgrade."
Comment #112
catchThe 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.
Comment #113
webchickThere'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
Comment #114
effulgentsia CreditAttribution: effulgentsia commentedWe 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.
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).
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.
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.
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?
Comment #115
Crell CreditAttribution: Crell commentedPHP 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.
Comment #116
ParisLiakos CreditAttribution: ParisLiakos commentedin 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)
Comment #117
twistor CreditAttribution: twistor commented#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.
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.)
Comment #118
alexpottSo 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:
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.
Comment #119
Crell CreditAttribution: Crell commentedAlso, 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.
Comment #119.0
Crell CreditAttribution: Crell commentedUpdated issue summary.
Comment #120
chx CreditAttribution: chx commented> 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.
Comment #121
ar-jan CreditAttribution: ar-jan commentedBut 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.
Comment #122
EclipseGc CreditAttribution: EclipseGc commentedI 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
Comment #123
XanoI 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.Comment #124
iantresman CreditAttribution: iantresman commentedI 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?
Comment #125
Crell CreditAttribution: Crell commentediantresman: 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.
Comment #126
Crell CreditAttribution: Crell commentedSome 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...*
Comment #127
effulgentsia CreditAttribution: effulgentsia commentedI'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.
Comment #128
chx CreditAttribution: chx commentedDid 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.
Comment #129
Dries CreditAttribution: Dries commentedHaving 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.
Comment #130
Crell CreditAttribution: Crell commentedThanks, 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.)
Comment #131
XanoComment #133
sanguis CreditAttribution: sanguis commentedlets all get started on array dereferencing patches!
Comment #134
klonos...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?
Comment #135
XanoComment #136
YesCT CreditAttribution: YesCT commentedAt some point,
https://drupal.org/requirements
will have to be updated.
Comment #137
tim.plunkettHEAD is passing on 5.4: https://qa.drupal.org/pifr/test/600303
So this is now an infra issue.
Comment #138
hass CreditAttribution: hass commentedIf 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.
Comment #139
XanoI 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?
Comment #140
klonosSo 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.
Comment #141
heddnComment #143
chx CreditAttribution: chx commented*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.
Comment #144
chx CreditAttribution: chx commentedAlso, 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.
Comment #145
Anonymous (not verified) CreditAttribution: Anonymous commentedplease 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.
Comment #146
EclipseGc CreditAttribution: EclipseGc commentedYup, 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
Comment #147
iantresman CreditAttribution: iantresman commentedPHP 5.4.0 or PHP 5.4.21?
Comment #148
amateescu CreditAttribution: amateescu commentedSince security was one of the reasons here, we should target at least 5.4.2.
Comment #149
klonos@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
Comment #150
cosmicdreams CreditAttribution: cosmicdreams commentedAdd follow up issue: #2135197: Upgrade testbots to PHP 5.4
Comment #151
effulgentsia CreditAttribution: effulgentsia commentedAnd a followup for the D6 problems pointed out by chx.
Comment #155
twistor CreditAttribution: twistor commentedRunning 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.
Comment #156
cosmicdreams CreditAttribution: cosmicdreams commentedDecision made, follow ups created. Anything else to do here?
Time to close this issue.
Comment #157
XanoThis 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.
Comment #158
chx CreditAttribution: chx commented#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.
Comment #159
cosmicdreams CreditAttribution: cosmicdreams commentedrerolled 138
Comment #161
catchThat'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.
Comment #162
klonos...exactly what catch said above. I'm not saying we should revert the decision, but do let people express their opinions freely.
Comment #163
alesr CreditAttribution: alesr commentedDrupal 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.
Comment #164
alexpottComment #165
EclipseGc CreditAttribution: EclipseGc commentedre #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
Comment #166
chx CreditAttribution: chx commentedWell 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.
Comment #167
Alan D. CreditAttribution: Alan D. commentedGreat 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. :)
Comment #168
iantresman CreditAttribution: iantresman commentedThe 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.
Comment #169
cosmicdreams CreditAttribution: cosmicdreams commented@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.
Comment #170
klonos...removing related issues. I've added them all as child/follow-ups to this one. That was a pain because we currently don't have: #2130889: Allow adding child/follow-up issues directly from the parent issue and converting related issues to children.
Comment #171
klonos...and I never mean to remove the tag (#2136389: Consolidate successive comments from the same user that update the issue summary and/or its metadata into a single comment).
Comment #172
webchickSince 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.
Comment #173
gregglesI 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.
Comment #174
amateescu CreditAttribution: amateescu commentedI 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.
Comment #175
EclipseGc CreditAttribution: EclipseGc commentedWe 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
Comment #176
klonosHow 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 files to be assigned to branch(es)/version(s) and thus tested against it
Comment #177
jthorson CreditAttribution: jthorson commented#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.
Comment #178
EclipseGc CreditAttribution: EclipseGc commented@jthorson,
That was not intended to be condescending or anything. I realize you test bot guys work your asses off. ;-)
Eclipse
Comment #179
hass CreditAttribution: hass commentedWe 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/
Comment #180
gregglesRe #179, please see #2140113: [Policy] Stop supporting PHP 4.
Comment #181
hass CreditAttribution: hass commentedThat'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.
Comment #182
effulgentsia CreditAttribution: effulgentsia commentedPHP 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.
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?
Comment #183
pfrenssenComment #184
AimAdvantage CreditAttribution: AimAdvantage commentedBy 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.
Comment #185
effulgentsia CreditAttribution: effulgentsia commented@AimAdvantage: thanks for the info on Bluehost. For D7 (and D6), the issue you might want to follow is #2135203: Fix all known PHP 5.4 incompatibilities on D6 and D7 that are critical or would prevent a migration to D8.
Comment #186
anavarreComment #187
anavarreAdded 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)
Comment #188
iantresman CreditAttribution: iantresman commentedComment #189
webchickFor 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?
Comment #190
XanoI 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.
Comment #191
XanoThere may be an issue with testing traits. See [#https://drupal.org/node/2159845].
Comment #193
YesCT CreditAttribution: YesCT commented.
Comment #194
fgm