Contrib.social

Add upper PHP constraint to composer.json and/or the installer

Open on Drupal.org →
Created on 26 December 2019, over 4 years ago
Updated 24 July 2023, 11 months ago

Problem/Motivation

Although Drupal contains checks against the minimum supported version of PHP, currently there are no checks to stop the user from running Drupal with a version of Drupal that is newer than supported. For example, users who attempt to use Drupal 8.8.1 with PHP 7.4 will encounter problems, and there is nothing beyond documentation to warn them that this configuration does not work.

Proposed resolution

Add guards so that Drupal installations on new versions of PHP will fail-fast.

  • Drupal's composer dependencies should also have a constraint rejecting versions of PHP that are too new.
  • Drupal should have a constant DRUPAL_MAXIMUM_PHP to compliment DRUPAL_MINIMUM_PHP; it should be used in the same ways the existing constant currently is.

Remaining tasks

Add DRUPAL_MAXIMUM_PHP and corresponding checks.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Drupal's composer.json file now constrains the maximum supported PHP version in addition to the minimum version.

Original report

I got a little over-zealous in bumping the PHP version for my Drupal project's Docker environment and discovered that Drupal 8.8.x has a known incompatibility with PHP 7.4 (being worked on at #3086374) but this is not expressed in composer.json, and there are no current core dependencies that otherwise block installation on PHP >= 7.4.

This patch adds an upper bound to PHP 7 compatibility to < 7.4.0, which will help address this issue at current and also on any future release cycle that is behind or otherwise out-of-sync with a new PHP 7 minor version. (E.g., when PHP 7.4 compatibility comes in, this can change to < 7.5.0).

I'm not sure of the exact internals of testbot relative to composer install, so unsure if this requires any follow-up on infra or in a test? This can be validated after the install by a failure, with some manual testing (The composer package is built from latest PHP stable version):

$ docker run --rm -u `id -u` -v `pwd`:/src -w /src/core composer:1.9 install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - This package requires php >=7.0.8 <7.4.0 but your PHP version (7.4.1) does not satisfy that requirement.
🐛 Bug report
Status

Active

Version

11.0 🔥

Component
Composer  →

Last updated 1 day ago

No maintainer
Created by

🇺🇸United States bradjones1 Digital Nomad Life

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 1 year ago →
    🇯🇵Japan tyler36 Osaka

    What is the reason behind not having a lower limit constraint?

  • Comment about 1 year ago →
    🇺🇸United States bradjones1 Digital Nomad Life

    What is the reason behind not having a lower limit constraint?

    There already is one, however it's not necessarily enforced in the same way (yet.) This is a separate issue, though definitely related in spirit.

  • Comment about 1 year ago →
    🇺🇸United States bradjones1 Digital Nomad Life

    And re: #16, tarballs no longer a thing. :-)

  • Comment about 1 year ago →
    🇯🇵Japan tyler36 Osaka

    @bradjones1 thanks for the reply
    I was hoping to get a minimum PHP restriction in Drupal because it is not appearing in drupal/recommended-project.
    This was the closest issue I could find that addressed this.

    Do you know of the specific issue? If not, I will create one.

  • Comment about 1 year ago →
    🇺🇸United States bradjones1 Digital Nomad Life

    #28 You're looking in the wrong package for the minimum constraint. It's in drupal/core already.

  • Comment 11 months ago →
    🇺🇸United States xjm

    FWIW I am a strong -1 on adding any constraint or hard error. It wold huge overhead to have to constantly explicitly re-declare compatibility for new PHP versions that might work just fine, and it would mean sites and downstream would be constantly hard-blocked on us to declare our compatibility. We dropped use Laminas packages in D10 because of exactly that problem -- they declared max constraints on PHP versions and it blocked Drupal from being compatible with new PHP versions even when really everything worked fine.

    I'm more "meh" on adding a warning. I still don't like the overhead of having to constantly update a comment so that the installer or status report can say "by the way, Drupal core hasn't fixed all critical/all known compatibility issues with PHP version whatever". Plus, even when core does fix all its known issues with a given PHP version, there's no guarantee that the site's installed contrib will be compatible at all, so that also reduces the usefulness of such a warning.

    So, after thinking about it, I'd lean toward wontfix for this issue. I think the status quo of the status report linking the PHP requirements handbook page → is probably good enough, without the downsides that an error or even a warning would have.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024