DEBUGGING BY PROCESS OF ELIMINATION
Problem: You are working on a site with 5 third-party modules and 4 custom modules. You’ve for example heavily modified the way that pricing works in the system. You run into an error where products aren’t showing correct pricing anymore.
You can either:
• Start digging into the code to determine the cause of the issue, OR:
• Isolate the cause of the issue by progressively disabling the modules on the site until you identify which module is causing the error.
Most of the time, this is the better approach.
• After you identify the violating module, start commenting out different sections of the config.xml file until the issue goes away.
• After you identify the bad class/file, go through the code, progressively eliminating different sections until you narrow it down to a line of code
DISABLING A MODULE VS DISABLING BLOCK OUTPUT
Disabling block output explained
• You can access this option in System > Configuration > Advanced
• Disabling a module’s block output makes the XXXX class not output the contents of any blocks in that module
Why would you disable a modules block output as opposed to disabling it?
• Core Magento classes that are commonly disabled
• Mage_Poll, Mage_Review, Mage_Tag, Mage_Wishlist (NOTE: Need to verify that there are no issues disabling these module‘s block output)
• Disabling a module
• Change the <active>true</active> to false
• Remove the module’s config file from app/etc/modules