[12.x] Require PHP 8.5

Is PHP 8.5 the eventual minimum version of Drupal 12, or is this an interim step?

Answering myself based on the rule linked, PHP 8.5.0 is at alpha now with a beta expected August 14, 2025 and stable somewhere in November 2025: https://www.php.net/supported-versions -- later PHP versions will not yet be stable when Drupal 12 reaches beta, so it will be PHP 8.5.x for sure for Drupal 12.

Added the statement to the issue summary :)

Surely PHPStan will report new errors by raising the platform in composer.json. Let's find out for now.

Added child issue #3564075: Remove use of backtick operator in run-tests.sh for PHP 8.5
#3515347: Reduce run-tests.sh complexity in spawning subprocesses covers backtick deprecation message by removal of the related code block

Is there any chance that Drupal 12 will support being run on any versions of PHP older than PHP 8.5? The "PHP requirements" page does not currently document what versions are supported for Drupal 12.

I tried to remove the BC layer from mysql but PHPStan complains that these constants are all zero?

  Line   mysql/src/Driver/Database/mysql/Connection.php                      
 ------ -------------------------------------------------------------------- 
  125    Array has 3 duplicate keys with value 0                             
         (\Pdo\Mysql::ATTR_USE_BUFFERED_QUERY, \Pdo\Mysql::ATTR_FOUND_ROWS,  
         \Pdo\Mysql::ATTR_MULTI_STATEMENTS).                                 
         🪪  array.duplicateKey                                              

The stubs that ship with PhpStorm also show these constants as zero.

Might have gone a bit far with removing PHP backward compatibility, we could split some of this out if we want to.

I also agree with @catch that we probably shouldn't commit this for a little while so we can be more confident about backports to 11.x.

The minimum version requirement is listed as PHP 8.3 twice in core/INSTALL.txt.

core/lib/Drupal/Core/Utility/PhpRequirements.php has the EOL date for PHP 8.3 in $phpEolDates.

And as I mentioned in #3567815: [D12][CI] Test on PHP 8.5 only there are three jobs for PHP 8.3 in .gitlab-ci.yml in the block that starts on line 407.

The current set of changes looks OK though. I double-checked all of the deletions and verified that the correct stuff got removed. The only remaining use of PHP_VERSION_ID is in TokenParser, which I assume we aren't editing because it's copied from Doctrine.

Change parent and priority

Echoing @liam-morland's question above (emphasis mine):

Is there any chance that Drupal 12 will support being run on any versions of PHP older than PHP 8.5? The "PHP requirements" page does not currently document what versions are supported for Drupal 12.

Yes, the page has been updated to state 8.5 minimum for Drupal 12. The question is: Will PHP 8.4 be an option for Drupal 12?

The current Debian release (trixie) already supports 8.4, but PHP 8.5 isn't in the Debian repos, not even from Debian unstable (sid). Debian 14 (forky), the first release that could (and likely will) natively support PHP 8.5, is due out summer of 2027. PHP 8.4 will be supported until 2029.

While paths exist to install PHP 8.5 today (containers, third-party repos, build-from-source), I think the burden should be on Drupal to show why the absolute latest is necessary or why running on PHP n-1 is not possible.

Will PHP 8.4 remain an option for Drupal 12, and if not then what new feature of PHP 8.5 is critical for Drupal 12?

Moving this to the policy discussion in #3406215: [policy] Default to requiring the latest stable PHP release available when a new major version reaches the first beta window.

The changes for INSTALL.txt are in #3568123: Update INSTALL.txt for Drupal 12 and that is RTBC. These two should be committed at the same time.

Addressed #21, and found another case in the package_manager tests that needs a small update. There are some other old BC layers lying around I think those should be handled elsewhere as they're not quite as straightforward, they aren't critical.

Question though. If this gets merged to main and those that are doing 11.x work won’t they have to now upgrade

btw updating in ddev using just the config.yml gets 8.5.0RC3

If you use ddev for core development it's pretty easy to update to 8.5 only in your core dev

Me, a month ago, thinking I was super smart, did this.
Me, last week, when doing a git bisect, had to revert and restart ddev.

(It was trivial but still super annoying.)

Can https://git.drupalcode.org/issue/drupal-3537713/-/blob/3537713-12.x-requ... be removed here?

rebased and done #31

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

My feedback was addressed. The additional changes to TemplateProjectTestBase make sense. I didn't know what was up with PHPStan, so I ran it locally and didn't have any errors. I think this is probably good to go. Don't forget the complimentary patch in #3568123: Update INSTALL.txt for Drupal 12.

Don't think they're blockers, but had a couple questions about the Symfony polyfills for 8.4 and 8.5.

Yep let's skip installing those polyfills, good spot.

Done #37/38. #40 deserves an issue of its own IMO.

#37/38 addressed, so lgtm.

Stubbed an issue for #40: #3570634: Remove fallback classloader and related code in AttributeClassDiscovery

Rebased, PhpRequirements had conflicts.

Per #39 should this wait till ddev ships with a non RC version?

Not necessary to wait, IMO. Per ddev maintainers on Slack:

You can add a custom .ddev/web-build/Dockerfile.update to a project:

RUN (apt-get update || true) && apt-get upgrade -y

Committed 2b1cd68 and pushed to main. Thanks!

Yeah I don't think we need to wait. The ddev release will happen and there instructions to update are quite simple.

Opened #3570713: Bump PHPStan to 2.1.38 as I'm seeing an issue on HEAD when trying to commit another issue which might be related to the version bump

Wouldn't some coordination (or at least communication) between the DDEV team and Drupal core team be a great idea, to help streamline future dev-releases of Drupal, and their support in DDEV? Feel free to join the conversation in Add a project type for Drupal 12 #8055.