Skip to main content

Plugins SortOrder and Limitations in Magento2

Plugins SortOrder and Limitations in Magento2

In the previous blog, we’ve discussed how to declare plugins and what are the types of plugins. 

In this blog, we will focus on plugin sort order and limitations of plugins in Magento2. 

Plugin SortOrder

Plugin sort order is used to decide the priority of executions when multiple plugins are listening to the same method. And if more than one plugin is listening to the same method but doesn’t add sort order or maybe the same sort order then the execution will be decided on component load order by the sequence tag of module.xml and area of plugins.   

Sort order works in lower to higher when used in before method and higher to lower when works in after methods. Around plugins execute before the before plugin when around plugin have lowest sort order then before plugin. 

Let’s take an example to understand this:- 

Order to execute plugins - 

  1. Before plugins 

  2. Around plugins chaining 

  3. After plugins 



 

Plugin1

Plugin2

Plugin3

sortOrder

10

20

30

before

beforeDispatch()

beforeDispatch()

beforeDispatch()

around

 

aroundDispatch()

aroundDispatch()

after

afterDispatch()

afterDispatch()

afterDispatch()

  • Before plugin with the lowest sort order executes first,
  • Then the around plugin with the lowest sort order,

  • Then before plugin from lowest to highest,

  • And same with the around plugin, 

  • After completing the chain of before and around plugin executions,

  • After plugins execute as highest to lowest sort order. 


In the above process plugins will be executed like :- 


  1. Plugin1 : beforeMethod()

 

Because it has the lowest sort order in before plugin.  


  1. Plugin2 :beforeMethod()


After the Plugin1, Plugin2 before method has lowest sort order. 


  1. Plugin2: aroundMethod()

Plugin2 around method has sortorder 20 which is lowest from Plugin3 before method so this method will execute first. 


  1. Plugin3 : beforeMethod()


Executes as lowest to highest sort order in before plugins.


  1. Plugin3 : aroundMethod()


Plugin3 around method as lowest to highest sort order in around methods. 


If now aroundMethod is calling the callable method then the original callable method will be executed first and if aroundMethod is not calling the callable  then after plugins will execute as highest to lowest sort order. 


  1. Action : OriginalMethod() (If callable exist)

                    Else 

Plugin3 : afterMethod()


Because afterMethods executes as highest to lowest sort order so Plugin3 has highest sort order. 


  1. Plugin2 : afterMethod()


Execute as highest to lowest sort order in after plugins. 


  1. Plugin1 : afterMethod()


Execute as highest to lowest sort order in after plugins. 


Plugin Limitations 


Plugins cannot be used on following :- 


  • Final methods

  • Final classes

  • Non-public methods

  • Class methods (such as static methods)

  • __construct

  • Virtual types

  • Objects that are instantiated before Magento\Framework\Interception is bootstrapped

That’s all! I hope this tutorial helps you to understand plugin sortorder and limitations well. 






Comments

Popular posts from this blog

Magento2 CLI

Magento2 CLI  Back after a long break! Starting again with this blog because I found it the most important to understand if we are doing the magento development as magento commands play the most important role here. It really helps us a lot if we know that lĺwhich command we need to run on this action or after any changes.  Let’s start with the basic commands that we use a lot of times during our development.  cache:clean or cache:flush php bin/magento cache:clean Or  php bin/magento  cache:flush Both of these commands are used to clean the cache of Magento2 so that your new changes can be reflected to your store.  Using cache:clean it deletes all the enabled cache of magento2. Disabled caches are not affected with cache:clean but if you are doing cache:flush then it purges all the cache storage of magento wherever its enabled or disabled or it even deletes all the third party cache along with the magento cache.  If you are doing any changes in admin configuration, layout xml file, u

How EAV Model Works in Magento2?

                         How EAV Model Works in Magento2?  EAV Model stands for Entity-Attribute-Value is a very important concept of magento2 to understand how the attributes of entities are stored and works in magento2.  EAV Model is described as :-  Entity - Entity refers to the data items such as customers,orders,catalog,category etc.  Attribute - Attributes of the entities like price is an attribute of the product(entity) is referred here is an attribute. Value - A value of the attribute as $20 is a value for price attribute is referred here is a value.  Use of EAV Model EAV(Entity-Attribute-Value) is used to create new attributes of entities such as products, categories etc. With the use of eav models we don’t need to change the structure of the core tables of attributes thus it increases the scalability of the system.  Let’s have a look at how eav works in Magento2 -  Eav model used many several tables to store the data of the entity attributes. The top most table for the e

Plugins in Magento2

Plugins in Magento2 Unlike Magento1, Magento2 introduces a whole new concept of Plugins or Interceptor. A plugin or interceptor is used to change the behaviour of the method of any class without affecting the actual class. This is a very powerful way to customize the core classes of Magento2.  Plugins are one of the customization methods in Magento2. In plugins, there is a design pattern called “Interception” which means “Inserting code dynamically without changing original class behaviour” and this is what plugins exactly do in Magento2. Plugins modify the behaviour of a plugin class function by intercepting a function call and adding code before, after and around that function’s call.  Plugins are used with public methods only.  Declaring Plugins To declare plugins in Magento2, we have to create di.xml according to the specific area.  Create di.xml inside Vendor/Module/etc for global.   < config >     < type name = "{ObservedType}" >       < plugin name