Drupal  8.2.6
API documentation

Overview of event dispatch and subscribing

Introduction and terminology

Events are part of the Symfony framework: they allow for different components of the system to interact and communicate with each other. Each event has a unique string name. One system component dispatches the event at an appropriate time; many events are dispatched by Drupal core and the Symfony framework in every request. Other system components can register as event subscribers; when an event is dispatched, a method is called on each registered subscriber, allowing each one to react. For more on the general concept of events, see http://symfony.com/doc/current/components/event_dispatcher/introduction.html

Dispatching events

To dispatch an event, call the ::dispatch() method on the 'event_dispatcher' service (see the Services topic for more information about how to interact with services). The first argument is the unique event name, which you should normally define as a constant in a separate static class (see and for examples). The second argument is a object; normally you will need to extend this class, so that your event class can provide data to the event subscribers.

Registering event subscribers

Here are the steps to register an event subscriber:

Note that in your getSubscribedEvents() method, you can optionally set the priority of your event subscriber (see terminate example above). Event subscribers with higher priority numbers get executed first; the default priority is zero. If two event subscribers for the same event have the same priority, the one defined in a module with a lower module weight will fire first. Subscribers defined in the same services file are fired in definition order. If order matters defining a priority is strongly advised instead of relying on these two tie breaker rules as they might change in a minor release.