[Symfony 5] The signature of the "Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch()" method should be updated to "dispatch($event, string $eventName = null)", not doing so is deprecated since Symfony 4.3.

Probably the best choice is get consensus on #2825358: Event class constants for event names can cause fatal errors when a module is installed first and then start implement BC shim

I think we will have to fork and replace the symfony interface with one where we can expand the argument list and do our deprecations now, so that for Drupal 9 we are compliant with the SF5 and PSR-14 interfaces.

Why not just using the LegacyEventDispatcherProxy as described at https://symfony.com/blog/new-in-symfony-4-3-simpler-event-dispatching ?

Because that is not available in Symfony 3.

That's true but not relevant. The event dispatcher is "independent" from the symfony version. You can install the symfony event dispatcher in version 4.3 which is compatible to "symfony" 3.4.

Symfony/event-dispatcher 4.3 isn't compatible with php 7.0. we can't use it in Drupal 8.
When we fix it in Drupal 9, that is the route will take, but this is postponed until the branch opens.

According to https://www.drupal.org/docs/8/system-requirements/php-requirements

Support for PHP 7.0 will continue until at least March 6, 2019. We will post an announcement as soon as the end of PHP 7.0 support has been scheduled.

So why don't we say that from Drupal 8.8.0 we are not going to support PHP 7.0 anymore? That would be exactly 8 months between our promise to support it at least until March 6, 2019 and the release date of Drupal 8.8.0 scheduled for December 4, 2019.

Also PHP 7.0 is EOL since January 10, 2019. I think that 11 months supporting an EOL version is pretty enough, especially given the fact there is an incompatibility that we could fix by doing so.

Even if we did, changing a major version on the dispatcher would introduce a number of hard BC breaks that likely wouldn't be acceptable in a Drupal minor release.

Not if we use the BC layer as suggested in #6 or provide our own based on that one.

I've discussed this with the Release Managers in the recent past and I have just reached out for reconfirmation

Tagging accordingly.

We are trying not to add new deprecations in 9.0.x so should we add a @todo and a followup issue here to deprecate this in 9.1.x? Or, as the existing BC layer is enough for now, just bump this to 9.1.x anyway?

My point was that in this specific case we are replacing a Symfony deprecation with a silent BC layer, but in Drupal 10 I assume we want to remove that BC layer entirely? If so we should create at least a followup to do that now - and to achieve that, we also need to deprecate some time in the Drupal 9 cycle. If we don't do this now, we will likely just forget that this silent BC layer even exists.

Maybe.

Let's see what we need to fix.

Bumping to critical since it blocks Drupal 10.

Maybe #2833771: PSR-14 (Events) development and support should be marked as duplicate, too.

Since it seems that this issue here is the one that will be continued, I repeat my comment from https://www.drupal.org/project/ideas/issues/2833771#comment-13668083

I just want to mention that we removed the hard dependency to symfony's event-dispatcher in the solarium library, the PHP client for Apache Solr.
In solarium we now do pure PSR-14 compliant event dispatching.

symfony itself became PSR-14 compliant with 4.3. Unfortunately drupal core didn't adopt to it.

In order to get the latest solarium version 6 to work with the search_api_solr module for Drupal 8 and 9 I included a light wight PSR-14-Bridge in search_api_solr 4.1.0:
https://git.drupalcode.org/project/search_api_solr/-/tree/4.x/src/Solari...

like already mentioned in #2876675: Allow symfony/event-dispatcher 4+ to be installed in Drupal 8 I hope that drupal becomes more inclusive for third party libraries in the future.

As I proposed in the past, it is not too late to do something similar to symfony's LegacyEventDispatcherProxy in drupal Core to ease the life for contrib developers and to meet your requirements:

From the release management perspective, we would not block the release of Drupal 9 or any major on adopting this PSR. It would have to be adopted in a way that met our BC requirements and ideally followed the continuous upgrade path policy.

@mkalkbrenner thanks I marked that issue duplicate of this one too.

#3020303: Consider using Symfony flex to allow switching between major Symfony versions would have made it a lot easier to run Symfony 4 on Drupal 8, (or Symfony 5/6 on Drupal 9), but unfortunately has been stalled for some time (mostly on min/max dependency testing).

The patch from #18 no-longer applied to 9.1.x, so here's a re-roll.

Also updated the issue summary.

I think we should go ahead and convert calls to EventDispatcher::dispatch() in this issue.

Then we should try another patch with the deprecation un-suppressed/adding our own, and see if it's possible to trigger a deprecation - whether we can or not may depend on dependencies that are also dispatching events. If we're not able to remove the deprecation suppression due to dependencies, we should add a follow-up for that - so that contrib/custom code can start to take advantage of the forward-compatibility layer.

Started looking at converting the calls, but while there's not a hard dependency, it will be less overall work if we do #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead first - since the conversions here with otherwise have to use the deprecated Event class.

Making it clear from the title that this is soft-blocked on the other issue.

Here's a patch on top of #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead.

Fixing the syntax error..

OK after actually doing the patch, there is only one use statement that actually conflicts with #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead, it just happened that was the first class I looked at before, so here's a standalone one with just the changes required for this issue. Since there's no real conflict at all, removing PP-1 as well, either could go in first and it'll be a small re-roll for the other.

What's still missing, as discussed in #18 and #21, is triggering our own deprecation message. This is the Symfony one:

 @trigger_error(sprintf('Calling the "%s::dispatch()" method with the event name as the first argument is deprecated since Symfony 4.3, pass it as the second argument and provide the event object as the first argument instead.', EventDispatcherInterface::class), E_USER_DEPRECATED);

I was originally thinking we should copy the Symfony one exactly, but I think it would be easier to Drupal-ify it instead and use our standard format. Once we've done that we should also add test coverage for the deprecation message.

Overzealous removing the skipped deprecations, we can't do anything about the parent class/interface so those need to be removed in Drupal 10 as part of the Symfony 5 update process, which is OK.

Also some dispatch invocations in unit tests that my grepping didn't find.

Think I messed up the patch creation somehow, tests are passing locally. Trying again.

Added the deprecation message and a test for it.

+++ b/core/lib/Drupal/Component/EventDispatcher/composer.json
@@ -7,7 +7,8 @@
+    "symfony/event-dispatcher": "^4.4",

Is the event-dispatcher still needed as dependency?

Yes we still use various classes from there like GenericEvent. It might be worth auditing exactly how much we actually use though.

+++ b/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php
@@ -86,9 +88,19 @@ public function __construct(ContainerInterface $container, array $listeners = []
+      $event = $event_name ?? new Event();

This is probably quite minor but following #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead we have three events classes to choose from and I wondered exactly which one we should be instantiating here. I suppose this is only the BC layer so instantiating the old Symfony class seems correct.

Everything else looks great so this is good to go, I think.

So I actually changed that in #3153803: [Symfony 5] Update EventDispatcher::dispatch() to make it forward-compatible with Symfony 5 to use ContractsEvent, but I think that was actually wrong - if existing event listeners are type hinting on the legacy Symfony Event class, we don't want to break those typehints - so the default either needs to be the deprecated class or the Drupal subclass. Either way, I think that issue is the place to finalise that decision since it's where we actually trying to enforce things.

Committed bd4c5f0 and pushed to 9.1.x. Thanks!

diff --git a/core/tests/Drupal/Tests/Component/EventDispatcher/ContainerAwareEventDispatcherTest.php b/core/tests/Drupal/Tests/Component/EventDispatcher/ContainerAwareEventDispatcherTest.php
index be3a950afc..facac8776a 100644
--- a/core/tests/Drupal/Tests/Component/EventDispatcher/ContainerAwareEventDispatcherTest.php
+++ b/core/tests/Drupal/Tests/Component/EventDispatcher/ContainerAwareEventDispatcherTest.php
@@ -489,7 +489,7 @@ public function testDispatchLazyListener() {
     };
     $this->dispatcher->addListener('foo', [$factory, 'foo']);
     $this->assertSame(0, $called);
-    $this->dispatcher->dispatch( new Event(), 'foo');
+    $this->dispatcher->dispatch(new Event(), 'foo');
     $this->dispatcher->dispatch(new Event(), 'foo');
     $this->assertSame(1, $called);
   }

Fixed coding standard on commit.

https://3v4l.org/dRb0l

Here are backports for 8.8, 8.9 and 9.0 in case anyone needs this. Due to the Composer change that is needed for 8.x be warned that this hass more far-reaching consequences there. Because 8.x still has a 3.x symfony/http-kernel, I removed the actual deprecation from those patches.

All patches pass tests on their respective branches at time of writing, which can be seen on #408, #410 and #411 of #2274167: [ignore] Patch testing issue.

(For the record, the version numbers in the patches don't have any meaning other than that it took me a couple tries, respectively, to get them right.)

Sorry for the noise. For this to work with Composer setups the patch may not include anything outside of /core, so here's those patches for 8.8 and 8.9.

This is going to affect contrib - see http://grep.xnddx.ru/search?text=-%3Edispatch%28&filename= - we need to mention this in the release notes.

This starting to trouble contrib already: https://www.drupal.org/project/scheduler/issues/3166688, https://gitlab.com/drupalspoons/devel/-/issues/344.

Is/was there no way to introduce this with any BC layer or warning to developers?

Isn't this a compat break between 9.0 and 9.1. Those are not allowed unless I'm missing something. I'm coming from https://gitlab.com/drupalspoons/devel/-/issues/344