text:
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
#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
- 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 #1droplet CreditAttribution: droplet commented
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.
Comment #2skottler CreditAttribution: skottler commented
|» 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.
Comment #3droplet CreditAttribution: droplet commented
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 #4Mike Wacker CreditAttribution: Mike Wacker commented
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.
Comment #5gagarine CreditAttribution: gagarine commented
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...
Comment #6Alan Evans CreditAttribution: Alan Evans commented
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.
Comment #7RobLoach CreditAttribution: RobLoach commented
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.
Comment #8Alan Evans CreditAttribution: Alan Evans commented
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.
Comment #9plach CreditAttribution: plach commented
@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 #10heyrocker CreditAttribution: heyrocker commented
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.
Comment #11Alan Evans CreditAttribution: Alan Evans commented
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.
Comment #12msonnabaum CreditAttribution: msonnabaum commented
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.
Comment #13Mike Wacker CreditAttribution: Mike Wacker commented
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.
Comment #14RobLoach CreditAttribution: RobLoach commented
|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.
Comment #15Alan Evans CreditAttribution: Alan Evans commented
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.
Comment #16catch CreditAttribution: catch commented
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.
Comment #17webmaster-eddie CreditAttribution: webmaster-eddie commented
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.
Comment #19skottler 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 #20rodrigoaguilera CreditAttribution: rodrigoaguilera commented
Responding to #1 I have the feeling that hosting companies are moving fast to 5.4, for example in bluehost is available now
Comment #21ParisLiakos CreditAttribution: ParisLiakos commented
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
Comment #22fgm CreditAttribution: fgm commented
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.
Comment #23ParisLiakos CreditAttribution: ParisLiakos commented
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
Comment #24coderintherye CreditAttribution: coderintherye commented
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?
Comment #25catch CreditAttribution: catch commented
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.
Comment #26Crell CreditAttribution: Crell commented
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. :-)
Comment #27catch CreditAttribution: catch commented
Comment #28Topcheese CreditAttribution: Topcheese commented
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.
Comment #29Crell CreditAttribution: Crell commented
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.
Comment #30wizonesolutions CreditAttribution: wizonesolutions commented
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.
Comment #31chx CreditAttribution: chx commented
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.
Comment #32wizonesolutions CreditAttribution: wizonesolutions commented
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).
Comment #33David_Rothstein CreditAttribution: David_Rothstein commented
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.
Comment #34Mark Trapp CreditAttribution: Mark Trapp commented
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.
Comment #35Topcheese 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" 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 #36Crell CreditAttribution: Crell commented
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.
Comment #37Topcheese 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 #38Crell CreditAttribution: Crell commented
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.)
Comment #39ParisLiakos CreditAttribution: ParisLiakos commented
|» 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
Comment #40Mark Trapp CreditAttribution: Mark Trapp commented
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.
Comment #41ParisLiakos CreditAttribution: ParisLiakos commented
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
Comment #42Topcheese 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 #43Topcheese CreditAttribution: Topcheese commented
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.
Comment #44Topcheese CreditAttribution: Topcheese commented
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." ;)
Comment #45mgifford CreditAttribution: mgifford commented
Comment #46Mark Trapp CreditAttribution: Mark Trapp commented
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.
Comment #47wizonesolutions CreditAttribution: wizonesolutions commented
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.
Comment #49cweagans CreditAttribution: cweagans commented
|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.
Comment #50chx CreditAttribution: chx commented
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.
Comment #51cweagans CreditAttribution: cweagans commented
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) {
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.
Comment #52Crell CreditAttribution: Crell commented
|» 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.
Comment #53cweagans CreditAttribution: cweagans commented
|Decide whether Drupal 8 should depend on PHP 5.4
|» Decide when Drupal 8 should depend on PHP 5.4
|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.
Comment #54klonos CreditAttribution: klonos commented
...I agree with Cameron.
Comment #55cweagans CreditAttribution: cweagans commented
|» Active
Ideally, this version bump would happen now. We need to definitively decide that this is not possible before postponing this issue.
Comment #56David_Rothstein CreditAttribution: David_Rothstein commented
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.
Comment #57chx CreditAttribution: chx commented
|» 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.
Comment #58catch CreditAttribution: catch commented
|Decide when Drupal 8 should depend on PHP 5.4
|» Require PHP 5.4
|» 9.x-dev
|» Major
|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.
Comment #59chx CreditAttribution: chx commented
|Require PHP 5.4
|» Require PHP 5.5
Well, I want generators.
Comment #60msonnabaum CreditAttribution: msonnabaum commented
Generators don't allow you to do anything new. Iterators exist now…
Comment #61tstoeckler CreditAttribution: tstoeckler commented
Comment #62skyredwang CreditAttribution: skyredwang commented
PHP 5.5 has an opcode cache component in core https://wiki.php.net/rfc/optimizerplus, which is a drop-in replacement for APC
Comment #63xjm CreditAttribution: xjm commented
Comment #64Mac_Weber CreditAttribution: Mac_Weber commented
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.
Comment #65webchick CreditAttribution: webchick commented
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.
Comment #66xjm CreditAttribution: xjm commented
@webchick, the issue is already filed against 9.x, so I was adding the tag to revisit before the 9.x release. ;)
Comment #67webchick CreditAttribution: webchick commented
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
Comment #68Crell CreditAttribution: Crell commented
webchick: I've already been giving thought to that. ;-) Give me a few weeks...
Comment #69effulgentsia CreditAttribution: effulgentsia commented
|Require PHP 5.5
|» Require PHP 5.4
|» 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.
Comment #70cweagans CreditAttribution: cweagans commented
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.
Comment #71ParisLiakos CreditAttribution: ParisLiakos commented
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.
php 5.4 would make our life a lot easier in #1858196: [meta] Leverage Symfony Session components
Comment #72cweagans CreditAttribution: cweagans commented
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.
Comment #73Topcheese CreditAttribution: Topcheese commented
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!
Comment #74sun CreditAttribution: sun commented
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).
Comment #75cweagans CreditAttribution: cweagans commented
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 :)
Comment #76jbrown CreditAttribution: jbrown commented
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.
Comment #77droplet CreditAttribution: droplet commented
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
All old clients unable to use PHP 5.4. No free migration to new server.
Comment #78dawehner CreditAttribution: dawehner commented
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
Comment #79RobLoach CreditAttribution: RobLoach commented
You can/should run PHPUnit tests independently of Drupal, however. In either case, we should be updating the test bot.
$ phpunit
Comment #80Mac_Weber CreditAttribution: Mac_Weber commented
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.
Comment #81Topcheese CreditAttribution: Topcheese commented
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.
Comment #82ParisLiakos CreditAttribution: ParisLiakos commented
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..
Comment #83Mac_Weber CreditAttribution: Mac_Weber commented
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).
Comment #85jibran CreditAttribution: jibran commented
Comment #86brianV CreditAttribution: brianV commented
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.
Comment #87Topcheese CreditAttribution: Topcheese commented
Klausi is right. Besides, the minimum version for Symfony 2 is 5.3, so they are not in it alone.
Comment #88claudiu.cristea CreditAttribution: claudiu.cristea commented
+1 for PHP 5.4 as minimum version
Comment #89cweagans CreditAttribution: cweagans commented
Comment #89.0cosmicdreams CreditAttribution: cosmicdreams commented
Updated issue summary to include specific version numbers of distributions, operating systems and tools.
Comment #89.1heddn CreditAttribution: heddn commented
added mint OS
Comment #89.2cosmicdreams CreditAttribution: cosmicdreams commented
Comment #89.3cosmicdreams CreditAttribution: cosmicdreams commented
Comment #89.4cosmicdreams CreditAttribution: cosmicdreams commented
Comment #90BeachsidePaul CreditAttribution: BeachsidePaul commented
I'm using A2hosting.com and it offers PHP 5.2.17 thru PHP 5.5.0beta2
Comment #91droplet CreditAttribution: droplet commented
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.
Comment #91.0droplet CreditAttribution: droplet commented
Fix Fedora link.
Comment #92amateescu CreditAttribution: amateescu commented
Comment #93greggles CreditAttribution: greggles commented
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?
Comment #94webchick CreditAttribution: webchick commented
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. :\
Comment #94.0webchick CreditAttribution: webchick commented
Comment #95greggles CreditAttribution: greggles commented
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).
Comment #96webchick CreditAttribution: webchick commented
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.
Comment #96.0webchick CreditAttribution: webchick commented
re-organizing and adding a link to an issue that would be helped by php 5.4+
Comment #97David_Rothstein CreditAttribution: David_Rothstein commented
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.
Comment #97.0David_Rothstein CreditAttribution: David_Rothstein commented
added dreamhost
Comment #97.1chx CreditAttribution: chx commented
Comment #98amateescu CreditAttribution: amateescu commented
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?
Comment #99chx CreditAttribution: chx commented
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.
Comment #100Xano CreditAttribution: Xano commented
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.
Comment #101chx CreditAttribution: chx commented
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.
Comment #102twistor CreditAttribution: twistor commented
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.
- Cheap installs: covered. (need more data)
- Medium installs: covered.
- 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.
Comment #103pounard CreditAttribution: pounard commented
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.
Comment #103.0pounard CreditAttribution: pounard commented
Comment #104greggles CreditAttribution: greggles commented
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.
Comment #104.0greggles CreditAttribution: greggles commented
clarify opening sentences
Comment #105amateescu CreditAttribution: amateescu commented
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?
Comment #106yannickoo CreditAttribution: yannickoo commented
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!
Comment #107pounard CreditAttribution: pounard commented
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.
Comment #108David_Rothstein CreditAttribution: David_Rothstein commented
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.
- Cheap installs: covered. (need more data)
- Medium installs: covered.
- 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:
- Sites hosted externally, e.g. via a commercial hosting provider: covered (at least for new installs).
- Sites hosted internally, but with the power, money, resources, technical ability, etc., to set up the hosting environment however they want: covered.
- 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....
Comment #109chx CreditAttribution: chx commented
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.
Comment #109.0chx CreditAttribution: chx commented
Added info for a new hosting company: A Small Orange.
Comment #110yannickoo CreditAttribution: yannickoo commented
@chx Ehm… wrong issue? :D
Comment #111chx CreditAttribution: chx commented
Nope I was answering "It seems, without some hoop-jumping, that any existing install will require an additional server to upgrade."
Comment #112catch CreditAttribution: catch commented
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.
Comment #113webchick CreditAttribution: webchick commented
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
Comment #114effulgentsia CreditAttribution: effulgentsia commented
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?
Comment #115Crell CreditAttribution: Crell commented
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.
Comment #116ParisLiakos CreditAttribution: ParisLiakos commented
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)
Comment #117twistor 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
- Some kind of server. VPS, raw hardware, other
- 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.)
Comment #118alexpott CreditAttribution: alexpott commented
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.
Comment #119Crell CreditAttribution: Crell commented
Also, I started this conversation earlier today:
In the first few hours the feedback is tentatively positive.
Comment #119.0Crell CreditAttribution: Crell commented
Comment #120chx 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 #121ar-jan CreditAttribution: ar-jan commented
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.
Comment #122EclipseGc CreditAttribution: EclipseGc commented
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".
Comment #123Xano CreditAttribution: Xano commented
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.
Comment #124iantresman CreditAttribution: iantresman commented
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?
Comment #125Crell CreditAttribution: Crell commented
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.
Comment #126Crell CreditAttribution: Crell commented
Some more host data, courtesy of a WordPresser. (Is that the right term?)
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 #127effulgentsia CreditAttribution: effulgentsia commented
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.
Comment #128chx CreditAttribution: chx commented
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.
Comment #129Dries CreditAttribution: Dries commented
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.
Comment #130Crell CreditAttribution: Crell commented
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.)
Comment #131Xano CreditAttribution: Xano commented
|» Needs review
Comment #133sanguis CreditAttribution: sanguis commented
lets all get started on array dereferencing patches!
Comment #134klonos CreditAttribution: klonos commented
...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 #135Xano CreditAttribution: Xano commented
Comment #136YesCT CreditAttribution: YesCT commented
Comment #137tim.plunkett CreditAttribution: tim.plunkett commented
Comment #138hass CreditAttribution: hass commented
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.
Comment #139Xano CreditAttribution: Xano commented
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?
Comment #140klonos CreditAttribution: klonos commented
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.
Comment #141heddn CreditAttribution: heddn commented
|Needs work
|» Needs review
Comment #143chx 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 #144chx CreditAttribution: chx commented
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.
Comment #145beejeebus CreditAttribution: beejeebus commented
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.
Comment #146EclipseGc CreditAttribution: EclipseGc commented
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.
Comment #147iantresman CreditAttribution: iantresman commented
PHP 5.4.0 or PHP 5.4.21?
Comment #148amateescu CreditAttribution: amateescu commented
Since security was one of the reasons here, we should target at least 5.4.2.
Comment #149klonos CreditAttribution: klonos commented
@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 #150cosmicdreams CreditAttribution: cosmicdreams commented
Comment #151effulgentsia CreditAttribution: effulgentsia commented
And a followup for the D6 problems pointed out by chx.
Comment #155twistor CreditAttribution: twistor commented
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.
Comment #156cosmicdreams CreditAttribution: cosmicdreams commented
|Needs work
|» Reviewed & tested by the community
Decision made, follow ups created. Anything else to do here?
Time to close this issue.
Comment #157Xano CreditAttribution: Xano commented
|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.
Comment #158chx 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 #159cosmicdreams CreditAttribution: cosmicdreams commented
|Needs work
|» Needs review
rerolled 138
Comment #161catch CreditAttribution: catch commented
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.
Comment #162klonos CreditAttribution: klonos commented
...exactly what catch said above. I'm not saying we should revert the decision, but do let people express their opinions freely.
Comment #163alesr CreditAttribution: alesr commented
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.
Comment #164alexpott CreditAttribution: alexpott commented
Comment #165EclipseGc CreditAttribution: EclipseGc commented
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.
Comment #166chx CreditAttribution: chx commented
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.
Comment #167Alan D. CreditAttribution: Alan D. commented
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.".
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.
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 #168iantresman CreditAttribution: iantresman commented
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.
Comment #169cosmicdreams 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 #170klonos CreditAttribution: klonos commented
...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 #171klonos CreditAttribution: klonos commented
...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 #172webchick CreditAttribution: webchick commented
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.
Comment #173greggles CreditAttribution: greggles commented
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.
Comment #174amateescu CreditAttribution: amateescu commented
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.
Comment #175EclipseGc CreditAttribution: EclipseGc commented
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.
Comment #176klonos CreditAttribution: klonos commented
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 files to be assigned to branch(es)/version(s) and thus tested against it
Comment #177jthorson CreditAttribution: jthorson commented
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.
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 #178EclipseGc CreditAttribution: EclipseGc commented
That was not intended to be condescending or anything. I realize you test bot guys work your asses off. ;-)
Comment #179hass CreditAttribution: hass commented
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
Comment #180greggles CreditAttribution: greggles commented
Comment #181hass CreditAttribution: hass commented
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.
Comment #182effulgentsia CreditAttribution: effulgentsia commented
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?
Comment #183pfrenssen CreditAttribution: pfrenssen commented
Comment #184AimAdvantage CreditAttribution: AimAdvantage commented
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.
Comment #185effulgentsia 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 #186anavarre CreditAttribution: anavarre commented
Comment #187anavarre CreditAttribution: anavarre commented
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)
Comment #188iantresman CreditAttribution: iantresman commented
Comment #189webchick CreditAttribution: webchick commented
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?
Comment #190Xano CreditAttribution: Xano commented
|Require PHP 5.4
|» [policy, no patch] Require PHP 5.4
|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.
Comment #191Xano CreditAttribution: Xano commented
Comment #193YesCT CreditAttribution: YesCT at Contegix commented


text:
NEW YORK (TheStreet) -- Portfolio Recovery Associates (PRAA) was surging 15% to $58.17 on Thursdayg after the financial and businesses services company reported fourth-quarter earnings that surpassed analysts' expectations.
Portfolio Recovery reported net income of 91 cents a share, ahead of the Zacks consensus estimate of 89 cents. A year earlier, earnings were 70 cents a share. Revenue jumped almost 20% to $184.9 million, but came in just short of the Zacks consensus estimate of $186 million.
The company also received a boost from the announcement that it would acquire Aktiv Capital, an Oslo-based debt investment company, for $880 million. JMP Securities said in a research note on Thursday that the deal should be immediately accretive and that it should provide much-needed diversification. The firm reiterated its $72 target price and "outperform" rating on Portfolio Recovery after what it called "a positive and transformative acquisition by the company."
TheStreet Ratings team rates PORTFOLIO RECOVRY ASSOC INC as a "buy" with a ratings score of A. TheStreet Ratings Team has this to say about its recommendation:
"We rate PORTFOLIO RECOVRY ASSOC INC (PRAA) a BUY. This is based on the convergence of positive investment measures, which should help this stock outperform the majority of stocks that we rate. The company's strengths can be seen in multiple areas, such as its robust revenue growth, largely solid financial position with reasonable debt levels by most measures, impressive record of earnings per share growth, compelling growth in net income and expanding profit margins. Although the company may harbor some minor weaknesses, we feel they are unlikely to have a significant impact on results."

subset: commoncrawl


text:
Decision makers
- Donald Forgione, DirectorFlorida Park Service
- Mickey Thomason, ManagerCross Florida Greenway
- Sally Lieb, Park ManagerSilver Springs State Park
State of Florida: Let the Silver River monkeys live!
For over 70 years, rhesus monkeys have lived along the banks of the Silver River and Oklawaha River in North Central Florida. The monkeys were introduced into the area by a tour boat operator in the 1930s. Spotting the monkeys can be a highlight of canoe trips in the Silver Springs State Park. The monkeys have lived a peaceful existence in the wild, but the State of Florida considers them to be "nonnative" and allows trapping of monkeys.
Between 1998-2012, approx. 800 monkeys were trapped and removed from the area and sold to research and testing laboratories.
Photo of monkeys at Silver Springs State Park, by Ann E. Hamilton
- Florida Park Service
Donald Forgione, Director
- Cross Florida Greenway
Mickey Thomason, Manager
- Silver Springs State Park
Sally Lieb, Park Manager
I just signed the following petition addressed to: Florida Park Service.
Let the Silver River monkeys live!
It is a tragedy that wild monkeys living along the Silver River and Oklawaha River are torn from their families and forest homes and sold to research and testing laboratories.
Once wild and free, these sensitive and intelligent animals will end their lives in the isolation of a laboratory. Please end the trapping of monkeys for the research industry at Silver Springs State Park, on Cross Florida Greenway properties and other state lands.
There are methods of population control that are humane and effective, such as the trapping, sterilization and return of monkeys. In addition, rules against feeding or harassing monkeys along the rivers should be strictly enforced.
The monkeys are appreciated by both locals and tourists. Please, don't allow the trapping program to tarnish the image of Florida's state parks.
Animal Rights Foundation of Florida started this petition with a single signature, and won with 1,867 supporters. Start a petition to change something you care about.
Report abuse
Please report any content that may violate Change.org's Terms of Service or Community Guidelines.
Thank you for taking the time to report content. Our team will review your claim and contact you if we need more information.
Trending petitions
This petition can't win without you
Add your name to help "State of Florida: Let the Silver River monkeys live!" win today. Every signature matters.


text:
Cinesthetics Photographer
Rikki StraubModel Female San Diego, California, US
Mayhem # 2147184
About MeI live in San Diego and I love every second of it. I smile everyday just being here. I love all the opportunities modeling could bring, travel, exposure, and new people. I also really love photography and appreciate the artistic eye it takes to capture a good shot.
Have you worked with Rikki Straub? Add Credits for Rikki Straub! >>
Credit NotesJoe Jovel, Ben Duarte
Cinesthetics Photographer
gumisforlo... Photographer
Christina Frankel Photographer
Mario Covic Photographer
Eric Serra Photographer
JC Cannegieter Photographer
Loading Content


text:
The iPhone was as much of a revolution to carrier networks as it was to consumers -- it was the first phone that gave users a reason to wirelessly gobble data, and that was before "there's an app for that" became a colloquialism. According to an upcoming study, though, Verizon smartphones now take the data consumption crown.
Validas, a wireless bill service provider for consumers, businesses, and government agencies, recently finished an analysis of more than 20,000 consumer wireless bills collected between January and May 2010. According to its study, due to be published September 1, Verizon Wireless smartphones consumed an average of 421MB per month versus the iPhone's 338MB per month. Validas compares general "smartphones" from Verizon Wireless to just AT&T's iPhone, though the majority of Verizon Wireless's data consumption is probably coming from the growth of Android devices.
[ iPhone, BlackBerry, or Android? Whatever handheld you use or manage, turn to InfoWorld for the latest developments. Subscribe to InfoWorld's Mobilize newsletter today. ]
Validas revealed a number of other interesting statistics in a press release. For example, there are slightly more Verizon Wireless smartphone owners who use less than 200MB per month (a bar that AT&T set when it switched to tiered data pricing in June) than iPhone owners -- 54 percent versus 52 percent, respectively. Interestingly, a handful of both Verizon Wireless smartphone users and AT&T iPhone users consume "no data" over their networks in a given month -- 3.4 percent and 2.9 percent, respectively. Perhaps these users are lucky enough to live around truly ubiquitous Wi-Fi.
While iPhone users edged out Verizon Wireless smartphone users for consuming more than 200MB each month (48 and 46 percent, respectively), Verizon Wireless smartphone users hit the network the hardest when it comes to "power user" territory. Nearly twice as many Verizon Wireless smartphone users (or 11 percent) consume 500MB to 1GB each month, and more than twice as many (four percent) use more than 2GB per month.
Validas shares even more interesting tidbits from its study in a blog post, especially in terms of sheer year-over-year growth in wireless data usage between 2009 and 2010 across all the major U.S. networks. Verizon lead the pack in terms of growth with a mean increase of 48.2MB to 147.2MB used per customer per month, as 42.9 percent of its customers opted into new data plans versus 33.4 percent a year ago. T-Mobile followed with a data usage increase from 44.6MB to 120.6MB, though it had virtually no growth in the number of new data plans. Sprint was in third place with an actual decrease in mean data usage of 166.5MB to 133.4MB, even though new customers opting into data plans increased from 36.9 percent to 49.9 percent.
AT&T came out on top with the greatest number of customers with data plans at 71.2 percent, which was up from 58.4 percent a year ago. Mean data usage per user is also up from 111.9MB to 149.6MB.
Validas did not present any explanation for the significant growth in wireless data usage from Verizon Wireless or other network smartphone users. One possible reason: the fact that Android allowed users to run data-intensive third-party apps in the background -- such as Pandora or turn-by-turn directions -- while iOS did not during the time of Validas's study. The restrictions that Apple had to impose on some types of features due to AT&T's struggling network may be another cause. Apple also pitches the iPhone to a broad audience that may contain a higher ratio of members who simply do not want to consume as much data while on the go. Android, by comparison, got to the market more quickly for power users who have been waiting to live on streaming music, portable 3G hotspots, and a mobile OS that can be more easily tinkered with.
However, because the iPhone only recently began allowing third-party apps to run in the background with Apple's release of iOS 4, it will be interesting to see Validas's study performed again in another six to 12 months.


text:
Shareholders in Centro's two listed entities face divergent futures as the giant property landlord attempts a $13 billion sale or recapitalisation.
News of the restructure has bolstered
Overall, Centro is a complex web of inter-linked equity funds and debt, controlling a portfolio of shopping centres in Australia and the US.
The decision to put $13 billion of its assets on the block came after pressure from its lenders and after interest in the Australian assets from investors such as a Lend Lease-led consortium. It is possible the outcome could also be a recapitalisation or, if no agreements can be reached, an administration.
Commonwealth Bank this past week sold most of its debt in Centro Properties Group at just over 50¢ in the dollar.
JPMorgan analyst Rob Stanton and his team said the sale process would be the catalyst for closing the gap between share price and net asset backing (NTA) at Centro Retail. Already the 50 per cent gap between unit price and NTA has closed considerably as the market anticipates a sale of assets at close to NTA. Centro Retail must refinance more than $900 million by December next year but it has around $800 million of positive equity in the company.
JPMorgan forecasts that NTA will rise from the 33¢ posted in the mid-year results to 40¢ by year-end.
Centro Retail chief executive
The stock closed at 24¢ on Friday, rising from 16¢ one month ago, and has booked a 45 per cent return in the year to date.
The JPMorgan analysts have upgraded their forecast to "overweight", setting a price target of 38¢ by December next year.
Orbis Australia is the trust's third-largest holder with 13.23 per cent of the register. Orbis fund manager Simon Marais bought in at an average price of 12¢ and is comfortable with a sell-down. "If it's broken up and I get my 40¢, I'll wave them goodbye and I'm happy," he said. "What I want them to do is not to firesale it."
It is a very different story with the parent stock Centro Properties Group, which has a negative 43 per cent return in the year to date. Rebecca Li, of the CNP Shareholders Association, said she accepted investors in the parent would take a loss but they wanted to protect what value they had, including Centro's management platform.
The CNP Shareholders Association accepts they will take a loss.
The Australian Financial Review


text:
Chuao Chocolatier Treat Assortment
Chuao's chocolate bonbons are wickedly delicious! From simply good fillings like gianduja (a hazelnut paste) to exciting combos like modena (strawberry caramel and balsamic vinegar), they're an indulgence worth splurging on.
A sweet way to add a little sweetness to your tea or hot chocolate. Would make an adorable house gift!Tags: kitchen, chocolate, truffles, spoons, fred flare, housewares, kitsch, measuring, bon bonsAdded 9 Years Ago from Fredflare


text:
The Extender includes a Sender and a Receiver. It can extend Power-Switch & Keyboard & Mouse and VGA port signal of the computer max up to 200 meters through a single Cat5E cable. Also provides Switch & Keyboard & Mouse and VGA port on Sender for local use, convenient to maintenance and workstation management, also well for data security, helpful to reduce the noise and heat. It can widely used in the Computer-System, Monitor-System, Data-Service-Center, Industrial-Control, Enterprise-Computer-Management, Education, Banking, Securities-System, Family etc.. The Extender (include the Sender and Receiver) with Anti-Lightning for enhances the reliability and stability. The Receiver with clarity and brightness adjustment function, could to adjust the Brightness and Clearness manually, make remote display without blurring and smearing.
Share your reviews, photos and videos here!
Fed 26,2015 11:02:04
Very fast delivery 2 weeks! Thank you! The prouct works well.
Is this feedback helpful for you?Yes ( 0 )No ( 2 )