events.xml - Module Configuration Files

Why Events?

Magento 2 uses an event-driven architecture to allow modules to communicate without direct dependencies. Instead of Module A calling Module B directly, Module A dispatches an event, and any module can listen to it via an observer.

This decouples modules — Module A doesn't know or care who's listening.

How Events Work

Code dispatches event → Event Manager notifies observers → Observers execute their logic

The dispatch call:

$eventManager = $this->eventManager;
$eventManager->dispatch('catalog_product_save_after', ['product' => $product]);

The observer configuration in events.xml:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Event/etc/events.xsd">
    <event name="catalog_product_save_after">
        <observer name="my_observer" instance="Vendor\MyModule\Observer\ProductAfterSave"/>
    </event>
</config>

Event Naming Convention

Events follow a pattern: {entity}_{action}_{timing}

• catalog_product_save_after — after a catalog product is saved
• sales_order_place_before — before an order is placed
• customer_login — when a customer logs in

The timing suffix (_before, _after) indicates when the observer fires relative to the main action.

areas.xml

Events can be area-specific. Place events.xml in:

• etc/events.xml — global (all areas)
• etc/frontend/events.xml — frontend only
• etc/adminhtml/events.xml — admin only
• etc/crontab/events.xml — cron only

This ensures observers only run in the appropriate area.

Basic events.xml Structure

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Event/etc/events.xsd">
    <event name="catalog_product_save_after">
        <observer name="unique_observer_name"
                  instance="Vendor\Module\Observer\ProductObserver"
                  disabled="false"/>
    </event>
</config>

Observer Attributes

Multiple Observers per Event

A single event can have multiple observers:

<event name="catalog_product_save_after">
    <observer name="inventory_sync"
              instance="Vendor\Inventory\Observer\SyncInventory"/>
    <observer name="search_reindex"
              instance="Vendor\Search\Observer\ReindexProduct"/>
    <observer name="audit_log"
              instance="Vendor\Audit\Observer\LogProductChange"/>
</event>

Observers execute in the order they are loaded, which depends on module load order.

Disabling Observers

Temporarily disable an observer without removing it:

<observer name="debug_logger"
          instance="Vendor\Debug\Observer\Logger"
          disabled="true"/>

This is useful for:

• Debugging without observer side effects
• Temporarily disabling third-party observer behavior
• Performance testing with specific observers turned off

Observer Class Structure

Observers implement Magento\Framework\Event\ObserverInterface:

namespace Vendor\Module\Observer;

use Magento\Framework\Event\Observer;
use Magento\Framework\Event\ObserverInterface;

class ProductAfterSave implements ObserverInterface
{
    public function execute(Observer $observer)
    {
        $product = $observer->getEvent()->getProduct();
        // Your logic here
        return $this;
    }
}

Accessing Event Data

The Observer object provides access to data passed during dispatch:

// Dispatched with: $this->dispatch('sales_order_place_before', ['order' => $order]);

public function execute(Observer $observer)
{
    $order = $observer->getEvent()->getOrder();
    // or
    $order = $observer->getEvent()->getData('order');

    $orderId = $order->getIncrementId();
    $total = $order->getGrandTotal();
    // ... process order data
}

Observer with Dependencies

Observers can receive dependencies via constructor injection:

namespace Vendor\Module\Observer;

use Magento\Framework\Event\Observer;
use Magento\Framework\Event\ObserverInterface;
use Psr\Log\LoggerInterface;
use Vendor\Module\Service\NotificationService;

class OrderPlaced implements ObserverInterface
{
    public function __construct(
        private LoggerInterface $logger,
        private NotificationService $notificationService
    ) {}

    public function execute(Observer $observer)
    {
        $order = $observer->getEvent()->getOrder();
        $this->logger->info('Order placed: ' . $order->getIncrementId());
        $this->notificationService->notifyNewOrder($order);
        return $this;
    }
}

Common Magento Events

Always check existing events in vendor/magento/ before creating custom ones.

Dispatching Custom Events

Create your own events for other modules to observe:

namespace Vendor\Module\Service;

class WarrantyService
{
    public function __construct(
        private \Magento\Framework\Event\ManagerInterface $eventManager
    ) {}

    public function processWarranty($warranty)
    {
        // Before processing
        $this->eventManager->dispatch(
            'vendor_warranty_process_before',
            ['warranty' => $warranty]
        );

        // Process warranty
        $result = $this->doProcessing($warranty);

        // After processing
        $this->eventManager->dispatch(
            'vendor_warranty_process_after',
            ['warranty' => $warranty, 'result' => $result]
        );

        return $result;
    }
}

Best Practices

1. Use descriptive event names — vendor_module_action_timing pattern
2. Always pass relevant objects — observers need data to work with
3. Keep observers lightweight — heavy logic belongs in services
4. Don't modify dispatched objects unexpectedly — observers should not break assumptions
5. Document your events — other developers need to know what data is passed
6. Use area-specific events.xml — don't load frontend observers in admin

Performance Considerations

Every dispatched event adds overhead. Avoid dispatching events in tight loops:

// Bad: dispatches event for every product in a loop
foreach ($products as $product) {
    $this->eventManager->dispatch('product_processed', ['product' => $product]);
}

// Better: dispatch once after the loop
$this->eventManager->dispatch('products_batch_processed', ['products' => $products]);

Debugging Events

To see which events are dispatched, add logging:

// In a custom module, observe controller_action_predispatch
public function execute(Observer $observer)
{
    $action = $observer->getEvent()->getControllerAction();
    $this->logger->info('Event dispatched for: ' . get_class($action));
}

Or check the event list in the Magento codebase:

grep -r "dispatch('" vendor/magento/ --include="*.php" | head -50