I think I don't need to explain in detail about plugins, preferences and observers. These are types of overriding or extending default magento functionality.

While overriding any magento core method/function, you must think first about which way to prefer. Whether it is plugin, observer or preferences. Observers can work only in some specific cases while in most of the cases you need to choose between plugin and preference.

Many times, I enters into the situation where I need to choose between around plugin and preference. You can imagine such case in that before and after plugins can't work for you. So this is really hard decision for me to choose between these two.

If you choose around plugin then it will call the method twice before and after the method execution. It means it may execute all code written in that method twice.

If you choose preference then your custom code or say custom feature might stop work if there is any change comes into the core method in future magento upgrade versions.

So this is really hard decision for me to choose the right approach. I am not sure how many of you had faced such situation but I would like to know about the best option to choose from this.

You can share your views with pros and cons.


2 Answers 2


In general I would rank each of the customization approaches in this order, best option being first:


  1. Patches
  2. Plugins / Interceptors
  3. Observers
  4. Preferences



I wouldn't officially say this is the best approach. It's conditional. There are cases where a modification you are making is just fixing a bug with Magento or a third party module. At least with non Magento Cloud sites, you can install the cweagans/composer-patches composer package (see link below), to gain the ability to patch composer installed modules pretty easily:

Github - cweagans/composer-patches


  • Instead of creating an entire module with a preference/plugin to fix something, you could just create a patch if you know that the change should be there anyway
  • If/when the original module vendor applies the fix and your patch no longer applies, it can be skipped from being applied automatically, or fail loudly in a development environment so you can address properly


  • If a vendor changes the files you are patching but does not introduce your same fix, your patch could no longer be applied

Plugins / Interceptors


  • Multiple modules can declare plugins without conflicting/short-circuiting other module plugins (with the exception of around plugins, which can short-circuit)
  • Since they only operate before/after/around the original methods they are declared on (Wikipedia - Aspect-oriented programming), you have a much smaller footprint to deal with when it comes to upgrades. In contrast to a preference + full override of a method, you don't have to compare the insides of a method override with the original for every Magento upgrade, diffing your customizations with changes in the upgrade.


  • Limited to public methods, which depends on Magento and other third party vendors declaring methods public.



  • If an event is dispatched in the middle of a large method that you would have to otherwise override to customize, the observer would enable you to have a smaller customization footprint


  • Introduces hidden dependencies. Allows modules that haven't declared hard dependencies on the module dispatching the event to cause non-obvious side effects
  • As a general rule, observers shouldn't change the data that was attached to the event being dispatched. This makes the code REALLY hard to reason about. I'm sure this probably happens in core code, but it's frowned upon.



  • Necessary when methods needing overriding are marked protected, private, final
  • Hmm...can't think of more pros


  • Equivalent to an override/rewrite that you might see in Magento 1. If multiple modules are installed that have a preference on the same class, whichever module loads last is going to win, effectively short-circuiting the preferences that other modules had. You will run into conflicts quicker with this approach if you plan to install a lot of modules
  • If a preference is used, and the full contents of original class methods are overridden, or worse, the whole class contents are overridden, you will run into upgrade issues a lot quicker, since the contents of the methods could change between versions of Magento

Let me put two cents in.


Actually, observers should not be used to modify event data somehow:

14.1. All values (including objects) passed to an event MUST NOT be modified in the event observer. Instead, plugins SHOULD BE used for modifying the input or output of a function.


So comparing observers with other customisation ways is not correct.


Plugins shouldn't be used when you have to rewrite a public method in all cases but preference should.

4.1. Around-plugins SHOULD only be used when behavior of an original method is supposed to be substituted in certain scenarios.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.