Require PHP 5.3

-1

IMHO requiring PHP 5.3 would be a rush
too many hosting won't get there that soon
PHP 5.3 seems pretty unstable, even introducing new features like namespaces having huge changes/improvement between 5.3 minor versions

Relates to #360605: PHP 5.3 Compatibility and #867772: Use PHP 5.3 namespaces . Among other reasons for requiring it, PHP 5.3 is now the only officially supported PHP version. Security updates are only done for PHP 5.3.

I imagine that D8 will require PHP 5.3. Can we document it and close that issue?

I've already seen several web hosts switch to 5.3 as default, or offer it as an option. +1 for D8.

In my searches I did not find this issue. Updating the title to make it easier to find and use. There was some conversation on #1167160: Bump Drupal 8 Minimum PHP version to 5.3 as well.

To restate what I said there....

PHP 5.3 has been our for some time and has a number of new features that would be useful for core and contrib. PHP 5.3 adoption is on an upswing with hosts making it the default. If Drupal 8 is going to be a couple years out we could start developing in PHP 5.3 now so we are on top of technology when D8 is released.

@tmuras Drupal has a check for the minimum php version. So, there is a tiny amount of code to change on this issue.

Whoever submits the first Drupal patch with a goto in it gets a cookie.

Good ol' comment module not protecting from issue status changes.

I am 100% in support of this move. Remember, we're looking at what the market will look like at the end of 2012 or thereabouts. By then, 5.3 should be readily available on anything capable of running Drupal in the first place.

Argh!

I have a very cheap host (one.com) and even they switched to php 5.3 a few months ago. (Thnx to this issue I started reading more about php 5.3, and now I'm convinced we should do this :p )

Remember: goto should only be used as a break to a labelled destination. ;-)

2012 is the end of the world, we have to try it and release D8, LOL

+1 for PHP 5.3 only and D8
@mfer I can look at the patch

+1

We already have to support 5.3, without being able to take advantages of its new features. Let's make this a D8 requirement.

Do we want 5.3.0, or one of the later releases with bug fixes?

I'd say the oldest 5.3 that's used by current stable versions of: Debian, Ubuntu, Red Hat, Suse. (Those cover the vast majority of the market.)

I was also thinking about requiring as high as possible version of PHP 5.3.x but I think that requiring 5.3.0 is good enough. Debian for instance has 5.3.3 but this includes security patches from 5.3.4 and 5.3.5.
We should be requiring higher version only if there are some features that we would like to use. Are there?

There should be no new features in 5.3.x after 5.3.0. What there are is fewer bugs. Fewer bugs == fewer workarounds for us.

Perhaps we should commit 5.3.0 for now, and then be comfortable with bumping that requirement later if we find a bug that's fixed in 5.3.2 or some such that we don't want to have to deal with.

I agreed with @Crell in #20.

We should require 5.3.0 so we can take advantage of new features. We can require a later 5.3 release if its absolutely necessary to fix a bug, but this should be avoided if possible to maintain maximum compatibility.

A little research from DistroWatch:

Current releases:
RHEL 6.1 (stable): PHP 5.3.3
Debian 6.0 Squeeze (stable): PHP 5.3.3
Ubuntu 11.04 (stable): PHP 5.3.5
openSUSE 11.4 (stable): 5.3.5
Mandriva 2010.2 (stable): 5.3.4
CentOS 5.6 (stable): 5.1.6
Fedora 15 (stable): 5.3.6

Old releases:
RHEL 5.6 (oldstable): PHP 5.1.6
Debian 5.0 Lenny (oldstable): PHP 5.2.6
Ubuntu 10.10 (oldstable): PHP 5.3.3
openSUSE 11.3 (oldstable): 5.3.2
Mandriva 2010.1 (oldstable): 5.3.2
Fedora 14 (oldstable): 5.3.3

Since we don't support 5.1 anyway anymore, it looks like PHP 5.3.3 would cover every current distribution. 5.3.2 would cover every current distribution and one version back (except on Debian, where Lenny is very very old anyway and using 5.2).

I'm happy with either 5.3.2 or 5.3.3 as a target.

+1 for 5.3.2 so.

Anyone else want to update that patch to 5.3.2? Easy one to do.

I think I can handle that :-)

Test bot approved!

This is a good one to have. Committed to 8.x.

Patch still needs work (try running "grep -R 5\\.2 ." on a D8 checkout).

Biggest problem is probably install.php which still tells you "Drupal requires at least PHP 5.2.4", but there are others.

I'm on it

I put one todo in the code. (can someone give advice or reroll :) )
And this needs a review.
I'm wondering if this broke something...

forgot patch

Lets try again

+++ b/install.php
@@ -16,8 +16,8 @@
+if (version_compare(PHP_VERSION, '5.3.2') < 0) {
+  print 'Your PHP installation is too old. Drupal requires at least PHP 5.3.2. See the <a href="http://drupal.org/requirements">system requirements</a> page for more information.';
   exit;
 }

Shouldn't we use DRUPAL_MINIMUM_PHP here?

Something like:

+if (version_compare(PHP_VERSION, DRUPAL_MINIMUM_PHP) < 0) {
+  print 'Your PHP installation is too old. Drupal requires at least PHP ' . DRUPAL_MINIMUM_PHP . '. See the <a href="http://drupal.org/requirements">system requirements</a> page for more information.';
   exit;
 }

Powered by Dreditor.

DRUPAL_MINIMUM_PHP isn't available that early.

To make it available we'd need to include bootstrap.inc, which (last time someone checked, at least) causes a parse error in PHP 4... see #722974-10: Install script returns a blank page for PHP4, PHP 5.1 (should display *something* instead)

Might be worth adding this fact to the code comment in install.php. (Or we could just decide to let PHP 4 users whitescreen by the time Drupal 8 comes around, but I'm not sure that's a good idea, and anyway, it's a different issue.)

Updated patch.

Performed the TODO in authorize_get_filetransfer()
Tidied up drupal_error_levels()
Added a comment to install.php per #38

Bug report??

Patch looks good on a visual review (I haven't tested it though). One minor typo:

+// The minimum version is specified explicity, as DRUPAL_MINIMUM_PHP is not yet

Should be "explicitly".

I only tested one or two parts of this directly, but the testbot says the whole thing is good and the patch itself looks very straightforward, so I'm marking it RTBC.

While PHP 5.3 is requirement there's a great ability to cleanup D8 codebase to make it compatible with True FastCGI support introduced.
Is there any issue / post at g.d.o about making Drupal compatible with FastCGI?

This ability could be illustrated with

Framework::init();
while($request = FastCGI::accept()) {
  // Process request
}
Framework::shutdown();

Committed #44 to Drupal 8. Thanks for the rigor, David.

Unfortunately this is the error message:

Your PHP installation is too old. Drupal requires at least PHP 5.3.2. See the system requirements page for more information.

However, http://drupal.org/requirements says:

PHP:
Drupal 5 and 6: 4.4.0 or higher (5.2 recommended)
Drupal 7: PHP 5.2.5 or higher (5.3 recommended)

I updated http://drupal.org/requirements just in that one place. This is a pretty major change, and caught me by surprise. Are there other places that we should be fixing docs? Wouldn't this be called something like a major API change in midstream?

Sorry, I'm just lost. I fooled myself checking out 8.x

A note that the requirements were raised to PHP 5.3.3 as of #1321540: Convert DBTNG to namespaces; separate Drupal bits.

By now it seems that PHP 5.3.4 is required because of Drupal\field\FieldInstance

It implements ArrayAccess. The reason it needs PHP 5.3.4 is that FieldInstance has the offsetGet method implemented as returning by reference.

From the php website:

Note:

Starting with PHP 5.3.4, the prototype checks were relaxed and it's possible for implementations of this method to return by reference. This makes indirect modifications to the overloaded array dimensions of ArrayAccess objects possible.

A direct modification is one that replaces completely the value of the array dimension, as in $obj[6] = 7. An indirect modification, on the other hand, only changes part of the dimension, or attempts to assign the dimension by reference to another variable, as in $obj[6][7] = 7 or $var =& $obj[6]. Increments with ++ and decrements with -- are also implemented in a way that requires indirect modification.

While direct modification triggers a call to ArrayAccess::offsetSet(), indirect modification triggers a call to ArrayAccess::offsetGet(). In that case, the implementation of ArrayAccess::offsetGet() must be able to return by reference, otherwise an E_NOTICE message is raised.

This means the requirement should be updated (and I need to get my php version up to date)

Ah what a chance xD, thanks for the link ;-)

Probably we could make it upper if sorting bug will be fixed https://bugs.php.net/bug.php?id=50688
This required for sorting configuration entities