Drupal 9 uses PHP syntax that's deprecated in PHP 8.2, so exclude that from error_reporting() and DeprecationListenerTrait

Change makes sense to me. Should the drupal docs be updated to mention that 9.5 can work on 8.2? Would it be recommended?

I figured out how to change #3354670-19: Remove the laminas-feed pin from core-recommended to allow Drupal 9.5 to be installed on PHP 8.2 → 's changes to phpunit.xml.dist to instead make the needed change in DeprecationListenerTrait, so that it applies only to PHP 8.2, which I think makes that acceptable for this issue's scope now, so adding it here, which allows this to also pass PHP 8.2 tests on DrupalCI, yay!

Should the drupal docs be updated to mention that 9.5 can work on 8.2? Would it be recommended?

Even if/when #4 is committed, the situation will be a bit weird with drupal/core-recommended and drupal/recommeded-project because of 📌 Remove laminas-feed, laminas-escaper, and laminas-stdlib from drupal/core-recommended to allow Drupal 9.5 to be installed on PHP 8.2 Fixed .

You'll be able to do composer create-project drupal/recommeded-project:^9, because that includes a composer.lock file, and Composer doesn't check platform constraints when installing from a lock. However, you will not be able to do any composer operation (e.g., composer update or composer require) following that, because drupal/core-recommended pins to Laminas minor versions whose composer.json constraints don't allow PHP 8.2. You can get around that by either switching from core-recommended to core → , or using --ignore-platform-req=php+ or similar. So, not sure yet what that means with respect to what we'll want to say on https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → .

The failures in #4 are due to deprecated code called within data providers. When data providers are run, DeprecationListenerTrait's error handler isn't being used yet. Changing core/phpunit.xml.dist from error_reporting=32767 to error_reporting=24575 makes the tests pass, but I haven't figured out yet how to apply that change only for PHP 8.2 (i.e., where this can be done in PHP code rather than in XML).

I think this is the cleanest way to fix it. Hopefully the included docs explain the rationale clearly.

s/null/NULL/

Cool, nice progress. Thanks!

Alas that the PHP 8.2 patch is still failing, back to NW.

Kernel tests run in an isolated process, which adds interesting behavior around different error handlers registered in the different processes.

The last submitted patch, 10: d95-php82-error-reporting-3355675-10.patch, failed testing. View results →

All the code in this patch (and in #10) is within if (PHP_VERSION_ID >= 80200) { blocks, so I'm pretty sure #10's PHP 8.1 test failure is a random unrelated failure.

This patch improves on the docs a bit to make things clearer.

Nice work. The comments are really helpful as some of this is quite arcane and explaining it will help us re-use this in the future if we need it for another PHP version.

This looks good to me to at least allow D9 to run on PHP 8.2 even if we didn't solve all the deprecations - we never will, so to me this is OK to commit in a patch release and at least allow an easier upgrade path for some users, as they can go to PHP 8.2 on Drupal 9.5 now, and then Drupal 10 later.

Yeah agreed with #13, we gave up on full PHP 8.2 support, but allowing installs to run and CI runs to be green is worthwhile for sites that want to update to Drupal 10 on PHP 8.2

Minor comment improvement only, so leaving RTBC.

Looks good to me - committing now so it can make it into this week's patch release.

@smustgrave that's a good question. I don't think PHP 8.2 should be the recommended version for Drupal 9.5. Adding a note that it can run on it might be worth it, but we'll need 📌 Remove laminas-feed, laminas-escaper, and laminas-stdlib from drupal/core-recommended to allow Drupal 9.5 to be installed on PHP 8.2 Fixed as well as enabling core test runs on 8.2 first I think.

Tagging for release notes and added a one-liner just to have something for now.

Automatically closed - issue fixed for 2 weeks with no activity.