By now we probably have all heard that when installing multiple Magento extensions they can clash. Essentially when both extensions try to rewrite the same core model or block only one gets through.
In an attempt to not only understand the cause but also the outcome I’ve set up a small experiment. I pitted against each other various different extensions which all tried to rewrite the same block. The below table highlights in green who “won”. The second column is always the name of the file inside app/etc/modules.
| Aa_Aa community | Aa_Aa.xml | vs. | Aa_Zz community | Aa_Zz.xml |
| Aa_Aa community | Aa_Aa.xml | vs. | Zz_Aa community | Zz_Aa.xml |
| Aa_Zz community | Aa_Zz.xml | vs. | Zz_Zz community | Zz_Zz.xml |
| Zz_Aa community | Zz_Aa.xml | vs. | Zz_Zz community | Zz_Zz.xml |
| Aa_Aa community | Aa_all.xml | vs. | Aa_Zz community | Aa_all.xml |
| Aa_Aa community | aa_aa.xml | vs. | Zz_Zz community | Zz_Zz.xml |
| Aa_Aa community | aa_aa.xml | vs. | Zz_Zz community | zz_zz.xml |
| Aa_Aa community | Aa_Aa.xml | vs. | Mage_Aa core | Mage_Aa.xml |
| Aa_Aa core | Aa_Aa.xml | vs. | Zz_Zz community | Zz_Zz.xml |
| Aa_Aa local | Aa_Aa.xml | vs. | Zz_Zz community | Zz_Zz.xml |
| Aa_Aa local | Aa_all.xml (mentioned 1st) |
vs. | Aa_Aa community | Aa_all.xml (mentioned 2nd) |
| Aa_Aa local | Aa_all.xml (mentioned 2nd) |
vs. | Aa_Aa community | Aa_all.xml (mentioned 1st) |
To sum up my findings:
1.) Extensions are loaded alphabetically
2.) The app/etc/module filename is the most influential factor
3.) It doesn’t matter if your extension is in core, community or local
4.) Mage namespace is always loaded first
The tests were run on an Ubuntu machine. Depending on how the php glob function sorts its output your mileage may vary. To see how the action unfolds live you can add Mage::log($filePath); to lib/Varien/Simplexml/Config.php around line 495 (inside the loadFile() function).
To experiment yourself you can download the files used in my experiments from here: MageBase-Extension_Winners_and_Losers.zip. You will need to delete the ones not in use / edit some of the xml files if you want to call them from a different codePool. Please let me know in the comments if you are getting different results.
Sidenote:
You can override community extensions with local overrides. Say you have a file in
app/code/community/MageBase/Test/Block/Myblock.php
if you copy it to
app/code/local/MageBase/Test/Block/Myblock.php
the local file will be used instead.
Files
Originally published on magebase.com. Copyright © 2010 Magebase - All Rights Reserved.
You can influence the module load order by usind . in the files. This will override the alphabetical load order.
Hi Vinai, thanks for stopping by and sharing the . (dot) tip. Would you mind expanding a little bit on where and how you would use it? Or were you referring to renaming app/etc/modules/ZZ_zz.xml to app/etc/modules/.ZZ_zz.xml?
Good tip about the local vs. communitry.
FYI I’m using this extension to resolve conflicts, it also suggests a resolution – its really quite good:
http://www.magentocommerce.com/magento-connect/Maison+du+Logiciel/extension/2477/magento-conflict
Hi Graham,
I had been using the same extension for a while but thanks for making me aware of the update that it now does resolution suggestions.
The XML Tags where filtered out of my previous post – sorry about that!
Here how the >depends< node can be used in the app/etc/modules/*.xml files:
<Mage_Admin>
<active>true</active>
<codePool>core</codePool>
<depends>
<Mage_Core/>
</depends>
</Mage_Admin>
This XML ensures the Mage_Core extension already is loaded when the Mage_Admin extension is loaded, even though it is behind it in alphabetical order.
I sure hope this post doesn’t loose the XML again…
Vinai
Nice tip Vinai, also, the
<depends>tag forces the extension to check the dependencies so if you develop an extension that depends on a less used core extension which may have been disabled via the modules XML, this is very useful. Same goes, if your extension should depend on another installed third party extension.For example if you disable Mage_Wishlist in the modules XML, you will get an error report saying:
Module "Mage_Rss" requires module "Mage_Wishlist. Since Mage_Rss depends on Mage_Wishlist,[…] Magento Extension Clashes – Winners and Loosers […]
[…] functionality in the save method. It works no matter how the object is saved, but is open to extension clash hell which is not appealing. (I’ve grouped these two together, because they’re mostly the […]
very helpful and informative article. keep up the good work
I liked this article a lot. I have a client that wants to load lots of extensions – the number is actually hovering around 50. Can magento extensions affect the magento performance?
@Faisal of course. Every extra code that is run will have a performance impact and depending on how well/bad the extensions are coded the penalty can be quite a lot.
I have multidomain site that is not working. Its a live site, so it very serious.
The conflict manager shows 12 conflicts (4 of them with a Fooman extension and 2 of them with Netzarbeiter extension) Please take notice that Fooman and Netzarbejder extensions do not conflict with each other.
The conflicts are mainly with extensions from Maison du logiciel (ERP), the originater of the above conflict manager. I find all this amusing since all the players are active or mentioned in the post.
In terms winners and losers, I feel I am the loser.
The other conflicts are with extension from:
Amasty (order- and custumer attributes)
Tiny Brick (True edit)
Aitoc (advanced permissions).
Actually I am very stressed and have had sleepless nights and find it very difficult to stay friends with magento.
Will some sweet magento superhero please save me and my site?
I am desperate to get my up and running again.
I have 2 test sites running to resolve the issues. One where I have installed MDN extensions first and 1 where i have installed everything except MDN extensions.
I have purchased alternative extensions from other suppliers in hope thay will not conflict.
Here is my goal:
Multi domain site (no problem)
Advanced permissions pr domain (The Aitoc extension).
Access control for B2B domain (site locked, no visible products) (Netzarbeiter ext.)
registration before access with more details: Company, VAT nr, + addtional fields (Amasty ext.)
Customized PDF invoices, shipping notes (Fooman extension)
Point of sales for the brick and mortar shop (POS ext. from Maison du Logiciel).
editable orders without destroying creditcard transaction (true edit from tiny brick).
customer can add order nr. which will be on shipping note and invoice (not solved)
one step checkout for all domains (fire checkout from templates master, looks like a winner)
And most important: NO CONFLICTS
If I get the above to work I can go from loser to winner also
Please please please write to krp@atrading.dk if you can help
[…] finally, here’s an excellent / slightly confounding exposé: http://magebase.com/magento-tutorials/magento-extension-clashes-winners-and-loosers/ This entry was posted in Uncategorized and tagged magento, php, programming, webdev. Bookmark the […]
Thanks Fooman You have just save me paying someone to sort out the problem. All I need to do was to change the load order and back in business. A simple “AA” did the trick.