Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
- Download Drupal Core 8.3.x-Dev
- Run composer update
- 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.
Comment | File | Size | Author |
---|---|---|---|
#11 | doctrine_common_version_below_2.8-2898119-11.patch | 383 bytes | sgurlt |
Comments
Comment #2
mondrakeSee #2887000: composer.json does not constrain Symfony components to minor and patch versions that are compatible with Drupal before you go too far with a patch :)
Comment #3
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedOh very awesome, thanks a lot for quickly hopping in, I already started to clone the drupal repo :)
Comment #4
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedHm but where is the drupal 8.3.x patch?
Comment #5
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedComment #6
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedSince I could not find a patch for this, here it is :)
Comment #7
cburschkaHi, 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:
After setting this, composer will enforce compatibility with PHP 5.5.9 regardless of whether you're using PHP7.
Comment #8
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedAccording to: https://www.drupal.org/docs/7/system-requirements/php
This then should be:
right?
Comment #9
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedNew patch based on #8.
Comment #10
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedReroll, wrong version ...
Comment #11
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedIt did not work when I have patched the /core/composer.json, so I did the adjustment now for the /composer.json
Comment #12
dawehnerOne other thing we can do is to explicitly specify
"doctrine/common": "^2.5<2.8",
Comment #13
sgurlt CreditAttribution: sgurlt as a volunteer and at Bright Solutions GmbH commentedThis 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
Comment #14
BerdirThere 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
Comment #16
pounardYou'll potentially have problems not only with doctrine/common but a few other packages too:
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.
Comment #18
Mile23Super-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.
Comment #19
Mile23Comment #20
3liI have added the following to my composer.json (inside "config")
But I am still getting issues,
Is there something else I need to be doing?
Comment #21
fjgarlin CreditAttribution: fjgarlin at Amazee Labs commentedDo you get that message after running
composer install
orcomposer update
? You should run the latter.Comment #22
cburschkaAdding 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.
Comment #23
FMB CreditAttribution: FMB commentedNot necessarily revert, just launching
composer update
as fjgarlin said, so that composer.lock reflects your changes in composer.json.Comment #24
joelsteidl CreditAttribution: joelsteidl at Aten Design Group commentedI ran into this issue as well. The patch seemed to work as advertised when running composer on the machine with 5.6.
Comment #25
revagomes CreditAttribution: revagomes at Taller commentedI've had the same issue here and path #11 worked like a charm.
Comment #26
Mile23See #12.
Comment #27
Mile23So @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:
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.Comment #29
colanSo this is really about updating the tests then.
To confirm #27 from PHP 7.1 requirement for Doctrine packages:
...and it proceeds to provide options on how to mitigate that.
Comment #30
Mile23I think it's safe to close this issue since #2843328: Enforce minimum PHP version in composer dependencies is in, meaning we test the lock file to make sure Drupal core can be installed under PHP 5.5. This way core devs won't inadvertently patch composer.lock with an inappropriate dependency.
Comment #31
alexpott@Mile23 I think you meant to actually close this issue.