The "Symfony\Bridge\PsrHttpMessage\Factory\DiactorosFactory" class is deprecated since symfony/psr-http-message-bridge 1.2, use PsrHttpFactory instead.

I've found that that particular dependency has a requirement of php 7.1, which I didn’t realize when I made the issue yesterday, so it isn’t going to end up in our composer.lock file anytime soon, but it is being installed on my sites when I do composer update on a modern php version.

It's replacement seems to be available in 1.1.0 though, which is currently in the lock file, so perhaps we can start using it. Could it be this easy?

Haha, not even close. It's not a direct replacement and requires more packages that do have php7 dependencies, so maybe it's something we can tackle in 8.8

Okay, now I'm just being silly. It must be time to go home.

Wow, I didn't really think that would work. It is good to know if we ever support a minium php version of 7.1 that we can swap out for a psr17 message factory that easily. Back to the issue at hand. Here's a patch showing the deprections if symfony/psr-http-message-bridge is updated to version 1.2. This should cause about 2600 failures. Also is a patch locking the version to 1.1 patch releases, in which the Diactoros message factory is not deprecated. I'm in favor of locking the version until our minimum php version supports a more modern alternative. I think we suppress more than enough deprecation notices right now.

The alternatives to locking the minor version of psr-http-message bridge are to suppress the deprecation notices, or to do nothing, and not update the dependency in the lock file, because 1.2 requires php 7.1. Up to the FMs what to do (if anything).

That's odd, the composer lock file still has 1.1.0. Composer install should keep it there, but any composer update on php 7 or higher will install the new one.

It definitely broke my builds, until I forced the downgrade in my sites' composer.json. Jenkins runs updates on php 7.3 which was pulling in phmb 1.2, and then the project's phpunit tests were failing.

composer.lock is definitly part of the tagged release, and if we are going to upgrade to symfony/psr-http-message-bridge 1.1.1 in 8.8, then it is appropriate to add it to the composer.lock. The patch is made for a Drupal release, not to be applied to existing sites.

Although I've just noticed that 1.1.1 adds a new dev dependency that itself has a dependency of php7.1, so we may be stuck back with 1.1.0 after all. Queuing a test against php 7.0 and seeing if it breaks composer.

Respectfully reopening because while we updated psr-http-message-factory to 1.1.1 in that issue, we didn't lock it to <1.2, which is what gets installed if you composer update with php7.0 or higher. The purpose of this issue is to lock it to <1.2 in composer.json or otherwise manage the deprecation errors that come up so sites that do run an update don't break or throw deprecation errors.

If this is truly something we don't want to do then we can close this. I know we technically only guarantee what's in the lock file, but if we know of an issue with a vendor update, we should handle it if we can, and we can here pretty easily.

I've rather changed my mind from #7 and agree we should just suppress the deprecations after all.

I don't think there is one open. Removing the deprecation suppression would mean replacing the message factory with a psr17 message factory once php 7.1 is the minimum supported version, I assume in Drupal 9.

Added #3043471: Replace the DiactorosFactory message factory in symfony/psr-http-message-bridge with a PSR-17 compliant message factory as a follow up and postponed on changing our minimum supported php version to 7.1

I'm not even sure that there will be another release in the 8.6 series before 8.7 is released and 8.6 becomes security-fixes only. Nothing has been committed to the 8.6 branch in the week since the 8.6.13 security release, and 8.7 is due in just over a month.

Either way, that backport is at the discretion of the committers.