What are extension conflicts?
One of the biggest problems we see as Magento matures is extension conflicts. This is where you have or more extensions effectively replacing the same core files in Magento. If you see an extension that uses the word “<rewrite>” in it’s config.xml file be aware that you may hit conflicts with other extensions.
There isn’t an easy way around extension conflicts. You could argue that better programming will work – e.g. by using Observers, taking advantage of source and backend models, writing your own MVC to sit alongside core Magento, etc. But my experience has shown that there are scenarios where you just need a re-write, especially where you are directly manipulating core functionality.
Many extensions will never have extension conflict problems. These include standard shipping extensions and payment modules. This is because the Magento architecture is such that they just plug in as an add-on – they aren’t interfering with the core code.
It’s worth pointing out that you may also get conflicts around the theme side, for instance if one extension replaces a step in one page checkout and another also does then you have isses. I’m concentrating here on PHP extension conflicts.
How do I identify extension conflicts?
There is a great extension(!) that will go through all your extensions looking for conflicts. This can be found here.
WebShopApps offer a modified version of this which works on Enterprise editions of Magento – we produced for a customer so thought may aswell release. More info here.
For theme conflicts there isnt a tool I know of to detect these, it comes down to good old concentration!
How do I resolve conflicts?
You have 3 choices for resolving conflicts:
- Merge the code from one conflicting file into another and switch off the rewrite config.xml in one
- Switch off the rewrite in one config.xml and then make the conflicting extension PHP file extend the other extension
- Use the <depends> capability to make one extension depend on another. They will then rewrite in that order
Which one you choose really does depend on how far you need to go. More often than not even though a class may conflict the actual methods within may not. In this scenario I’d go for option 3. If you have conflicting methods within classes then option 1 or 2 are applicable.
Example of option 2
So originally where you may have had something like:
class A_Extension_Model_Type_Onepage extends Mage_Checkout_Model_Type_Onepage
You would change it to:
class A_Extension_Model_Type_Onepage extends B_Extension_Model_Type_Onepage
Once you have done this you need to change extension B config.xml file commenting out the conflicting “<rewrite>” blocks that are now inheriting from A.
Example of option 3
Let’s say you have 2 extensions Foo_A and Foo_B. In the module for file Foo_B (under app/etc/modules) you would add the following:
<depends Foo_A />
Now Magento will load the extensions in this order. So in effect the Foo_B class will be loaded first, then Foo_A, then base Magento.