Posted by catch on September 14, 2009 at 2:34am
20 followers
Issue Summary
At the very least we should try to require PHP5.2.8 for check_plain() if it's in Debian and/or Red Hat by then.
Namespacing and lambda/enclosures make it tempting to try requiring PHP5.3. Obviously we'll have to track usage.
Comments
#1
-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
#2
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?
#3
I've already seen several web hosts switch to 5.3 as default, or offer it as an option. +1 for D8.
#4
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....
#5
@tmuras Drupal has a check for the minimum php version. So, there is a tiny amount of code to change on this issue.
#6
Retitling, we need to make a decision on 5.3 or not, I can't think of any minor 5.2 versions that are relevant at the moment (check_plain() was solved with 5.2.4 in 7/8 over a year ago).
Marked #1167160: Bump Drupal 8 Minimum PHP version to 5.3 as duplicate.
I'm currently in favour of requiring 5.3 and think it's worth basing the release date on this requirement (as opposed to basing the requirement on the release date).
Regardless of any features in 5.3, there's a chance that PHP 5.4 will come out during the 8.x lifecycle. This is going to mean we may have to retrofit 5.4 support into Drupal 7, we may or may not see early 5.4 releases by the time 8.x is on its way out.
I would much rather worry about supporting two major PHP versions, especially in contrib, than three - Drupal 6 supporting PHP4 all the way through to PHP 5.3 has not been an easy path.
Bumping this to 'major' - the patch is tiny but the ramifications are large.
#7
Whoever submits the first Drupal patch with a
gotoin it gets a cookie.#8
Good ol' comment module not protecting from issue status changes.
#9
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.
#10
Argh!
#11
I didn't actually mean to change the title from mfer's, just the original one, that was also a crosspost ;)
#12
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 )
#13
Remember:
gotoshould only be used as abreakto a labelled destination. ;-)#14
2012 is the end of the world, we have to try it and release D8, LOL
#15
+1 for PHP 5.3 only and D8
@mfer I can look at the patch
#16
#17
+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.
#18
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.)
#19
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?
#20
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.
#21
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.
#22
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.
#23
+1 for 5.3.2 so.
#24
Anyone else want to update that patch to 5.3.2? Easy one to do.
#25
I think I can handle that :-)
#26
Test bot approved!
#27
This is a good one to have. Committed to 8.x.
#28
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.
#29
Now it's a bug.
#30
I'm on it
#31
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...
#32
forgot patch
#33
#34
The last submitted patch, 576508-php-5-3-upgrade-31.patch, failed testing.
#35
Lets try again
#36
+++ 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_PHPhere?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.
#37
DRUPAL_MINIMUM_PHP isn't available that early.
#38
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.)
#39
Updated patch.
Performed the TODO in authorize_get_filetransfer()
Tidied up drupal_error_levels()
Added a comment to install.php per #38
#40
Bug report??
#41
Sun, it's a bug now because the installer tells you to use 5.2 when it now actually requires 5.3.
#42
Moving back. It'd be good if we could start just rolling back patches when they're immediately found to introduce bugs then it wouldn't put the bug count higher.
#43
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 yetShould be "explicitly".
#44
#45
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.
#46
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
<?phpFramework::init();
while($request = FastCGI::accept()) {
// Process request
}
Framework::shutdown();
?>
#47
Committed #44 to Drupal 8. Thanks for the rigor, David.
#48
Automatically closed -- issue fixed for 2 weeks with no activity.
#49
Unfortunately this is the error message:
However, http://drupal.org/requirements says:
#50
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?
#51
Sorry, I'm just lost. I fooled myself checking out 8.x
#52
A note that the requirements were raised to PHP 5.3.3 as of #1321540: Convert DBTNG to namespaces; separate Drupal bits.