[meta] Deal with PHP requirement vs. Debian PHP version numbering

I think we're now required to bump the minimum PHP Version requirement to 5.4.5. I can't get a single page to load on PHP 5.4.4.

So, let's not hem and haw about it :)

https://drupal.org/requirements

Possibly related: I'm getting zend_mm_heap corrupted with running tests from the command line:

$ php ./core/scripts/run-tests.sh --list

Available test groups & classes
-------------------------------

action
 - Drupal\action\Tests\ActionUninstallTest
 - Drupal\action\Tests\BulkFormTest
 - Drupal\action\Tests\ConfigurationTest
Action
 - Drupal\system\Tests\Action\ActionUnitTest
[...]
 - Drupal\views_ui\Tests\WizardTest
zend_mm_heap corrupted
$ php -v
PHP 5.4.4 (cli) (built: Jul  4 2012 17:28:56) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

@tim.plunkett thanks!

Confirming that the problem does not occur with a higher version of PHP.

As a user of MAMP, I upgraded to the latest version of MAMP which includes php 5.5, which solves my problem.

Mh, so this is a conflict between debian, which uses php 5.4.4 and people using MAMP, which can update without any big issues.

Seems critical to me.

Why not bump the required release of PHP?
Latest in 5.4 branch is .33
http://php.net/archive/2014.php#id2014-09-18-2

Given the difficulty a regular site owner would have diagnosing the problem, we should bump the minimum level to avoid the problem.

I was just testing a fresh install of Drupal 8 beta1 and I happened to be on php 5.4.4. I couldn't get through an install. I updated to a newer version (5.4.19) and that resolved the issue.

I agree with the others on the thread. While most people should already be further along the 5.4.x branch, it should be stated as an explicit requirement so as to avoid tickets being filed against this known issue.

Let's bump to 5.4.5 for now.

Simple enough.
Looks good.

Committed 8d97fff and pushed to 8.0.x. Thanks!

Do we want to update the other instances of 5.4.2 in core?

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

core/INSTALL.txt
22:- PHP 5.4.2 (or greater) (http://www.php.net/).

core/lib/Drupal/Component/Plugin/composer.json
8:        "php": ">=5.4.2",

core/scripts/password-hash.sh
18:if (version_compare(PHP_VERSION, "5.4.2", "<")) {
22:ERROR: This script requires at least PHP version 5.4.2. You invoked it with

Edit: install.php seems most relevant here…

Documentation needs to be updated too. Spefically these pages:

• https://www.drupal.org/requirements
• https://www.drupal.org/requirements/php

New PHP5.4 container and all tests started to fail:

https://www.drupal.org/node/2349705

Example of the run:
http://coreresults.drupal-pt.org/sites/default/files/build_D80x_mysql55_...

Hi there,

the drupal testbot team just got across this one.

bumping the minimal php version breaks drupal currently on all debian systems since they are locked on php 5.4.4
i'm currently checking with the debian package maintainers when 5.4.5 is expected.

we are already working on a workaround for this : https://www.drupal.org/node/2349705

/bastian

Created #2349969: Update all references of PHP 5.4.2 to 5.4.5 (code & docs) to followup on references and docs.

That means it is not possible anymore to install D8 on standard Debian stable (Wheezy), are you sure it is a good idea to require 5.4.5 ?
I was still able to install it yesterday on all my Debian Wheezy VMs, now I am forced to upgrade PHP everywhere ...
For me this is a blocker.

You can't install current Drupal 8 release on wheezy anyway because of the php5.4.4 incompatibility. As such your situation is not worse than before the new requirement. Only alternative would be to change the order in which traits are loaded in the installation script.

Actually I *am able* to install current 8.0.x on a fresh Debian Wheezy, by *reverting #11 patch*.

PHP version is 5.4.4 ( 5.4.4-14+deb7u14, see https://packages.debian.org/wheezy/php5 ).
So for me the situation is worse than before the new requirement.
I would suggest to revert the patch and find another solution.

Also, the issue description does not mention D8 installation, but "using a core trait in a contrib module", so I am not sure what the problem is.

I am facing problem with php5.4.4. I would be upgrading server's PHP version.

@mike3933 could you describe system configuration and steps to reproduce the bug ? Thanks.

In the meantime, I can confirm that D8 installation works as expected on Debian Wheezy using default PHP 5.4.4 (and reverting the patch in #11 of course).
Tested on a dedicated server and on a VM, using the UI or drush si.

If you can install without any problems on Wheezy, we need to find out why your php 5.4.4 doesn't pose any problems whereas mine on MAMP does. Or, for the time being, we submit a reversal patch.

a. patch in #11 is incomplete
b. and most importantly..bumping the php version above 5.4.4 that debian wheezy ships with (dunno for other distros, but we should check) for a MAMP problem? Well, definitely needs more conversation
git revert 8d97fff

@basvredeling I just found why the problem does not occur on Wheezy : the patch at https://github.com/php/php-src/commit/90e23107a2acba1fd53b7e799372eb9f24... has been backported to the Wheezy PHP 5.4.4 package, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685765

You can find it in the diff at http://security.debian.org/debian-security/pool/updates/main/p/php5/php5... as well.

So forcing upgrading PHP to 5.4.5+ on Debian production servers is not necessary.

Here is the reversal patch.

oh, nice research #29..so this is not just a mamp issue, it wasnt happening on wheezy because its patched..hmm, in that case, bumping to 5.4.5 makes sense..
it still sucks big time that D8 wont run on vanilla wheezy though :(

Discussed this with jthorson in person and he pointed out that both the (new) test bot and people in this issue had been installing OK with Debian wheezy.

I think what might be happening is Debian has backported the fix for this into their fork of PHP 5.4.4, so it works on Debian but not with 5.4.4 on anything else.

I don't think there's any reason to break Wheezy if we don't have to, so I've rolled back the patch for now. Might need to figure out if PHP 5.4.whatever-patch-wheezy would work as a requirement.

@ParisLiakos we need to research for definite but I don't think this is an issue in stock Debian wheezy either. It's just that Debian's policy keeps them on 5.4.4 even though they backport things from later releases.

@tim.plunkett indeed, so we need to find a solution that suits everybody.

@catch thanks for the rollback.

I see that MAMP provides 5.4.4 and PHP 5.4.25, and nothing in-between.
Would DRUPAL_MINIMUM_PHP = '5.4.4-14' be a possible workaround ?
I guess that version_compare('5.4.4', '5.4.4-14', '<') would return true, no ?

@Tim yes that's why it's a critical bug. It was already broken for everyone on 5.4.4 and not on Debian with a bad error message and they'll need to upgrade. Better than forcing people to use a non default PHP build on Debian for no valid reason

Would DRUPAL_MINIMUM_PHP = '5.4.4-14' be a possible workaround ?
I guess that version_compare('5.4.4', '5.4.4-14', '<') would return true, no ?

Very good idea! it works indeed..maybe then a patch like that? (needs some testing with a couple scenarios i guess)

Actually if (version_compare($phpversion, DRUPAL_MINIMUM_PHP) < 0) in core/modules/system/system.install line 75 will fail in case DRUPAL_MINIMUM_PHP = '5.4.4-14' and php version is 5.4.4-14, since the comparison returns 0.

Thus I would suggest to update it to if (version_compare($phpversion, DRUPAL_MINIMUM_PHP) <= 0).

Also I am not sure what phpversion() returns on MAMP with PHP 5.4.4; would be great to get the exact output.

FYI RHEL and CentOS are still on 5.3.3 (http://mirror.centos.org/centos/6/os/x86_64/Packages/), while packages exists for 5.4.1 and 5.4.6 ( http://fr2.rpmfind.net/linux/rpm2html/search.php?query=PHP&submit=Search+... ), and not 5.4.4, so the 5.4.4-14 minimum will probably work in this case.

I agree with Tim Plunkett that the issue for everyone else is pretty grave. A non-patched php5.4.4 just fails installation without any notice why. Documentation from #2349969: Update all references of PHP 5.4.2 to 5.4.5 (code & docs) will only help a bit to prevent this fatal error. Being outdated is something Drupal installer should warn about.

Yes, wheezy is more important than a local dev environment. But php 5.4.4 is just incompatible. So this wont just affect me or other people on the previous major mamp release (2.x). I didn't mean to make this a MAMP discussion in any way. I tried virtualising Ubuntu with php 5.4.4 but lacked the time to verify it. Then stumbled upon this issue. Considered it verified.
To give you an idea. I've spent about 3 hours bumping my head into this issue. I've successfully installed an earlier alpha of D8 on exactly the same environment. There was no hint whatsoever that this could be caused by being on a version of PHP which suddenly became outdated between D8 alpha releases. Adding the 5.4.4 requirement as in #11 is valid as far as I see it. It should stay in while we are working on a better patch. There should really be a workaround for 5.4.4-14 systems. Or perhaps an option to ignore the php minimum version in the installer. The consequence for 5.4.4-14 users is the inability to install Drupal 8. The consequence for everyone else on <5.4.5 is a fatal error.

hmm, actually in a debian wheezy installation i just tested PHP_VERSION is "5.4.4-14+deb7u14"
and version_compare('5.4.4-14+deb7u14', '5.4.4-14', '<') returns TRUE -.-

If i switch to '5.4.4-13' it works as should though..so maybe we should switch to '5.4.4-13', i think its safe enough

Or perhaps an option to ignore the php minimum version in the installer.

It's a hard requirement to prevent people from finding unexpected fatal errors hours or months after installing Drupal. Not every PHP version incompatibility results in a fatal error on install, we're very lucky that this one does.

The consequence for 5.4.4-14 users is the inability to install Drupal 8.

Which they could previously do fine, then their choice is to hack core or change their PHP version unnecessarily.

Added a note to the release notes for now: https://www.drupal.org/node/2348025

version_compare() fix looks good.

IMHO stating that minimum version is 5.4.4-13 because version_compare('5.4.4-14+deb7u14', '5.4.4-14', '<') returns TRUE is misleading.

In install.php, I would instead suggest adding an exception for Wheezy like:

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

This test seems more explicit.

Thus initializing DRUPAL_MINIMUM_PHP to '5.4.5' in bootstrap.inc would be OK if we could add the 'Wheezy exception' in system.install and so on.

What do you think ?

Explicitly special-casing wheezy works for me. There's also the possibility that we'll need to raise version requirements to PHP 5.4.26 for whatever reason, but that Wheezy continues to work with PHP 5.4.4 because they backported that fix too, so it'd be less likely to break later on.

OK, here is a first (incomplete) patch that adds the Wheezy special-casing.

Would be nice to test it on MAMP with PHP 5.4.4 and/or tell what phpversion() returns on this system, so we know if the version comparison is correct.

I added the DRUPAL_MINIMUM_PHP_DEBIAN_WHEEZY constant, do not know if it is a good idea or not.

There's also the possibility that we'll need to raise version requirements to PHP 5.4.26 for whatever reason, but that Wheezy continues to work with PHP 5.4.4 because they backported that fix too, so it'd be less likely to break later on.

Good point!

I dont like the constant very much..it will get irrelevant pretty fast..at the very least rename it to just DRUPAL_MINIMUM_PHP_DEBIAN

#45 works for wheezy..that is, i can install and use D8 without problems
So we need to test that it fails on everything else using <5.4.5

Thanks for the feedback. Indeed, would be great to test this on <5.4.5.

I dont like the constant very much..it will get irrelevant pretty fast..at the very least rename it to just DRUPAL_MINIMUM_PHP_DEBIAN

The point is this constant only exists for Wheezy, so for me it *should* explicitely mention Wheezy.

FYI, next stable Debian will ship with PHP 5.6.0 at least (see https://packages.debian.org/jessie/php5).
Thus (IMHO), DRUPAL_MINIMUM_PHP_DEBIAN is too generic.

My question was more about adding yet another constant or not.

I don't think DRUPAL_MIMINUM_PHP_DEBIAN is too generic.

If jessie provides PHP 5.6, then the minimum PHP version on Debian is not going to change (short of another requirements change). It's just that people using Jessie will exceed the minimum anyway.

If wheezy gets completely dropped for support and we want to break it, or we raise our minimum PHP version in general, then it's still possible that the minimum on debian will be lower than other systems due to their naming convention.

On top of that, older versions of Debian than wheezy may be running more modern PHP versions (including a backport of the wheezy one), and the minimum applies to them just as much.

I disagree with #48, as we are talking about a very particular case here, but anyway, I suggest to focus on the 5.4.4/5.4.5 issue, which currently blocks some MAMP users, AFAIK.

Would be great if a MAMP user could test #45 patch against 5.4.4, or tell what phpversion() returns on this system, so we can go ahead. Thanks :)

I've tested MAMP 2.x with PHP 5.4.4
I get the PHP outdated message now before the installer is even loaded. So that's good.
Patch from #45 confirmed working.

@basvredeling Great, thanks for testing.

Here is the patch, hoping 5.4.4-13 in composer.json is safe enough.

thanks, patch looks great :)

1. +++ b/composer.json
   @@ -4,7 +4,7 @@
   +    "php": ">=5.4.4-13",
   

   i guess its fine, but maybe just ">" ?

2. +++ b/core/lib/Drupal/Component/Plugin/composer.json
   @@ -5,7 +5,7 @@
   -        "php": ">=5.4.2",
   +        "php": ">=5.4.4-13",
   

   Drupal/Component/Plugin is not affected by this bug, we should leave the requirement as is

@ParisLiakos you are right about 1), updated.
Not sure about 2) though, but we need to address the install issue first, so let's leave core/lib/Drupal/Component/Plugin/composer.json as is for now.

great, thanks!!
good to go now

Retested. Patch from #53 is also good on MAMP 2.

Don't really like the direction of creating a Debian specific check. How many exceptions for particular configurations will we need to make if we take it to the extreme?
Uneasiness aside, this seems RTBC

That also feels weird to me. I would personally just make the min. version ">5.4.4-13" and have a comment somewhere that explains that's what's in Debian Wheezy. But let's see what catch says.

See #44 why this is a good idea. "5.4.4-13" will only work now because 5.4.5 is right next to it. if we decide we need 5.4.15, we will have to actually do this anyway.

Yes #44 is why we need the debian-specific check, it's not possible to hack this with the PHP version because Debian themselves are hacking the PHP version.

There aren't many issues like this that actually block an install, so I do think we need the extra complexity here. Not in a position to commit at the moment but will do so tomorrow.

Committed/pushed to 8.0.x, thanks!

Note this follow-up #2354301: Composer require.php : invalid version constraint

Unfortunately I have to reopen this issue since the patch does not address installation of modules, which are also blocked by the 5.4.5 requirement, on Wheezy.

Thus, installation of Drupal works as expected, but installation of modules is impossible, as the message "This module requires PHP version 5.4.5 and is incompatible with PHP version 5.4.4-14+deb7u14." is displayed for each module in admin/modules, while drush en module returns "module is incompatible with the PHP version".

Finally #56 seems the best option to me (or a mix of #53 and #56), above all if version_compare(PHP_VERSION, '5.4.4-13', '<') returns TRUE on MAMP with PHP 5.4.4 (again, would be great to know what phpversion() returns on this system).

hmm yes, that turns to be more complex than that..to get modules+themes to be installable on wheezy this needs to happen

diff --git a/core/lib/Drupal/Core/Extension/ThemeHandler.php b/core/lib/Drupal/Core/Extension/ThemeHandler.php
index 694185f..59f6dac 100644
--- a/core/lib/Drupal/Core/Extension/ThemeHandler.php
+++ b/core/lib/Drupal/Core/Extension/ThemeHandler.php
@@ -460,7 +460,7 @@ public function rebuildThemeData() {
       'description' => '',
       'features' => $this->defaultFeatures,
       'screenshot' => 'screenshot.png',
-      'php' => DRUPAL_MINIMUM_PHP,
+      'php' => DRUPAL_MINIMUM_PHP_DEBIAN,
       'stylesheets' => array(),
       'libraries' => array(),
     );
diff --git a/core/modules/system/system.module b/core/modules/system/system.module
index 1c930f7..af627a6 100644
--- a/core/modules/system/system.module
+++ b/core/modules/system/system.module
@@ -790,7 +790,7 @@ function _system_rebuild_module_data() {
     'description' => '',
     'package' => 'Other',
     'version' => NULL,
-    'php' => DRUPAL_MINIMUM_PHP,
+    'php' => DRUPAL_MINIMUM_PHP_DEBIAN,
   );
 
   // Read info files for each module.

this has the drawback that if we ever need to get DRUPAL_MINIMUM_PHP 5.4.6 and above, one would be able to install modules on 5.4.5, but...wont be able to get core to install at first:) so its not an issue.

@jfhovinne
drush eval "echo phpversion();" returns 5.4.4 on MAMP 2.1.x

@basvredeling Perfect, thanks.

Here is a patch that removes the DRUPAL_MIMINUM_PHP_DEBIAN constant, and instead computes DRUPAL_MIMINUM_PHP by comparing PHP_VERSION with '5.4.4-14+deb7u14'.

Should be more solid ?

#65 works

+++ b/core/includes/bootstrap.inc
@@ -21,15 +21,12 @@
+define('DRUPAL_MINIMUM_PHP', PHP_VERSION == '5.4.4-14+deb7u14' ? '5.4.4' : '5.4.5');

The problem with this is that the moment we get 5.4.4-15+deb7u15 this breaks.

Regarding package naming, see http://metadata.ftp-master.debian.org/changelogs//main/p/php5/php5_5.4.4...

Here is something more generic.

I think this should be rolled back - on HEAD and with the patch at #68

composer self-update
composer validate
./composer.json is invalid, the following errors/warnings were found:
require.php : invalid version constraint (Could not parse version constraint >5.4.4-13: Invalid version string "5.4.4-13")

@larowlan The Composer issue is being dealt with by #2354301: Composer require.php : invalid version constraint, and rolling back to the previous value (">=5.4.2" if I am correct) will not match the 5.4.5 requirement, so I guess it is a good idea to discuss this on 2354301, to avoid cross-posting.

+++ b/core/includes/bootstrap.inc
@@ -21,15 +21,12 @@
+define('DRUPAL_MINIMUM_PHP', preg_match('/^5\.4\.4-(\d{1,2})\+deb(\d{1,2})u(\d{1,2})$/', PHP_VERSION) == 1 ? '5.4.4' : '5.4.5');

Why don't we use version_compare here instead of our own regex?

I think we should bump the composer version to 5.4.5 in #2354301: Composer require.php : invalid version constraint and wait for an upstream fix - debian composer users can just upgrade their php or wait.

I committed the patch from #2354301: Composer require.php : invalid version constraint.

Leaving this open to track the composer upstream fix (needs an issue opening against composer if there isn't one already) and other remaining issues.

Why don't we use version_compare here instead of our own regex?

To be sure this is a Debian PHP 5.4.4-something package, and not PHP 5.4.4-something on another system.

Leaving this open to track the composer upstream fix (needs an issue opening against composer if there isn't one already) and other remaining issues.

There is one, see https://github.com/composer/composer/issues/3335

Note that as long as we still have DRUPAL_MINIMUM_PHP = 5.4.5, it is impossible to enable any modules on Debian wheezy, as that is apparently added as default php requirement for every module.

Yes, would be great to review and test #68, which should fix this issue.

All of our production servers are Debian Wheezy, so this is an important issue for us. I've tested #68 both with 8.0.x and Beta-2 on a couple of these servers & a development machine also running Wheezy, and it works fine for me.

Thanks to #60 I was able to install in Wheezy but then couldn't enable any modules, they all showed as needing PHP 5.4.5.

The patch from #68 worked great, now I can enable modules too.

Looks good to me, and has also been RTBC for long enough for someone to complain. :)

Committed and pushed to 8.0.x. Thanks!

This change in requirements needs to be documented on https://www.drupal.org/requirements -- I am not sure exactly how to document so reopening this issue.

@jhodgdon see #2349969: Update all references of PHP 5.4.2 to 5.4.5 (code & docs)

#2349969 has been fixed. The requirements page itself was updated too.

Good news, the Debian PHP package maintainers have decided to follow the stable PHP 5.4.x releases for Wheezy, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757342 and http://www.debian.org/security/2014/dsa-3064

Debian Wheezy ships now with PHP 5.4.34, which means DRUPAL_MINIMUM_PHP = 5.4.5 should not be a problem anymore on this system.

I am not sure if I should create a follow-up issue, or provide a patch here, or if a revert is still possible.

This new PHP release should also solve the Composer issue.

Patch is attached and D8 installation works on Wheezy with PHP 5.4.34.

This is essentially a revert (although I'll probably commit the patch since the commit history here isn't super-clean), so it's fine to leave it on the same issue I think.

Patch itself looks fine, and this is a great (though ironic) resolution to the issue.

Thanks debian - php version sanity is restored! This issue is a critical task and is allowed per #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Committed 13aef43 and pushed to 8.0.x. Thanks!

.