Choose your perfect Event in Magento 2

One of the most powerful and commonly used technique for extending the standard logic in Magento is an event system. We have described this system in details in our previous article. It’s really useful for developers to know how the event system works. Moreover, choosing the most suitable event for a custom logic implementation is also very important part in development – so, in this article, we are going to review a list of the framework-level events that help understand which event will be perfect to observe in Magento 2.

Events in Magento controllers

We can execute our code before some controller has been dispatched (before calling the execute() method of a controller class). Here is a list of the events that allow to do that:

  • controller_action_predispatch – executes before each controller dispatching.
  • controller_action_predispatch_{route_name} – executes before controllers with the specific {route_name}. For example, to execute an observer before CMS pages controllers dispatching we should register our observer for the controller_action_predispatch_cms event. The controllers route names can be found in extension’s routes.xml file for an area that you are interested in.
  • controller_action_predispatch_{full_action_name} – executes before each controller with the specific {full_action_name}. The full action name consists of the route name, controller name and action name followed by the underscore character. For example, the full action name of home page is cms_index_index. To execute an observer before the home page controller dispatching we should register our observer to controller_action_predispatch_cms_index_index event.

Also, we can execute our code after controller has been dispatched. Below check set of events for this purpose:

  • controller_action_postdispatch_{full_action_name} – executes after a controller with specific {full_action_name}.
  • controller_action_postdispatch_{route_name} – executes after each controller with specific {route_name}.
  • controller_action_postdispatch – executes after each controller dispatching.

Events in rendering system

In Magento 2 there are many events that give an ability to execute observers upon different parts of a page rendering flow:

  • layout_load_before – executes before the layout of current page is loaded. From this point we can get an access to the following objects:
    • $observer->getFullActionName() – the full name of the current action.
    • $observer->getLayout() – get layout of the current page.
  • layout_generate_blocks_before – executes after layout is loaded and before the layout blocks are generated. Here we can also get an access to the same objects that are mentioned for the previous event.
  • layout_generate_blocks_after – executes after blocks from the layout of the current page are generated.
  • core_layout_render_element – executes after a block is rendered. Here is a list of available objects in this event:
    1. $observer->getElementName() – gets the event block’s name.
    2. $observer->getLayout() – gets current page’s layout.
    3. $observer->getTransport() – gets an instance of the Magento\Framework\DataObject class that contains the rendered elements.
  • view_block_abstract_to_html_before – executes before a block is sent to output. Here is a list of available objects of this event:
    • $observer->getBlock() – gets an event block.
  • layout_render_before_{full_action_name} – executes before the page layout with specific {full_action_name} is rendered.
  • layout_render_before – executes before each page layout is rendered.

    • Events in models

    Usually, models extend the Magento\Framework\Model\AbstractModel class. It gives an ability to observe a predefined set of model events. And the model should have AbstractModel::_eventPrefix attribute specified for observing events of a specific model. The attribute’s value equals to “core_abstract” by default.

    Also, in models we have AbstractModel::_eventObject attribute that gives an ability to specify a name of the current model’s instance for different model-specific events.

    Review a list of the global models events:

    • model_load_before – executes before each model is loaded. Here we can get an access to the following event’s data:
      • $observer->getField() – gets currently processed model’s field name.
      • $observer->getValue() – gets currently processed model’s field value.
    • model_load_after – executes after each model loading.
    • model_save_before – executes before each model saving.
    • model_save_after – executes after each model saving.
    • clean_cache_by_tags – executes after model related cache tags are cleaned.
    • model_delete_before – executes before model is deleted.
    • model_delete_after – executes after model is deleted.
    • model_save_commit_after – executes after the models saving transaction is committed.
    • model_delete_commit_after – executes after the models saving transaction commit is deleted.

    In the mentioned events, we can get an access to the following data:

    $observer->getObject() // get the current model instance

    Now, let’s check the model-specific events:

    • {event_prefix}_load_before – executes before model with {event_prefix} is loaded.
    • {event_prefix}_load_after – executes after model with {event_prefix} is loaded.
    • {event_prefix}_save_before – executes before model with {event_prefix} is saved.
    • {event_prefix}_save_after – executes after model with {event_prefix} is saved.
    • {event_prefix}_delete_before – executes before model with {event_prefix} is deleted.
    • {event_prefix}_delete_after – executes after model with {event_prefix} is deleted.
    • {event_prefix}_save_commit_after – executes after model’s data with {event_prefix} is committed.
    • {event_prefix}_delete_commit_after – executes after model’s data commit with {event_prefix} is deleted.
    • {event_prefix}_clear – executes when a model object is being prepared for correct deleting by the garbage collector.

    Furthermore, we can get an access to the following event data from each of them:

    • $observer->getDataObject() – gets the current model reference.
    • $observer->get{event_object} – gets an event object for the current model.

    Events in collections

    In Magento we have an ability to execute custom code upon a collection loading flow. We can use the below list of the events for this purpose:

    • core_collection_abstract_load_before – executes before each collection loading.
    • core_collection_abstract_load_after – executes after each collection loading.

    From the observers for these events, we can access the current collection using this way:

    $observer->getCollection()

    In the similar way as for models, we can specify $_eventPrefix and $_eventObject fields of the AbstractCollection class. These properties were created for the same purposes as in AbstractModel – help in observers implementation for the specific collection by the following events:

    • {event_prefix}_load_before – executes before collection with {event_prefix}.
    • {event_prefix}_load_after – executes after collection with {event_prefix} is loaded.

    And then from the collection-specific events we can get an access to the current collection that depends on AbstractCollection::_eventObject property:

    $observer->get{event_object}()

    For example, if AbstractCollection::_eventObject is equal to “my_collection”, we can get an access to the current collection using the code below:

    $observer->getMyCollection()

    Well then, we have reviewed 35 framework-level events and their use cases. We hope that this article someday will help you find a perfect event for your implementations. Feel free to leave your ideas in the comments below.

    Read more: