Problem/Motivation

In #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4, we propose increasing \Drupal::MINIMUM_SUPPORTED_PHP to 7.4 in Drupal 9.4. This results in the following warning being displayed on installation, update, and the site status report:

Your PHP installation is too old. Drupal requires at least PHP 7.4.0. It is recommended to upgrade to PHP version 8.1 or higher for the best ongoing support. See PHP's version support documentation and the PHP requirements page for more information.

However, "the best ongoing support" is unclear, as are the consequences of continuing to use PHP 7.3. The specific consequences of using an old PHP version are explained in #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4.

Proposed resolution

(Also see #2670966: Warn users of old PHP versions and #2927344: Specifically warn about end dates for PHP support for old versions for examples of the previous messaging used in Drupal 8.)

Explain the consequences of PHP that is "too old" more clearly, either by improving the UI strings and/or adding more specific explanations to the system requirements documentation. See the issue summary of #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 for what the consequences might be. In particular:

  1. \Drupal::MIINIMUM_SUPPORTED_PHP is increased to at least 7.4and possibly later 8.0 (see the proposal in #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules).
     

  2. We monitor Drupal 9 dependencies' PHP version support from now until the Drupal 9 end-of-life.
     

  3. If:

    • A dependency drops support for PHP 7.3, and
    • The dependency also no longer supports previous versions that were compatible with PHP 7.3

    Then:

    • A new minor version of core (e.g., Drupal 9.5) is created that increases the minimum PHP requirement and the constraint for the affected dependency.
    • Old Drupal core minors (e.g., 9.3 and 9.4) are considered unsupported.
    • Security fixes are still backported to the old Drupal core minors only for security advisories that do not involve the affected dependency.

 

Implementation details

 

  1. [DONE] \Drupal::MINIMUM_SUPPORTED_PHP is increased to at least 7.4, but installation is allowed on this version (see #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4).
     

  2. [DONE] The PHP requirements handbook page table is updated to indicate PHP 7.3 is only supported by 9.x versions less than 9.4.x.
     

  3. [DONE] A section is added to the above handbook page: "What does it mean for a PHP version to be too old?" (the text used in the UI).
     

  4. Messaging about PHP versions less than \Drupal::MINIMUM_SUPOPRTED_PHP is updated in 9.4.x prior to 9.4.0. It links the PHP requirements handbook page section directly.
     

  5. We consider backporting some or all of the changes to 9.3.x in a patch release so that at least future bugfix and security releases of 9.3.x also have the necessary information.
     

  6. The new minor (e.g. 9.6.x) is branched from the tip of the production branch (e.g. 9.5.x HEAD).
     

  7. The new minor increases \Drupal::MINIMUM_PHP, the Composer PHP constraint, and the Composer constraint for the dependency.
     

  8. The new minor release (e.g. 9.6.0) is tagged immediately, with release notes referencing the issue for the dependency change. (It does not require a stabilization phase because it was already the stable bugfix branch.)
     

  9. The release cycle documentation is updated to indicate that 9.5.x (and 9.4.x if it is before June 2023) are considered end-of-life.
     

  10. Issues are bulk-updated from 9.5.x to 9.6.x with a message referencing the issue for the dependency change.
     

  11. A Drupal core blog post is created about the new 9.6.0 release and its PHP requirement.
     

  12. If it is still before December 2022, 9.3.x is explicitly marked unsupported on the core release node, to ensure users receive immediate messaging about this branch (since it does not contain our UI warnings in releases to date).
     

  13. "Recommended" is unchecked for 9.5.x on the core release node.
     

  14. "Supported" is still checked on the core release node for 9.5.x (only visible to core committers), and the branch still receives automated testing in order to facilitate best-effort backports.
     

  15. Security advisories that do not involve the affected dependency are still backported to 9.5.x.
     

  16. If a security update is released for the affected dependency that would require a core security advisory, it is not backported, and all 9.5.x and earlier core releases are marked insecure (so site owners see "Security update required!" in addition to the warnings and errors about old PHP).
     

  17. We could still backport other security fixes to 9.5.x on a best-effort basis after such an SA, but the releases would still be marked insecure.

Remaining tasks

This is postponed on #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4.

#4 could be addressed here as well.

User interface changes

TBD

API changes

Probably none.

Data model changes

None.

Release notes snippet

None.

Comments

xjm created an issue. See original summary.

xjm’s picture

Issue summary: View changes
Related issues: +#2670966: Warn users of old PHP versions

 

xjm’s picture

quietone’s picture

While doing this review I questioned the use of the possessive form with PHP, as in, "PHP's". Personally, I find it jarring to read but then languages do change. Still, it would be nice to consider using wording to avoid this situation.

xjm’s picture

Issue summary: View changes

A better option might be to say "the PHP project" rather than "PHP", to distinguish the entity that releases and maintains PHP versions from the language itself.

quietone’s picture

Although I find it jarring to read and would swear I was taught it was wrong, according to grammerly, section "Using abstract nouns in a sentence", using the possessive form with abstract nouns is OK.

#5. Nice point about making the distinction between the project and the language.

xjm’s picture

Issue summary: View changes

@quietone suggested that to unblock #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4, we could add to the IS there (and the proposed resolution here) what those consequences might actually be. Current proposal:

  • \Drupal::MIINIMUM_SUPPORTED_PHP is increased to at least 7.4and possibly later 8.0 (see the proposal in #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules).
  • We monitor Drupal 9 dependencies' PHP version support from now until the Drupal 9 end-of-life.
  • If:
    • A dependency drops support for PHP 7.3, and
    • The dependency also no longer supports previous versions that were compatible with PHP 7.3

    Then:

    1. A new minor version of core (e.g., Drupal 9.5) is created that increases \Drupal::MINIMUM_PHP and the Composer PHP constraint to the new requirement.
    2. The new core minor also increases the constraint of the affected dependency to their new minor version.
    3. Old Drupal core minors (e.g., 9.3 and 9.4) are considered unsupported.
    4. Security fixes are still backported to the old Drupal core minors for security advisories that do not involve the affected dependency.
    5. If a security update is released for the affected dependency that would require a core security advisory, then releases of the old Drupal core minors are marked insecure.

Updating the IS with that information.

xjm’s picture

Issue summary: View changes

Outlining specific implementation details.

catch’s picture

#7 looks fine to me.

Using 'final scheduled' per #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 covers the issue of not being able to call 9.4.x an LTS release too.

quietone’s picture

Yes, #7 is good for me as well.

I don't think we can use 'final scheduled' because creating a minor release when a dependency drops support for a PHP version is an unscheduled event. We can just say that the last release of the minor is the Long Term Support or something like that.

One last point, the proposed resolution suggests improving the UI strings. With the changes to the php-requirements page I don't think that is necessary. But should we anyway?

xjm’s picture

@quietone, re: the UI strings, I'm not sure. We already link the updated handbook page -- we could link the specific header, but I put it right under the table for visibility anyway because it's the most likely thing after the versions themselves to affect someone.

It's possible that we could make the UI strings warn more clearly about the consequences. Right now, we tell them to upgrade "for best ongoing support" (which was deliberately vague). However, they might need to upgrade because otherwise their site might not receive future security updates, which is a specific consequence that might do a better job of getting their attention in the UI.

We could additionally warn them other places. E.g. the emails that get sent when a security update is required could also mention the PHP version if it is below MINIMUM_SUPPORTED_PHP.

xjm’s picture

Issue summary: View changes

 

xjm’s picture

Issue tags: +Drupal 9.4 target

 

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

xjm’s picture

Issue summary: View changes

Updated the IS to reflect the December D10 release scenario, and checked off a couple items that were already fixed in advance of 9.4.0.

catch’s picture

Status: Postponed » Active

I think this can be unpostponed now, but I'm not sure what the explicit next step is here.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

effulgentsia’s picture

Version: 10.1.x-dev » 9.5.x-dev

Bumping this, because PHP 7.4 is now also officially EOL by PHP, so due to #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules, Drupal sites are now warning about that being too old as well, despite some Linux distros still maintaining security support for 7.4 and a not insignificant number of users still choosing to stay on 7.4 if they have custom code that's not yet compatible with PHP 8.

I don't think we need to change #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules, but clearer documentation for people about what the consequences would be for remaining on PHP 7.4 would be helpful.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Details on what 'too old' means was added to the requirements page in Feb 2022, https://www.drupal.org/node/2891690/revisions/view/12538405/12554358. Therefore I think that the initial problem here has been resolved.

Shall we close this?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.