The Event system is a core architectural mechanism that allows Drupal to react to actions as they happen during a request. Instead of tightly coupling logic through hooks or direct method calls, Drupal emits events and allows subscribers to respond.
Starting with Drupal 8, Drupal adopted Symfony’s EventDispatcher component. This introduced a consistent, object oriented, and decoupled way to extend behavior across core and contributed modules.
This article is part of Level 1 – Core Architecture in the 187-article series. The goal is to understand events as an architectural pattern and how they fit into Drupal’s request lifecycle.
Why Events Belong in Core Architecture
Events are not a feature level API. They define how Drupal allows cross cutting behavior without tight coupling.
Drupal core uses events to:
- React to HTTP request lifecycle stages
- Modify responses without overriding controllers
- Replace many procedural hook patterns
- Enable clean extensibility
- Coordinate complex systems such as routing, rendering, and caching
Without events, Drupal core would rely heavily on conditional logic and overrides.
What Is an Event in Drupal
An event represents something that has happened.
Examples:
- A request has been received
- A response is about to be sent
- An entity is being built
- A kernel phase has been reached
An event:
- Has a name
- Has an event object
- Is dispatched at a specific time
Events do not perform logic themselves. They notify listeners.
Event Dispatcher Overview
The Event Dispatcher is the service responsible for:
- Dispatching events
- Notifying subscribers
- Executing subscribers in priority order
Drupal exposes the dispatcher as a service.
Service ID:
- event_dispatcher
Core systems dispatch events at well defined points.
Events in the Request Lifecycle
Many important Drupal events occur during the HTTP request lifecycle.
High level flow:
- Request enters HttpKernel
- Kernel request event is dispatched
- Routing and controller resolution occur
- Kernel controller event is dispatched
- Controller executes
- Kernel response event is dispatched
- Response is sent
Events allow modules to intervene at each stage.
Kernel Events
Kernel events come from Symfony and are heavily used by Drupal.
Common kernel events:
- kernel.request
- kernel.controller
- kernel.view
- kernel.response
- kernel.exception
- kernel.terminate
These events allow deep customization without overriding controllers or routes.
Event Subscribers
An event subscriber is a service that listens to one or more events.
Subscribers are preferred over listeners because they:
- Are discoverable
- Are registered as services
- Support multiple events
- Support priorities
Creating an Event Subscriber
1. Create the Subscriber Class
namespace Drupal\my_module\EventSubscriber;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\KernelEvents;
use Symfony\Component\HttpKernel\Event\RequestEvent;
class ExampleSubscriber implements EventSubscriberInterface {
public static function getSubscribedEvents() {
return [
KernelEvents::REQUEST => ['onRequest', 100],
];
}
public function onRequest(RequestEvent $event): void {
$request = $event->getRequest();
}
}
Registering the Subscriber
Event subscribers must be registered as services.
services:
my_module.example_subscriber:
class: Drupal\my_module\EventSubscriber\ExampleSubscriber
tags:
- { name: event_subscriber }
The event_subscriber tag is required.
Event Priorities
Subscribers execute in priority order.
- Higher number runs first
- Lower number runs later
This allows fine grained control over execution order.
Incorrect priorities can cause unexpected behavior.
Custom Events
Modules can define and dispatch their own events.
Example dispatch:
use Symfony\Component\EventDispatcher\EventDispatcherInterface;
$dispatcher->dispatch($event, 'my_module.custom_event');
Custom events are useful for decoupling internal module logic.
Events vs Hooks
Drupal 7 relied heavily on hooks.
Drupal 8+ uses:
- Events for cross cutting concerns
- Hooks for entity and form lifecycle
Key difference:
- Hooks are procedural
- Events are object oriented and service based
Both still coexist in Drupal.
Common Use Cases
- Modifying responses
- Adding headers
- Redirecting requests
- Logging
- Altering render behavior
- Handling exceptions
Events should not replace business logic.
Common Mistakes
- Putting heavy logic in subscribers
- Using events where hooks are more appropriate
- Forgetting to register the service
- Incorrect event priority
- Modifying requests too late in the lifecycle
Drupal 10 and 11 Best Practices
- Keep subscribers focused
- Use dependency injection in subscribers
- Prefer subscribers over listeners
- Use kernel events sparingly
- Document custom events clearly
How Events Fit with Other Core Systems
Events integrate tightly with:
- Routing system
- Controllers
- Service container
- Render pipeline
- Cache system
Events allow these systems to communicate without tight coupling.
Acquia Exam Notes and Cheat Sheet
Key points to remember:
- Drupal uses Symfony EventDispatcher
- Event subscribers are services
- Subscribers use the event_subscriber service tag
- Kernel events are heavily tested on exams
- Events notify, they do not execute logic directly
Common exam traps:
- Confusing hooks with events
- Forgetting the event_subscriber tag
- Thinking event order is random
- Modifying responses without proper event timing
Quick recall list:
- KernelEvents::REQUEST happens early
- KernelEvents::RESPONSE happens late
- Higher priority executes first
- Subscribers can listen to multiple events
If you need to react without overriding code, events are usually the answer.
Summary
The Event system is a cornerstone of Drupal’s extensibility and request lifecycle. It enables decoupled, maintainable, and scalable architecture by allowing systems to react to actions as they occur. Mastering events is essential for understanding Drupal core behavior.