A Plugin, or Intercepter, 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. This allows you to substitute or extend the behavior of original, public methods for any class or interface.

Extensions that wish to intercept and change the behavior of a public method can create a Plugin class.

This interception approach reduces conflicts among extensions that change the behavior of the same class or method. Your Plugin class implementation changes the behavior of a class function, but it does not change the class itself. Adobe Commerce and Magento Open Source call these interceptors sequentially according to a configured sort order, so they do not conflict with one another.

Limitations

Plugins can not be used on following:

• 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

While we are all aware of the many benefits, let’s take a deeper dive into the limitations to ensure we avoid any potential issues or bugs in your Magento store

Why Can’t We Create Plugin For Final Methods?

For a Five-Year-Old Kid: You can’t create plugins for final methods because final methods are like special boxes that the person who made them wants to keep closed. They don’t want anyone to change what’s inside because it might make things messy or confusing. So, if a method is final, it means nobody can change it, keeping everything working just right!

Technical Explanation: Final methods are designed to prevent any subclass from overriding them. This ensures that the behavior of these methods remains unchanged, which helps maintain the integrity and stability of the code. Allowing plugins on final methods could lead to unexpected behaviors and conflicts, making it difficult to debug and maintain the code effectively. In short, final methods are locked to protect their functionality, and plugins can’t be applied to them.

Why Can’t We Create Plugin For Final Class?

For a Five-Year-Old Kid: You can’t create plugins for final classes because final classes are like super special toys that nobody can change. If someone tried to add new parts to the toy, it might break or stop working. So, the person who made it
says, “No one can change this toy!” This keeps it fun and safe to play with!

Technical Explanation: Final classes are defined to prevent any other classes from extending or inheriting from them. This design choice ensures that the original behavior of the class remains intact and stable. If plugins were allowed on final classes, it could lead to unpredictable results and conflicts in the code. By preventing modifications, final classes help maintain a clear and stable structure in the application.

Why Can’t We Create Plugin For Non-public Methods?

For a Five-Year-Old Kid: You can’t create plugins for non-public methods because those methods are like secret things that only the toy maker knows about. Imagine you have a special part of a toy that you’re not allowed to touch because it might break the toy. Only the person who made it should change those secret parts. If someone tried to change them, it could make the toy stop working!

Technical Explanation: Non-public methods (private and protected methods) are intended for internal use within a class and are not meant to be accessed or modified from outside. Allowing plugins on non-public methods would break encapsulation, a key principle of object-oriented programming. This could lead to unexpected behaviors and make the code harder to maintain and debug. By restricting access to these methods, we ensure that the internal workings of a class remain stable and predictable.

Why Can’t We Create Plugin For Static Methods?

For a Five-Year-Old Kid: You can’t create plugins for class methods, like static methods, because those methods are like rules for everyone to follow, not just one toy. Imagine if you had a rule that says, “Always put your toys away.” Everyone has to follow that rule, and you can’t change it for just one toy. If you tried to change the rule, it would confuse everyone and make things messy!

Technical Explanation: Static methods belong to the class itself rather than to instances of the class. The plugin system in Magento is designed to intercept instance method calls, allowing for behavior modification at the object level. Since static methods do not operate on instance data and are resolved at compile time, they cannot be intercepted by the plugin system. This design helps maintain clarity and consistency in how methods are called and ensures that the intended functionality of static methods remains unchanged.

Why Can’t we create plugin for __construct and ___destruct?

For a Five-Year-Old Kid: You can’t create plugins for __construct and __destruct because they are super special parts of a toy’s life. The __construct part is when the toy is being made, and the __destruct part is when it goes away. It’s like if you tried to change how your toy was built or how it is put away. If you changed those things, it might not work right or could break!

Technical Explanation: The __construct and __destruct methods are fundamental to the object lifecycle in object-oriented programming. The constructor is called when an object is created, and the destructor is called when it is destroyed. Allowing
plugins on these methods would disrupt the normal initialization and cleanup processes, potentially leading to instability and unpredictable behavior. The plugin system is designed for modifying behaviors of instance methods during their regular operation, not during the critical lifecycle phases of object creation and destruction.

Why Can’t We Create Plugin For Virtual Types?

For a Five-Year-Old: You can’t create plugins for virtual types because they are like pretend toys that don’t really exist on their own. Imagine if you made a special toy that’s just a name for another toy, like saying, “This is my magic version of the race car.” You can’t change the magic version because it’s not a real toy; it’s just a way to talk about the real one!

Technical Explanation: Virtual types in Adobe Commerce serve as aliases or configurations for existing classes, allowing developers to create modified versions without creating new class files. Since virtual types do not represent standalone implementations, applying plugins to them would not provide any meaningful interception of behavior. The plugin system is designed to work with concrete classes that have their own methods, ensuring that modifications are applicable and logical. Allowing plugins on virtual types could complicate the dependency injection system and lead to confusion in the class hierarchy.

Why Can’t We Create Plugin For Objects That Are Instantiated Before Magento\Framework\Interception is
Bootstrapped?

For a Five-Year-Old: You can’t create plugins for objects that are made before the special magic starts in the toy factory. It’s like if you tried to change a toy while it’s still being put together. If you change things too early, the toy might not work at all! The magic needs to be ready first so everything can work nicely together.

Technical Explanation: Objects instantiated before the Magento\Framework\Interception component is bootstrapped are created during the early stages of Magento’s initialization process, before the plugin system is ready. This means that there’s no interception infrastructure in place to modify or wrap these objects. Allowing plugins on these early-initialized objects could lead to inconsistencies and instability, as they are not part of the standard lifecycle managed by the Magento framework. By restricting plugins in this way, we ensure a stable and predictable application startup process.

Why Can’t We Create Plugin That Are Instantiated Before Objects That Implement?

example:- Magento\Framework\ObjectManager\NoninterceptableInterface

For a Five-Year-Old: You can’t create plugins for objects that are made before special objects that say, “Don’t change me!” Imagine if you had a toy that said, “I’m too special to change.” If you tried to change it, it might break. The toys that come first need to follow the rules of those special toys, so they can stay safe and work right!

Technical Explanation: Objects instantiated before those implementing Magento\Framework\ObjectManager\NoninterceptableInterface created before the interception system is fully set up. Since these Non-Interceptable objects are specifically designed to bypass the plugin mechanism, allowing plugins for early-initialized objects would undermine the design intent and create inconsistencies. This restriction helps maintain a clear structure and ensures that the integrity of the application is preserved, preventing unintended modifications to critical components.

Cheers!