Magento Plugin development is a process where the Magento 2 plugin (a technical tool) enhances code-writing capabilities. On the other hand, an Interception Plugin is a smaller extension in Magento 2 that enables the alteration of public classes or methods’ behavior by intercepting function calls.
It allows for executing code either before, after, or around the function call. Utilizing the Magento 2 Plugin Interception facilitates the modification of a class’s behavior without the necessity of directly altering the class itself.
One of the biggest advantages of Adobe Commerce (Magento) is its ability to personalize the framework as per our needs and use cases. When discussing personalization, you modify/restructure the default instance when installing Magento as per your requirement.
But how to build the best out of the default? That is when you override the core codes and execute them by your logic.
ON THIS PAGE
Why not write directly in Core Modules?
- Any modifications made directly in the Vendor folder will be cleared when updated.
- The vendor folder is not controlled [will be ignored in GIT], making it difficult to keep track of changes.
How to Modify Vendor Folder
We can override the core functionality with three techniques such as preferences, plugins, events, and observers. All three ways can be used to override the functionality but the way to use them is completely different.
Plugins
A plugin or interceptor, is a class that modifies the behavior of public class functions by intercepting a function call and running code before, after, or around that function call. It allows you to extend the behavior of original, public methods for any class or interface.
When the requirement is to introduce the logic before changing the end-result or to insert additional conditions/use cases inside the same methods then plugins can be used/created.
When to use Plugins:
- To modify the parameters of the method before its execution
- To modify the result of a function
- To manipulate or to introduce additional logic during the execution of functions.
To achieve all the three given cases above plugins can be used in three different ways before, after, and around plugins.
Declaring a Plugin:
Create a di.xml file in your module – app/code/{vendor}/{module}/etc/di.xml. Below is the syntax of the plugin declaration.
<config>
<type name="{ObservedType}">
<plugin name="{pluginName}" type="{PluginClassName}" sortOrder="1" disabled="false" />
</type>
</config>
Required Elements
- Type name: A class that the plugin observes.
- Plugin name: Name that identifies a plugin.
- Plugin type: The name of a plugin’s class or its virtual type. Use the following naming convention when you specify this element: \Vendor\Module\Plugin\<ClassName>.
Defining a Plugin
By applying the following code before, after, or around a public method, a plugin extends or modifies that method’s behavior.
Before Plugin
- Magento runs all before methods ahead of the call to an observed method. Ie, all the before methods of the specified class will run first before the actual method.
- You can use before methods to change the arguments of an observed method by returning a modified argument.
- You can also use this plugin to execute something before the method itself is executed.
- These methods must have the same name with the first letter in Capital as the observed method with ‘before’ as the prefix.
Eg: place() method should be written as beforePlace()
After Plugin
- Magento runs all after methods following the completion of the observed method. ie, all the after methods of the specified class will run only after the actual method execution is completed.
- You can use these methods to change the result of an observed method by modifying the original result and returning it at the end of the method.
- These methods must have the same name with the first letter in Capital as the observed method with ‘after’ as the prefix.
Eg: place() method should be written as afterPlace()
Around Plugin
- Magento runs the following code around methods before and after their observed methods.
- Using these methods allows you to override an observed method.
- These methods must have the same name as the observed method with ‘around’ as the prefix. Eg: place() method should be written as aroundPlace()
- Magento recommends avoiding the usage of around plugins when they are not required, as their use can prevent execution of the original function or other plugins in the queue and also increase stack traces and affect performance.
- Use after-method plugins if you require arguments for replacing or altering function results.
Example for Plugin Development
Create di.xml and declare your plugin:
app/code/Klizer/SalesOrder/etc/di.xml
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
<type name="Magento\Sales\Api\OrderManagementInterface">
<plugin name="before_place_order_operation" type="Klizer\SalesOrder\Plugin\BeforeOrderManagement"/>
<type name="Magento\Sales\Api\OrderManagementInterface">
<plugin name="after_place_order_operation" type="Klizer\SalesOrder\Plugin\AfterOrderManagement"/>
</type>
<type name="Magento\Sales\Api\OrderManagementInterface">
<plugin name="around_place_order_operation" type="Klizer\SalesOrder\Plugin\AroundOrderManagement"/>
</type>
</config>
Create BeforeOrderManagement.php in the given path to define the before plugin.
app/code/Klizer/SalesOrder/Plugin/BeforeOrderManagement.php
<?php
namespace Klizer\SalesOrder\Plugin;
use Magento\Sales\Api\Data\OrderInterface;
use Magento\Sales\Api\OrderManagementInterface;
class BeforeOrderManagement
{
public function beforePlace(
OrderManagementInterface $subject,
OrderInterface $order
): array {
// your logic here before execution
// can manipulate the order values before placing it
return [$order];
} }
- The above example overrides the place() public function of the Magento\Sales\Api\OrderManagementInterface class and manipulates the order parameter before the function executes.
- $subject is the class on which we are executing our plugin, and $order is the parameter of the original class.
Create AfterOrderManagement.php in the given path to define the after plugin.
app/code/Klizer/SalesOrder/Plugin/AfterOrderManagement.php
<?php
namespace Klizer\SalesOrder\Plugin;
use Magento\Sales\Api\Data\OrderInterface;
use Magento\Sales\Api\OrderManagementInterface;
Class AfterOrderManagement
{
public function afterPlace(
OrderManagementInterface $subject,
$result
): array {
// your logic here after execution
// proceed the operation that you want once the order is placed successfully
return $order;
} }
- The above example overrides the place() public function of the Magento\Sales\Api\OrderManagementInterface class and manipulates the result of the function once it is executed.
- $subject is the class on which we are executing our plugin, and $result is the result (return value) of the original class.
Create AroundOrderManagement.php in the given path to define the after plugin.
app/code/Klizer/SalesOrder/Plugin/AroundOrderManagement.php
<?php
namespace Klizer\SalesOrder\Plugin;
use Magento\Sales\Api\Data\OrderInterface;
use Magento\Sales\Api\OrderManagementInterface;
class AroundOrderManagement
{
public function aroundPlace(
OrderManagementInterface $subject,
\Closure $proceed
$order
): array {
// your logic here after execution
// proceed the operation that you want once the order is placed successfully
return $proceed($order);
} }
- Above is an example of an around plugin. $subject is the observed class, $proceed is the callable variable that allows executing the original function and other plugins in a queue, and $order is the argument placed in the original function.
Also Read: Create Custom API and Use CRUD Operations in Magento 2
Why Use Interceptors or Plugins in Magento 2?
- Minimize Extension Conflicts: They help reduce conflicts between extensions that modify the same class or method.
- Prevent Plugin Collisions: By using the sort order attribute, you can ensure plugins are executed in sequence, avoiding conflicts with other plugin classes.
- No System Rewrites: They eliminate the need to rewrite the system, allowing multiple modules to customize the same method.
- Modify Return Values and Arguments: You can adjust the return value or arguments of any method call on an object manager-controlled object.
Plugins Vs Observers Vs Preferences In Magento 2
In Magento 2, observers and plugins serve similar purposes but have key differences:
- Observers are specialized classes in Magento that can adjust business logic, affect overall behavior, and enhance Magento performance. They are triggered when the event manager dispatches specific events they are configured to monitor.
Here are the main distinctions between observers and plugins:
- Observers can modify both private and protected methods, whereas plugins are limited to altering public methods.
- Plugins have a defined sort order, but observers do not.
- Observers are restricted to events already present in Magento, whereas plugins offer more flexibility in extending functionality.
- Plugins are essential for altering Magento’s core functionality, such as enriching data in the order collection object, which cannot be achieved using observers.
- Due to Magento generating at least three objects in response to an event trigger, observers are generally slower compared to plugins.
Moving on to the difference between plugins and preferences in Magento 2:
- Preferences are utilized by the Object Manager to designate the default implementation of a class. They allow for overriding a class from another module to point towards a different implementation, effectively making the class global.
- Preferences specified in the di.xml file can override public or protected methods from core classes, with the default implementation determined by the preference node.
In essence:
- Preferences are used for class overriding, while plugins are employed to add functionality before, after, or around methods.
By understanding these distinctions, developers can effectively leverage the appropriate Magento 2 mechanisms for extending and customizing functionality within their projects.
Read Also: Magento Website Development
Sort Order of Plugins
- The sortOrder property from the plugin node declared in di.xml determines the plugin’s prioritization when more than one plugin is observing the same method.
- If two or more plugins have the same sortOrder value or do not specify it, the component load order declared in the sequence node from module.xml and area will define the merge sequence. Check the component load order in the app/etc/config.php file.
Limitations of Plugins
You cannot use plugins in the following cases:
- Final methods
- Final classes
- Non-public methods
- Class methods (such as static methods)
- __construct and __destruct
- Virtual types
- Objects that are instantiated before Magento\Framework\Interception is bootstrapped
- Objects that implement Magento\Framework\ObjectManager\NoninterceptableInterface
Disabling Plugins
Plugins can be disabled in a di.xml file. To disable a plugin, set the disabled parameter of the plugin declaration to true.
<type name="Klizer\SalesOrder\Plugin\AroundOrderManagement">
<plugin name="around_place_order_operation" disabled="true"/>
</type>
Above is the code that will disable the Around plugin that we created.
Wrapping up
The information provided above covers common queries that users often encounter when they begin their research on Magento 2 add-ons. Klizer stands out as a top-tier provider of multi-platform ecommerce solutions and Ecommerce web development services. Backed by experienced and certified developers, we are dedicated to delivering top-notch services aimed at optimizing your business operations effectively.
FAQs
What are some common challenges faced during Magento Plugin development?
Magento Plugin development can encounter challenges such as technical issues, compatibility issues with other custom Magento 2 extensions, and ensuring scalability and performance. Experienced developers can address these challenges effectively to deliver reliable and efficient plugin solutions.
What are the benefits of using Magento 2 Plugins in ecommerce stores?
By leveraging Magento 2 Plugins, ecommerce store owners can enhance the functionality and user experience of their online stores. Plugins allow for seamless integration of custom Magento extensions, improving site performance, user engagement, and overall customer satisfaction.
What is the purpose of an Interception Plugin in Magento 2?
An Interception Plugin is a small extension that allows for the alteration of public classes or methods’ behavior by intercepting function calls. This enables developers to execute code either before, after, or around the function call without directly modifying the class.
How can Magento 2 Plugins improve product development?
Magento 2 Plugins provide developers with the ability to modify the behavior of classes without directly changing them. This facilitates easier customization and extension of Magento’s functionality, leading to more efficient and flexible product development.
How can developers ensure the quality and reliability of Magento 2 Plugins?
Certified Magento experts and experienced developers can develop high-quality Magento 2 Plugins that meet the unique requirements of eCommerce businesses. Thorough testing, adherence to best practices, and ongoing support are essential for ensuring the quality and reliability of plugins.