Magento event system is one of the most powerful and commonly used techniques for extending the standard back-end logic. What’s more, choosing the right event for a custom logic interpretation is an essential part of development.
Even though event systems in Magento 1 and Magento 2 share similarities, developers will find it useful to understand how the Magento 2 event system operates specifically. Read on to see a list of the framework-level events that help understand which event will be perfect to monitor and track 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). Below is a list of events enabling you to do so:
- controller_action_predispatch — executes before each controller dispatching.
- controller_action_predispatch_{route_name} — executes before controllers with a 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.
We can also execute our code after the controller has been dispatched. Check our a set of events for this purpose:
- controller_action_postdispatch_{full_action_name} — executes after a controller with a specific {full_action_name}.
- controller_action_postdispatch_{route_name} — executes after each controller with a specific {route_name}.
- controller_action_postdispatch — executes after each controller dispatching.
Events in rendering system
In Magento 2, there are many events that allow executing observers in different parts of a page rendering flow:
- layout_load_before — executes before the layout of a current page is loaded. From this standpoint, 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 access to the objects mentioned in 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:
- $observer->getElementName() — gets the event block’s name.
- $observer->getLayout() — gets current page layout.
- $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. This way, developers can observe a predefined set of model events, all of which must have an AbstractModel::_eventPrefix attribute specified for observing events of a specific model. The attribute value equals to “core_abstract” by default.
Models also an have AbstractModel::_eventObject attribute that allows us to specify the name of the current model instance for different model-specific events.
Review the list of global models events:
- model_load_before — executes before each model is loaded. Here, we can get access to the following event data:
- $observer->getField() — gets the field name of the currently processed model.
- $observer->getValue() — gets the field value of the currently processed model.
- model_load_after — executes after each model loading.
- model_save_before — executes before each model is saved.
- model_save_after — executes after each model is saved.
- clean_cache_by_tags — executes after a model related cache tags are cleaned.
- model_delete_before — executes before a model is deleted.
- model_delete_after – executes after a 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 some model-specific events:
- {event_prefix}_load_before — executes before the model with {event_prefix} is loaded.
- {event_prefix}_load_after — executes after the model with {event_prefix} is loaded.
- {event_prefix}_save_before — executes before the model with {event_prefix} is saved.
- {event_prefix}_save_after — executes after the model with {event_prefix} is saved.
- {event_prefix}_delete_before — executes before the model with {event_prefix} is deleted.
- {event_prefix}_delete_after — executes after the model with {event_prefix} is deleted.
- {event_prefix}_save_commit_after — executes after the model data with {event_prefix} is committed.
- {event_prefix}_delete_commit_after — executes after the model 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 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 can execute custom code upon a collection loading flow. Here’s the 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.
Using observers for these events, we can access the current collection using this way:
$observer->getCollection()
Similarly, we can specify $_eventPrefix and $_eventObject fields of the AbstractCollection class. These properties were created for the same purposes as the ones in AbstractModel: to help developers implement observers for the specific collection. Here are the events related to this:
- {event_prefix}_load_before — executes before the collection with {event_prefix}.
- {event_prefix}_load_after — executes after collection with {event_prefix} is loaded.
Then, from the collection-specific events, we can access the current collection that depends on the AbstractCollection::_eventObject property:
$observer->get{event_object}()
For example, if AbstractCollection::_eventObject equals “my_collection”, we can get access to the current collection using the code below:
$observer->getMyCollection()
Conclusion
As we have reviewed 35 framework-level events and their use cases, we hope this article will help you find a perfect event for your custom implementations. Feel free to leave your ideas in the comments below and reach out if you’re looking to hire an expert Magento developer.
Read more:
