Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Conditions are context-aware and actions will be context-aware when #2011038: Use Context system for actions is fixed. The last remaining event handling plugin type to make context-aware are events.
Proposed resolution
Since we have moved to use Symfony events, add EventInterface that extends ContextAwarePluginInterface, so events can be discovered and contexts can be extracted from them.
This approach ensures that Drupal and Symfony events can still be handled by the same event system, but when events implement this interface, modules like Rules can act on them.
Remaining tasks
- Repurpose the #2382169: [meta] Add @Event to all events defined by drupal core
@Eventannotation to a plugin annotation. - Create
EventInterface. - Move the logic from
\Drupal\Component\Plugin\PluginBaseto a trait and let the base class use the trait. - Move the logic from
\Drupal\Component\Plugin\ContextAwarePluginBaseto a trait and let the base class use the trait. - Optionally provide a base class that extends
\Symfony\Component\EventDispatcher\Eventand uses the aforementioned traits. - Provide an event plugin manager.
User interface changes
None.
API changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | drupal_2443763_3.patch | 20.57 KB | Xano |
Comments
Comment #1
XanoComment #2
XanoComment #3
XanoComment #4
dasjocool! thanks for getting this started :)
i don't feel like the right one to entirely review this, so leaving it on "needs review" with a minor copy-paste remark:
should be \Event
Comment #6
jhodgdonLooking at the issue summary... I think we shouldn't just use @Event like you are suggesting and make it be a plugin annotation, because Symfony is using it to tag event constants (which is why we adopted it also for our event constants). Also, there is already code in the API module to handle this.
So probably you should pick a different name for the annotation, like EventPlugin or something like that?
Comment #7
XanoI understand. Are your concerns technical or purely from a sanity point of view?
Comment #8
jhodgdonIt is both technical and sanity:
- Symfony established the @Event tag to tag event constants. We shouldn't make it have a different meaning, or have it mean two different things in our code base (which includes Symfony).
- The API module has special code for the @Event tag, corresponding to our decision to add this tag to our event constants. This would be easy to reverse, but we would still need to do something to gather the event constants for this page:
https://api.drupal.org/api/drupal/core!modules!system!core.api.php/group...
and since I think we still want to have the Symfony events listed there, I think we need to use @Event for it?
Comment #9
fagoWhy would events be context aware - they do not consume context but provide it? So even if it works fine, I'm not sure it makes sense to do it that way? Then, this makes events plugins what would be a drupalism. Does that give us something in return? Also, afaik symfony events are value objects - thus, there is not much purpose of an interface on them?
For Rules, it would be great if we could go with the default event base class of symfony, such that contrib modules could use them and just add an annotation to them. So the event would work even without Rules, while Rules can parse the metadata. For everything more, like event forms etc. we'd have to make optional interfaces and an alternative base class / or separate classes.
Comment #10
dasjoAdding related Rules issue: #2145343: Rules events for Drupal 8
Comment #11
fagoThis is actually already fixed - and yeah, events are plugins but using yml discovery.