Drupal 8 does not work with PHP 5.3.2 (the version shipped with Ubuntu 10.04 LTS)

Looks good to me.

I'm not at all opposed to increasing to 5.3.2+ if there is any good reason, but this just sounds like sloppy coding that could be fixed by changing the class or method name.

Hm, not sure I would say it's sloppy. Is there some intrinsic reason a Condition class shouldn't have a condition method?

Ubuntu 10.04 (Lucid) is supported until April 2015 and I believe it has PHP 5.3.2...

Given that we bent over backwards to make sure Drupal 7 ran on the previous Ubuntu LTS release (Hardy), I think we should do the equivalent with Drupal 8 and Lucid, if at all possible.

Bending over backward to support very old releases is what kept us crippled by PHP 4 for so long.

Drupal 7 gave the finger to RHEL 5 which still shipped with PHP 5.1, because everyone who knew anything used backports on that anyway. We're already saying to hell with IE 6 and IE 7, which are officially supported by Microsoft for longer than 2015, I believe.

Anyone who's still running Ubuntu 10.04 in mid-2013 isn't going to be updating to Drupal 8 anyway, at least not until Drupal 9 is out, because they don't run current-version software anyway. :-)

Remember, a new Ubuntu LTS release (12.04) is due out in less than 2 months, and will be a year and a half old by the time Drupal 8 ships; and that's if we're optimistic about Drupal 8's ship date.

The only sloppy thing here would be caring about PHP 4-style constructors in the first place. It's 2012.

There is no blocker here.

I think supporting the most recent LTS release of Ubuntu when Drupal 8 is released is plenty, especially if it will already be 18 months old by then.

This change looks fine to me, too.

I'll add to @Crell's list that the PHP 5.4.0 stable is also around the corner.

PHP 5.4.0 has already been released. http://www.php.net/archive/2012.php#id2012-03-01-1

Many, many, many people are in a situation where they can choose the version of Drupal they run, but not the operating system of the underlying server.

I really don't like the idea of kicking out an unknown number of those people based on a short thread in the core issue queue that has no usage data to back it up.

When we stopped supporting PHP 4 and PHP 5.1, there were very strong technical reasons for doing so. And even then, I know (anecdotally) of sites that cannot upgrade to Drupal 7 because of those decisions.

In this case, it sounds like this is a minor problem with an easy workaround. Why can't we simply rename the class?

By the way, if I'm not mistaken, isn't one possible outcome of #1460476: Figure out sub-namespaces for DBTNG, establishing precedent for other subsytems. that this issue will fix itself automatically?

Maybe we should wait until some decisions are made there before going further here?

Ubuntu 10.04 LTS will be supported until Q2 of 2015. I don't think you can draw conclusions about the use of Drupal 8 based on OS upgrade schedules.

Drupal is very insistent on installing its own security updates. The warnings you get when logged in as an admin are very very visible. And I think that's good.

But then we should also take into account the PHP security updates. And as there are important security fixes in 5.3.n (for multiple n with n > 2), I think this should be a non-issue. I advise clients to change hosting provider if they are not up to date with security patches. I recently had one on 5.2.8, completely unwilling to update tot 5.3.n or even the most recent 5.2.n security update. Those hosters should be avoided.

#1460476: Figure out sub-namespaces for DBTNG, establishing precedent for other subsytems. won't resolve this issue, because the question is that the class short-name and method have the same name. The namespace it lives in is irrelevant.

Even on an LTS release, people can, and often do, install backports, especially for things like PHP. That's how RHEL 5 users use Drupal 7, or really anything in the PHP world since 5.1 is long-since dead. That's not an onerous expectation to put on someone running a already-deprecated LTS.

Crosspost.

Just to juice things up, I just ran this from the php bug on my LTS test server:

testserver:~$ php --version
PHP 5.3.2-1ubuntu4.14 with Suhosin-Patch (cli) (built: Feb 11 2012 06:50:46)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
testserver:~$ cat tmp.php
<?php
namespace NS1 {
class Test {
    function Test($t){
        die('called');
    }
}
}
namespace {
    new \NS1\Test($t);
    die(':(');
}

testserver:~$ php tmp.php && echo ""
called
testserver:~$

false versions--

Technically a crosspost but since the LTS /does/ have this fix but reports as 5.3.2 we're up a creek on sniffing support from the version. Don't know what to say but leaving NR.

oooooh! Thanks, you're right, its doing the wrong thing despite the bug claiming its the right thing. Bad bug... back to RTBC

I strongly disagree that this is RTBC, but I don't want to keep switching the status either.

Note that fietserwin's comment in #12 is incorrect, since Ubuntu LTS releases (and pretty much every distro that I've heard of) backport security patches. That's why the version gets reported as "PHP 5.3.2-1ubuntu4.14" rather than "PHP 5.3.2" (as in #15). You are not running an insecure version of PHP if you stick with one of these distros.

#1460476: Figure out sub-namespaces for DBTNG, establishing precedent for other subsytems. won't resolve this issue, because the question is that the class short-name and method have the same name. The namespace it lives in is irrelevant.

My understanding is that one possible outcome of that issue is that the class name would be something like QueryCondition, whereas the method name would presumably remain as condition(). Wouldn't that resolve it?

I'm comfortable with bumping the version requirement. Committed to 8.x.

Given #17 this was committed in a haste and I am reopening the issue. There's no need to rush. We made Drupal 7 run on 5.2.4 for Ubuntu and I doubt we suddenly lack the engineering talent to feature sniff instead of version check.

Sorry. I misunderstood #18 and #16. Still... not sure whether it's right to exclude previous-LTS Ubuntu because of such a minor issue...

Note that it's also no longer possible to display a "nice" requirements message on PHP 5.2, because the use statement and namespace at the top of files causes a syntax error. However, per tim.plunkett, users for 5.3.0 through 5.3.2 still get the "nice" message that requirements are not met on install.php and update.php (though a fatal on index.php).

FYI: Symfony still supports 5.3.2.

This issue definitely deserves the "revisit before release" tag.

As mentioned above, we might actually have reason to revisit it much sooner than that.

I've opened #1468340: index.php has syntax error instead of graceful fail for < 5.3 for the use statements syntax error.

http://www.mamp.info/en/mamp/index.html ships with 5.3.2

Hmm, my version of MAMP has 5.3.9. Maybe that page is out of date? More concerned about the LTS which is supposed to be supported into 2015.
https://wiki.ubuntu.com/LTS

Yes, I signed in today for Office Hours and started to work on http://drupal.org/node/1239930. My new install of D8 was rejected because my server runs Ubuntu 10.04 LTS...

I'll have to think of a work-around so I can continue to participate in Office Hours. This probably means setting up another server...

Well it appears that ubuntu 10.04 repositories will probably not be udated with php > 5.2, so

1) I tried the ppa respository at nginx using sudo add-get-repository ppa:nginx/php5.3 and that failed when I ran apt-get update.

2) Then I came across comment #4 from https://answers.launchpad.net/nginx/+question/189867 where Brian Mercer says

Ondřej Surý is a maintainer of the Debian php5 package and has a ppa at: https://launchpad.net/~ondrej/+archive/php5

However he has 5.4 up there now which may introduce new problems with existing code.

3) So I went to https://launchpad.net/~ondrej/+archive/php5 and did sudo sudo add-apt-repository ppa:ondrej/php5. After running sudo apt-get update, rebooting and then sudo apt-get dist-update I got PHP 5.4 installed. I was notified that there were differences in my old php.ini and the new one etc which I duly attended to.

This option is pretty bleeding edge but seems to work so far...

Correction: Drupal 7.12 appears to have issues at the moment running on PHP 5.4.

So rewinding back to PHP 5.3.2 and not trying to run Drupal 8 until I install > PHP 5.3.2.

Ubuntu is a really well-supported distro, both by its official channels as well as by the amazing community around it. We need not to worry about such things. I'm sure that even if there is no apt-get way to get php 5.4 installed, there'll always be a way and instructions to install from source. All that available simply by googling around for a minute or two. I'm confident that it will be pretty trivial for admins/gurus working in major organizations or hosting providers to get this task done and that it won't be an issue for people that use DIY servers (those don't even stick with the LTS versions and update quite often).

I cannot imagine moving to HTML5/CSS3 and other new technologies in a world where we'd need to be constantly "babysitting" people still using WinXP+IE6, php4 and whatever other deprecated technology might still linger out there. If they wish to not be "pushed" into upgrades, then perhaps they should stick with those technologies and use D7. Going through the whole trouble of migrating one's site to D8 but stubbornly refusing to upgrade the underlying OS and whatever piece of software that comes with it seems kinda ironic to me. We all need to accept the fact that sometimes you simply cannot feed one's self and/or the dog and keep the pie too.

...Point is that the right decision was made here.-

IE6 was released in 2001. 5.3.2 is not two years old. You are comparing oranges to buffalos, anyways.

And no, I disagree with the decision.

PHP is moving to a more predictable, time-limited release schedule anyway: https://wiki.php.net/rfc/releaseprocess

So by the time Drupal 8 ships, PHP 5.3.* will already be on life support.

You are comparing oranges to buffalos...

...sure, it's oranges & buffaloes, but I wasn't actually comparing the two (how can one possibly compare a browser to a scripting language). I was merely mentioning some examples of cases where adoption of newer/better/faster/safer technologies was slowed down either because their respective successors were "unstable", "not thoroughly tested" and so forth or because the old versions still held the major part of the market (isn't this expected when a new version is released). In other words progress was hindered because part of the market (I won't argue over how great a part or not) refused to let go of things simply because they were used to them. IMHO if one wants to have the latest, shiniest version, then they'll have to upgrade.

Ubuntu is free, php is free, drupal is free and so are their respective future version upgrades. It's not as if cost is a factor here either.

From the mentioned document:

x.y.z to x.y.z+1
- Bugfixes only (with a room for exceptions on a case by case basis and only for small self contained features additions).
- Extensions support can't be removed (like move them to pecl)
- Backward compatibility must be kept (internals and userland)
- ABI/API compatibility must be kept (internals)

So there is no reason to not update. Moreover, it is 2012 and I take automatic updates of, e.g., browsers and OS'es for granted. So my 1st reaction would be go complain with Ubuntu about them not updating.

My MAMP is PHP 5.3.6, xjm's is 5.3.9, so in any case they don't have problems with this change. Removing it from the title.

Yeah, Ubuntu's policy on upgrades is at https://wiki.ubuntu.com/StableReleaseUpdates#When. Based on that it seems really unlikely that they would take a fix like this into 10.04.

Going through the whole trouble of migrating one's site to D8 but stubbornly refusing to upgrade the underlying OS and whatever piece of software that comes with it seems kinda ironic to me.

Again, I think comments like this misstate the reality for a significant number of Drupal sites.

Consider a university, for example. If you're running a Drupal site there, there's a good chance you're doing it on an infrastructure run by people one level "up" the chain (for example, an academic department website running on a university-wide IT system, or a website for a small group within an academic department run on the department's IT system). You don't get to make the decisions about the operating system, and the people who do are managing a platform that's used by many other people besides you, running all sorts of fragile software. In these situations, they don't tend to update unless they absolutely have to.

So if we don't eventually change this, then (depending on Drupal 8's actual release date and a number of other factors) the likely result is that people in those situations will have to delay using Drupal 8 until quite a while after it's released.

#39: You're right, but it made me thinking that it must have been considered a major bug that could only be solved by breaking BC.

Diving a bit deeper into it: the condition class seems to have a __construct() constructor (I'm looking at the patch in #1321540-69: Convert DBTNG to namespaces; separate Drupal bits), but the condition method is also still called upon construction? Is that how PHP < 5.3.3 worked? The PHP documentation states: if PHP 5 cannot find a __construct() function for a given class, it will search for the old-style constructor function, by the name of the class.. I would consider that a major bug deserving to be fixed regardless it consequences. Or am I (completely) lost about what causes the problem in 5.3.2?

...I think comments like this misstate the reality for a significant number of Drupal sites.

Here we go again with that old significant/greatest part of installations that are still on older versions of OS/software. I didn't argue that this is not a fact, but why do the rest of the people have to not improve on account of them.

Consider the people using dev versions of modules (like myself) compared to the people that stick to the stable releases. Of course the number that chooses to "play safe" is always going to be greater then the "risky people". That doesn't mean though that we shouldn't move on with implementing new features. We don't "force" people that use older stable to upgrade to the next one(s). Besides, if a feature is added (or removed) and makes that much of a drastic change, then we -usually- choose to split to a new branch (from 7.x-1.x to 7.x-2.x say). It's up to the site's admins to choose to upgrade or not and if so, also make the required preparations/changes/sacrifices. Same with those people in your example, they'd unfortunately have to stick with D7 till their IT department decides to upgrade the OS ...eventually ...after they've had enough "nagging" I suppose ;)

I've never run into an academic IT department that's running an older LTS release of a Linux distro that is not running Red Hat, not Ubuntu. I admit my experiences do not quality as a valid survey, but I have never seen it. Ever.

I really think this is a mountain/mole hill issue, especially since we're looking at a release for Drupal 8 in mid-2013, a year and a half AFTER Ubuntu 12.04 LTS releases. Do NOT look at the market today. Look at what it will be in a year.

re #44: But the Condition class also has a __construct() constructor and thus PHP should, according to its own documentation, not look for the old style constructor at all, namespaced or not??? (I know this has nothing to do anymore with the decision made here/to make again near the release date, but it's just curiosity about what the error exactly is that causes it to be not running on 5.3.2)

fietserwin:

In PHP 5.0.0-5.3.2: *sees Condition::__construct() and Condition::condition()* OMG, you have two constructors! *explodes*

In PHP 5.3.3+: *Sees Condition::__construct(), notes that it's inside a namespace, and ignores Condition::condition()* You have a constructor. Neat! Let me call that for you like a good little runtime.

Just because Dries jumped the gun within 24 hours of this submitted it does not mean it was a good idea. David Rothstein had the chance to express his disagreement but I was not fast enough to jump on it. Dumping LTS versions is not something to be committed in 24 hrs especially because we are not in a rush. I have no idea why did we rush this.

I can't resist linking #938614-13: Downgrade required PHP version to 5.2.4 as an example of a major entity running old LTS...

This is tagged "revisit before release." We are going to do that. There's no reason in leaving a critical bug open when we are at least 18 months away from release.

Nor there is a reason to stop people who are using MAMP 1 or Ubuntu LTS from developing Drupal 8. Also if we need to rename that class better sooner than later.

MAMP is not a problem, as I already outlined in #38. And renaming the class, if we choose to do that, can happen anytime between now and Feb 2013, at which point we will be able to get out of academic arguing about this and look at actual usage stats to figure out the impact.

If we're talking about one particular version of one particular operating system that's about to be replaced by a new LTS release in the next month, that will be in service for 18 months by the time D8 releases, then this issue is normal, at best.

Mac OSX Snow Leopard ships with PHP *5.2.14*, and I still manage to develop for D8. I use MAMP. There are similar environments for Linux like www.apachefriends.org/en/xampp.html. So the idea that changing the minimum system requirements "stops people using Ubuntu LTS from developing Drupal 8" is total crap, man. :) You work on bleeding-edge code, you need a bleeding-edge environment. How you get there is up to you.

This quote from Gerhard in that other thread is hilarious btw. :)

"It's not the problem of the Drupal project if some managers promise other managers heaven on earth."

While we're in code thaw, that's my belief, too. When we're in code freeze, totally different story.

Either way, let's keep Ubuntu in the title, since it helps give this issue context.

According to the above discussion, this is also a problem with MAMP (MAMP 1), which can be solved by upgrading to MAMP 2. Having never used MAMP, I have no idea what the repercussions of that upgrade are... I do assume we care about that scenario a lot less, since it's a local development environment (compared to Ubuntu which people also use on production websites).

Although we can't look at future usage statistics now, we might actually be able to extrapolate from previous versions.

Currently, Hardy (the previous LTS) is a bit under four years old, and Lucid (the current LTS) is a bit under two years old. If we assume Drupal 8 is released in mid-to-late 2013, Lucid will be around three and a half years old then, and Precise (the new LTS) will be around one and a half years old.

Therefore, Hardy's usage today is likely a decent proxy for Lucid's usage when Drupal 8 is released.

I couldn't find any great stats on this (I didn't look that hard either) but did come across these statistics. Not sure how believable they are (for most of the Ubuntu installations they detected they were not able to detect a version at all) but it does suggest Hardy's current usage is around 10% of Lucid's. These stats are also based on computers that browse the web (not servers), and I would assume servers are more likely to run older LTS releases than personal computers are, although can't really prove that.

The only reliable source would be an ubuntu official update channel stats source (suppose they collect anonymous stats like we do). I don't know if such a thing even exists(?), but even so, how do we know that the majority of servers with outdated versions are even set to auto-update at specified intervals? In other words how much would we trust these stats when it comes to making safe conclusions/assumptions out of it.

As for the stats out there only being from computers that browse the web, there are stats sources that collect stats from server headers used in web sites browsed by users. BuiltWith is one such source.

I believe we should focus and be based only on the second type of stats sources since they collect data for our main target platform.

All that said, I didn't bother searching that much either.

Trying to guess the future isn't worth arguing, that's why there's a tag. The only thing I see worth arguing is whether imposing this on people testing patches for d8(and d7 patches that need to hit d8 first) is worthy now and we can revisit either decision before release so. Webchick seems to think this isn't a big deal and she's probably in the best position to judge(second only to maybe xjm) so I'm inclined to accept her judgement here.

MAMP is MIA right now: http://www.mamp.info

I currently cannot install Drupal 8 without this patch. Even if I figure it out before leaving for Drupalcon, I'll bet there will be people that will figure this out at the sprints and as a result wont be able to participate before either updating their local environment or applying this patch. That's a shame.

For anyone dealing with this annoyance right now, you can get the latest MAMP here: http://download.cnet.com/MAMP-PRO/3000-10247_4-10967824.html

For anyone who wants to upgrade Ubuntu 10.04 LTS to PHP 5.3.10 this is how I have done it:

sudo apt-get remove --purge php*
sudo apt-get autoremove
sudo apt-add-repository ppa:brianmercer/php5
sudo apt-get update
sudo apt-get install php5 libapache2-mod-php5
sudo apt-get install php5-cli
sudo apt-get install php5-cgi
sudo apt-get install php5-mysql
sudo apt-get install php5-gd
sudo service apache2 restart
sudo pecl uninstall apc
sudo pecl install apc

It looks a bit drastic using sudo apt-get remove --purge php* but Ubuntu does proceed to list a load of files that get filtered but then ignored and I have successfully upgraded 3 times so far...

Good Luck and thanks to Brian Mercer for his php5 ppa :)

At a minimum, if we could at least get the clean error message to show up in all places, this would be a great way for new contributors to understand why D8 isn't working on their environment. Currently, if I download the latest version as of today via GIT, and I go to:
mydomain.com/drush/

I get the following error message:
Parse error: syntax error, unexpected T_STRING, expecting T_CONSTANT_ENCAPSED_STRING or '(' in /home/martindavisiii/d8.md3productions.com/drupal/core/includes/bootstrap.inc on line 3

If I go to:
mydomain.com/drush/core/install.php

I get the following error message:
Your PHP installation is too old. Drupal requires at least PHP 5.3.3. See the system requirements page for more information.

There's actually a separate issue for that linked to above - see #1468340: index.php has syntax error instead of graceful fail for < 5.3.

I think this is a won't-fix at this point, especially in light of: #1751100: Bump minimum version of php required to 5.3.5

I think so, yes.

Since #1751100: Bump minimum version of php required to 5.3.5 has the "revisit before release" tag (per @catch's request) this actually should still have it too.

Although whether or not it can actually be revisited depends on the result of revisiting that one, of course...

Removing tag... see https://drupal.org/comment/8549287#comment-8549287