Replace the DiactorosFactory message factory in symfony/psr-http-message-bridge with a PSR-17 compliant message factory

Not clear what this is postponed on, sorry if I'm missing something.

Will this issue allow us to drop Diactoros as a dependency?

At the moment this is for updating to zend-diactoros 2.* rather than replacing it.

Per #2917655-44: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4, it now seems likely that Drupal 8.9 will require PHP 7.1.

Once that becomes not just likely but fact, this would become unblocked (per #3, this has been blocked on PHP 7.1 being the minimum version). But it'd then still be blocked on the 8.9.x branch opening.

#2917655-48: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 makes it sound less likely again that Drupal 8.9 will require PHP 7.1, which would block this.

Fixing typo in title, and updating status to make it more clear this is blocked on Drupal core requiring PHP 7.1 as its minimum version.

7.2 at least required for 9.0 and related issue filed

This is fixed by #3104354: Update Laminas components including Diactoros I think?

Following #3104015: Replace ZendFramework/* dependencies with their Laminas equivalents this patch takes the upgrade in #3104354: Update Laminas components including Diactoros and work in #3039584: The "Symfony\Bridge\PsrHttpMessage\Factory\DiactorosFactory" class is deprecated since symfony/psr-http-message-bridge 1.2, use PsrHttpFactory instead. and also upgrades symfony/psr-http-message-bridge to v2.0.0 for good measure. As we need to change service definitions here, for full compatibility with 8.9 can this be committed to 9.0 or do we have to wait until 9.1?

I don't see a reason here to wait until 9.1.x to commit this, there's no API change really, but Berdir moved it up to 9.1 so may have views?

Rerolled, and removed two skipped deprecations that are obsoleted by this patch.

Reroll following commit of #3104354: Update Laminas components including Diactoros

Setting parent

Looks ready except RM-appproval

Reroll

1. +++ b/core/composer.json
   @@ -41,7 +41,7 @@
   -        "symfony/psr-http-message-bridge": "^1.2.0",
   +        "symfony/psr-http-message-bridge": "^2.0",
   

   This part at least seems totally non-controversial to do in 9.0.x if it's done in time for beta.

2. +++ b/core/core.services.yml
   @@ -776,8 +776,17 @@ services:
      psr7.http_message_factory:
   -    class: Symfony\Bridge\PsrHttpMessage\Factory\DiactorosFactory
   +    class: Symfony\Bridge\PsrHttpMessage\Factory\PsrHttpFactory
   +    arguments: ['@psr17.server_request_factory', '@psr17.stream_factory', '@psr17.uploaded_file_factory', '@psr17.response_factory']
   

   It's still possible that this could be disruptive and might need the same thorough testing Wim did previously? Maybe we could split it into a separate issue?

In general, I'd also want to know what Symfony's long-term support plans are for the message bridge, since it's versioned separately from the rest of the Symfony components.

Thanks for the review!

#21.2 has to be done if we do #21.1, as DiactorosFactory is removed in symfony/psr-http-message-bridge 2.0.0; this is the backward incompatible part.

Note that this patch also removes two deprecation messages - the DiactorosFactory is considered deprecated, hence its removal in 2.0.0. I don't know Symfony's plans but I can only assume that 2.x will be supported better than 1.x going forwards.

Rerolled patch attached, as composer.lock has changed and the other parts have fuzzed a bit.

+++ b/core/core.services.yml
@@ -786,8 +786,17 @@ services:
     class: Symfony\Bridge\PsrHttpMessage\Factory\HttpFoundationFactory
+  psr17.server_request_factory:
+    class: Laminas\Diactoros\ServerRequestFactory
+  psr17.stream_factory:
+    class: Laminas\Diactoros\StreamFactory
+  psr17.uploaded_file_factory:
+    class: Laminas\Diactoros\UploadedFileFactory
+  psr17.response_factory:
+    class: Laminas\Diactoros\ResponseFactory

I don't think we're using it yet, but these seem like good candidates for defining as internal service definitions.

> I don't think we're using it yet, but these seem like good candidates for defining as internal service definitions.

We can set public: false on these I think?

That sounds good, moving to needs work for that change.

Symfony contracts also has a different version number to the other Symfony components, see https://github.com/symfony/contracts/releases

I assume they're doing this for any new components that are self-contained (but which might be new dependencies for other parts of Symfony, which contracts definitely is).

Changed the new services to be public: false

Thanks I think that's all that's left here.

Updating the issue summary so it references laminas/laminas-diactoros and not zend.

Rerolled as #3117558: 9.0.x core's hash in composer.lock is wrong landed ... the only difference is

2c2
< index b75e457532..14af35207b 100644
---
> index 959558421e..14af35207b 100644
9c9
< -                "reference": "f8e50d64acdddb816b10f83ca307712bd2cd65e5"
---
> -                "reference": "1135d82ca80e22e7f25b1bd9a8613cae5ae06372"

Opened a ticket to clarify the support cycle. Given we're already using this component I think it's fine to answer before that's answered, so untagging. (Also this doesn't really supply an API as such, so if we had to downgrade during beta due to bad news, it wouldn't be the worst thing, but having to downgrade is less likely than having to upgrade due to dropped support).

Here's the github issue to track support cycle https://github.com/symfony/psr-http-message-bridge/issues/76

I agree with @catch that getting onto v2 is good for D9 prior to beta.

Committed 05b122f and pushed to 9.0.x. Thanks!