While you're building a Magento shop with many third party modules, you might run into weird problems that could be caused by those third party extensions, or a combination of modules. To troubleshoot issues like that, it is useful to temporarily disable modules to see which modules gives you trouble. But disabling modules could be done in multiple ways.
By navigating in the Magento backend to System > Configuration > Advanced > Disable modules output you can easily disable certain modules. You can even select the scope of the configuration (in the top left of the page) and there for disable specific modules only for specific Store Views. This works out fine in most of the cases, and this is actually the preferred way of disabling a module.
But there's a catch, and that catch can only be explained by looking at how Magento is initialized: It first reads a lot of XML-files and interprets them, but only after that it knows which MySQL database to use. So first the XML-files are read, and the database configuration is read. But because all settings are stored in the database, some module XML is still included - even if the module is disabled through the Magento backend.
More performant (but not more useful, and a bit difficult) is it to disable the module right in its core: In XML. In the directory app/etc/modules you can find a bunch of XML-files. While the Magento core-modules are bundled in just a couple of files, in most cases you will find per third party module also a separate XML-file. When you open up the XML-file of for instance our MageBridge extension, you will find the following:
<config> <modules> <Yireo_MageBridge> <active>true</active> <codePool>community</codePool> <depends> <Mage_Api /> </depends> </Yireo_MageBridge> </modules> </config>
Now to disable this module, you would change the active-tag from true to false.
Remember to flush the Magento cache afterwards.
But this might not solve your problem. If some module is placed in the app/code/local directory it might be overriding a Magento core-class directly, without the use of XML-files. To bypass this problem, you need to temporarily disable all local modules.
This can be done by opening up the file app/etc/local.xml in which you should change the disable_local_modules-tag to true.
This should allow you to troubleshoot the problem. Of course there are many more things to troubleshoot when dealing with serious problems, but at least this is a start.