Plugins are like hooks that get the input from the core without changing them. How helpful are these plugins?
As an example, let us imagine this scenario. In B2B eCommerce sites there are different types of pricing like contract pricing, discounted pricing, group pricing and more. These prices are stored in the ERP system which is integrated with Magento. With the help of plugins, it is possible to pull different price lists based on the customer group that has logged in. This is helpful because we are able to pull different types of price list without changing the core. Upgrades too will be seamless because of this.
Let us see dive in a little deeper technically to understand plugins and preferences better.
In order to modify or improve any available core functionality, we end up overriding the core classes and methods. Since editing core files are not recommended, there are several ways to override the classes. Plugins & Preferences plays a major role in overriding existing functionality in Magento 2.
Plugins have been newly introduced in Magento 2. They allow us to execute our code before, after and around any public methods from the class, our plugin hooks in. Plugins do not override the class. It instead hooks into the respective methods of the class that we want to modify the business logic. Plugins mostly avoid the conflicts that arise when overriding the classes.
Three types of plugins are
These methods execute our business logic before, after or around our observing methods. For example, in order to change the result, afterMethodName() will be used. To change parameters and to execute some logic prior, beforeMethodName() will be used. To modify both, around will be used.
Interceptors are responsible for executing the plugins in the defined manner i.e before, after or around the observing methods. Interceptor files are generated in /var/generation directory.
To dig deeper and to understand better, you can start from any generated interceptors. For example, check vargenerationMagentoCatalogModelProductInterceptor::getName() method.
This interceptor method is responsible for executing all the registered plugins on the observing class methods in the specified sort order.
For more detailed info on how to write a plugin or how plugins are executed in specified order, check Magento official documentation for plugins.
Preferences are similar to class rewrites in Magento 1. It is equivalent to saying “whenever the code asks for ‘Code A’ give ‘Code B’. Apart from this you can add or modify on top of Class B.
Preference configurations are also falls under di.xml.
Whenever any class requests an instance of Class A, it will be provided with Class B instance. Here, Class B is an overridden class of Class A. Basically, Class B comprises the business logic of Class A, which may be extended or modified.
Preferences are also responsible for Abstraction-Implementation mappings. Object Manager uses the preference to identify the default implementation class for the respective interface. In this example, MagentoFrameworkLoggerMonolog is the default implementation class for the PsrLogLoggerInterface
Both Plugins and Preferences are helpful in overriding the classes. However, Plugins are preferable than Preferences since plugins do not override the class logically instead it hooks our logic into the available classes.
So, to modify or extend any existing business logic, it is better to use the plugins. Preferences are not recommended unless or otherwise there is no other option.
Hope this article was helpful. Please let us know if you have any queries.
Get your Magento Code Audit done today. Our team of certified Magento professionals are here to guide you on how to get started.