The newest version of Doctrine/Common (v2.8) requires PHP ~7.1.

Doctrine/Common is required by the Drupal Core:
"doctrine/common": "^2.5

By using "^" on the Version, 2.8 is downloaded when composer update is executed on the Drupal Core. Regarding the Drupal 8 PHP requirements, it has to work with PHP 5.6.x at least: https://www.drupal.org/docs/7/system-requirements/php

How to comprehend

  1. Download Drupal Core 8.3.x-Dev
  2. Run composer update
  3. Check the composer.lock file for doctrine/common, it will show you that it now requires PHP ~7.1

I am working on a patch for this.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

sgurlt created an issue. See original summary.

sgurlt’s picture

Assigned: sgurlt » Unassigned
Status: Active » Closed (duplicate)

Oh very awesome, thanks a lot for quickly hopping in, I already started to clone the drupal repo :)

sgurlt’s picture

Status: Closed (duplicate) » Needs work

Hm but where is the drupal 8.3.x patch?

sgurlt’s picture

Issue summary: View changes
sgurlt’s picture

Status: Needs work » Needs review
FileSize
466 bytes

Since I could not find a patch for this, here it is :)

cburschka’s picture

Hi, the linked issue #2887000: composer.json does not constrain Symfony components to minor and patch versions that are compatible with Drupal is actually not the same - the plan there is to constrain Symfony components to 3.2 because Drupal actually breaks (or broke, at the time) with 3.3. (Though looking at the upgrade issue #2874909: Update Symfony components to 3.3.* it now seems that the only remaining problems are deprecation notices, so I don't know if the constraint is still needed.)

What we have here is composer installing the latest version supported by the current platform - which, if you're using PHP7, can result in packages that require PHP7.

This is only a problem if your dev environment and the target/production environment have different PHP versions - but you can solve this by explicitly setting the target PHP version in your project's composer.json file:

@@ -14,7 +15,8 @@
     "prefer-stable": true,
     "config": {
         "preferred-install": "dist",
-        "autoloader-suffix": "Drupal8"
+        "autoloader-suffix": "Drupal8",
+        "platform": {"php": "5.5.9"}
     },
     "extra": {
         "_readme": [

After setting this, composer will enforce compatibility with PHP 5.5.9 regardless of whether you're using PHP7.

sgurlt’s picture

According to: https://www.drupal.org/docs/7/system-requirements/php
This then should be:

@@ -14,7 +15,8 @@
     "prefer-stable": true,
     "config": {
         "preferred-install": "dist",
-        "autoloader-suffix": "Drupal8"
+        "autoloader-suffix": "Drupal8",
+        "platform": {"php": "5.6"}
     },
     "extra": {
         "_readme": [

right?

sgurlt’s picture

New patch based on #8.

sgurlt’s picture

Reroll, wrong version ...

sgurlt’s picture

It did not work when I have patched the /core/composer.json, so I did the adjustment now for the /composer.json

dawehner’s picture

One other thing we can do is to explicitly specify

"doctrine/common": "^2.5<2.8",

sgurlt’s picture

This was my first approach, see #3 :)
But I think it is better to give this thing a general lock to make sure that we always meet the PHP requirements as described here: https://www.drupal.org/docs/7/system-requirements/php

Berdir’s picture

There is an existing issue to add the minimum php version configuration, I think this could be a duplicate of that if we decide to not do anything doctrine specific?

#2843328: Enforce minimum PHP version in composer dependencies

Status: Needs review » Needs work

The last submitted patch, 11: doctrine_common_version_below_2.8-2898119-11.patch, failed testing. View results

pounard’s picture

You'll potentially have problems not only with doctrine/common but a few other packages too:

    "require": {
        ...
        "doctrine/annotations": "^1.3 <1.4",
        "doctrine/cache": "<1.7",
        "doctrine/collections": "^1.3 <1.4",
        "doctrine/common": "^2.6 <2.7",
        "doctrine/dbal": "^2.5",
        "doctrine/doctrine-bundle": "^1.6",
        "doctrine/inflector": "<1.2",
        "doctrine/orm": "^2.5",
        ...
    },

This'll force doctrine to switch back to PHP 5.5 compatibility, it works gracefully with a Symfony fullstack 3.3 so it should work with Drupal 8 too.

This composer.json sample is extracted from a real client project I maintain, whose production is still PHP 5.5.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Mile23’s picture

Super-duper -1 on config platform fake-out: #2843328-22: Enforce minimum PHP version in composer dependencies

We know why we can't use doctrine/common 2.8, so we should specify it.

Mile23’s picture

Issue tags: +composer
Eli.Stone’s picture

I have added the following to my composer.json (inside "config")

"platform": {
     "php": "5.6"
 }

But I am still getting issues,

doctrine/instantiator 1.1.0 requires php ^7.1 -> your PHP version (7.1.5) overridden by "config.platform.php" version (5.6) does not satisfy that requirement.

Is there something else I need to be doing?

fjgarlin’s picture

Do you get that message after running composer install or composer update? You should run the latter.

cburschka’s picture

Adding those lines only prevents you from getting new packages in the future. If you had already updated to PHP7+ packages, you will need to revert your changes to composer.lock to get back to an installable state.

FMB’s picture

Not necessarily revert, just launching composer update as fjgarlin said, so that composer.lock reflects your changes in composer.json.

joelsteidl’s picture

I ran into this issue as well. The patch seemed to work as advertised when running composer on the machine with 5.6.

revagomes’s picture

Status: Needs work » Reviewed & tested by the community

I've had the same issue here and path #11 worked like a charm.

Mile23’s picture

Status: Reviewed & tested by the community » Needs work

See #12.

Mile23’s picture

So @alexrayu linked to this issue from the PHP minimum requirement documentation: https://www.drupal.org/node/2891690/discuss#comment-12296385

I'm seeing a failure in this travis-ci test set up to test composer-based bounds checks: https://travis-ci.org/paul-m/drupal_dependency_bounds_test/jobs/287060375

This fail says that Composer is able to resolve all the dependencies under PHP 5.5.9 (using composer update --prefer-lowest and also without), which means this issue isn't really a problem.

But then tests fail like this:

There was 1 error:
1) Drupal\Tests\migrate\Unit\process\FormatDateTest::testTransform with data set "timezone" (array('Y-m-d\TH:i:sO', 'Y-m-d\TH:i:s', 'America/Managua'), '2004-12-19T10:19:42-0600', '2004-12-19T10:19:42')
DateTime::setTimezone(): Can only do this for zones with ID for now
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/vendor/symfony/phpunit-bridge/DeprecationErrorHandler.php:73
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php:318
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php:238
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php:238
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/modules/migrate/src/Plugin/migrate/process/FormatDate.php:101
/home/travis/build/paul-m/drupal_dependency_bounds_test/drupal/core/modules/migrate/tests/src/Unit/process/FormatDateTest.php:75
--
There were 4 failures:
1) Warning
The data provider specified for Drupal\Tests\Component\Datetime\DateTimePlusTest::testDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now
2) Warning
The data provider specified for Drupal\Tests\Component\Datetime\DateTimePlusTest::testInvalidDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now
3) Warning
The data provider specified for Drupal\Tests\Core\Datetime\DrupalDateTimeTest::testDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now
4) Warning
The data provider specified for Drupal\Tests\Core\Datetime\DrupalDateTimeTest::testInvalidDateDiff is invalid.
DateTime::setTimezone(): Can only do this for zones with ID for now

This looks like some of the dataProvider code is malformed in some way for the Datetime component, which is then using deprecated code in some way (see that the error is thrown by DeprecatedErrorHandler).

This only shows up in the PHP 5.5.9 test.

Anyway, it doesn't show that we need to constrain versions on doctrine/common. If you run composer update under PHP 7.1, then Composer will use the best fit for that platform, which then probably show a minimum requirement of PHP 7.1 in the lock file for some of the packages.

For core, what we need is either the config:platform:5.5.9 setting (-1 on that from me), or the test in #2843328-51: Enforce minimum PHP version in composer dependencies which looks at core's lock file and verifies that it doesn't require any PHP newer than 5.5.9.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.