Change record status: 
Introduced in branch: 
2.0.x
Introduced in version: 
2.0.0
Description: 

In ECA 1, implementing an ECA event plugin required several components:

  • The ECA Event Plugin
  • The Event
  • The Event Subscriber

Several tasks have been spread across those 3 components, e.g. the configuration, the appliance check, the token data provider, etc. This was particularly confusing for events that are provided by other modules or even Drupal core because there ECA could add some of its extras into the event class and needed to work around that.

For ECA 2 this gets much simpler:

  • Nothing needs to be added to the Event any more
  • Event Subscribers are no longer required
  • Configuration, appliance checks and token data provider all go into the ECA Event Plugin

So, from now on, there is only the ECA event plugin that has to be provided, maybe also the event itself if that doesn't exist already.

Developing new ECA event plugins is a very straightforward process now.

Migrating ECA Event Plugins from ECA 1

  1. Delete the event subscriber, unless the integration requires it for other subscriptions. If the event subscriber provided token data as well, that needs to be moved into the ECA Event Plugin.
  2. Remove appliance checks from events if there are any. They get moved to the ECA Event Plugin.
  3. Remove token data provider from events if there are any. They also get moved to the ECA Event Plugin.
  4. Implement appliance checks and token data provider in ECA Event Plugins by implementing methods like EventBase::generateWildcard, EventBase::appliesForWildcard, EventBase::getData, EventBase::hasData and EventBase::buildEventData

So, almost everything gets moved from Events and EventSubscribers into the ECA Event Plugins. And for details, the many existing plugins are the best reference to see on how to implement those methods, that are needed in any particular case.

Impacts: 
Module developers
Site templates, recipes and distribution developers