It might happen that Magento behaviour is different under the regular Magento frontend than under the Joomla! frontend. This might be caused a MageBridge bug, but if it can not be replayed on any other testing environment, it might also be related to a third party Magento extension. This guide shows you how to debug conflicts between MageBridge and other Magento extensions.
The basic logic when debugging MageBridge compatibility with other Magento extensions, is that if the problem occurs with a specific Magento module enabled, the problem should NOT occur when that specific Magento module is disabled. To test for this, the Magento module needs to be disabled.
The Magento backend has an option in the System Configuration under the Advanced tab to disable the modules output, but disabling the output of an extension is very different from disabling the extension itself. We advise you to disable the extension entirely for proper testing, for which the procedure is explained in this guide.
Before modifying anything in Magento, make sure you have a proper backup available - of both the files as the database -, and that you know how to restore from that backup. Make sure that - when things fail - you know which steps you have take to undo the previous steps.
Also, disable Magento caching entirely. It's best to remove all files from the Magento folder var/cache manually.
Enable all debugging to know what is going on. This means that you have access to the Apache errorlogs, and have made sure that PHP Fatal Errors are logged there. Also, enable debugging in Magento - both the exception-log as the system-log should be enabled.
Within the folder app/etc/modules you will find a XML-defintiion of each module. For instance, MageBridge is initialized here through the file Yireo_MageBridge.xml. If you remove that file, the MageBridge extension will never be initialized and therefor in effect it is disabled.
To troubleshoot which extension is conflicting with MageBridge, move a specific XML-file to another location (for instance, a temporary folder app/etc/modules/old) and see whether this fixes things. In allmost all cases, you should not remove the files starting with Mage_ - these are core-files.
Be prepated that this kind of troubleshooting might also crash your site. For instance, if you disable module X, but your Magento theme makes calls to that module X, your frontend will crash. The same might occur in the backend, when the backend has requirements for that module (product-attributes, payment-methods, etcetera).
To restore the functionality of that module, placing back the XML-file in app/etc/modules should be sufficient in most cases. If not, restore from your backup. Because of the risks, it is highly recommended to do this only on testing environments, and not on production environments.
When you have a problem that is harder to replicate (for instance, a problem in the Magento checkout) it might be too time-consuming to test every single Magento module one-by-one. Instead, you might want to disable - let's say - 20 Magento modules. If your problem is solved without these 20 modules, you know that one of these 20 modules is to blame. Activate half of these modules to see which half is actually causing the problem, and repeat this process until you have found the conflicting extension.