Best Practices for Magento Debugging
20 likes11,373 views
The document outlines best practices for debugging and configuring Magento development environments, including enabling developer mode, using Xdebug for error backtraces, and tips for logging errors and monitoring log files. It provides guidance on troubleshooting common development issues, handling SQL errors, and debugging custom modules or third-party modules. Additionally, it discusses configuring exception handlers and tips for examining shipping method errors and using debugging tools like Eclipse and Zend Studio.
Best Practices for Magento Debugging
- 2. OVERVIEW • Environment configuration • Common Magento development problems and how to approach them • Using the right tools for the job: PHP debugging and profiling with Magento/ Eclipse I won’t be covering everything in minute detail. At the end of the presentation, I’ll provide a link to slideshow and link to blog posts explaining different sections in more detail.
- 4. AUTO-SET DEVELOPER MODE • Enable Mage::isDeveloperMode() on development and staging environments • Preferably, set the MAGE_IS_DEVELOPER_MODE via .htaccess file or server configuration. Example: • Alternatively, set the developer mode using conditional code in index.php. Example:
- 5. SHOW ALL ERRORS IN DEVELOPER MODE • Ensure that all errors are displayed when in developer mode:
- 6. WHY DETAILED ERROR AND EXCEPTION BACKTRACES ROCK • You can see all arguments passed to functions in the call stack • You can see all local variables at the location of the error/exception • You can customize xdebug to create links that allow you to jump to a specific line/ file in your favorite editor HOW DO I GET SUCH DETAIL? • Install Xdebug (an Apache module) on your development/staging servers • My recommended xdebug configuration values: http://bit.ly/gspkIK
- 7. Before
- 8. After Links to the location the file Fully expanded argument variables Local variables
- 9. HACK MAGENTO (SAFELY) TO ENABLE BACKTRACES • Modify the Mage::run() method to not catch exceptions if developer mode is on (blog post explaining how to make this modification: http://bit.ly/feJE2y)
- 10. USING MAGE::LOG TO LOG DEBUG DATA • Mage::log() allows you to log code to either the default var/logs/system.log file, or a custom file. • Mage::log(‘This is a custom message’, Zend_Log::INFO, ‘customfile.log’, true) • Pass Varien_Debug::backtrace(true, false) to Mage::log() to log a backtrace. This is helpful if you want to know what code is calling a specific section of code. This can be helpful when testing methods that are difficult to use a debugger on, such as Paypal code. • Log the attributes of a model using Mage::log($model->debug()) The debug() method prevents Mage::log from logging the dump of all of the nested objects • You can monitor the contents of the log files using: • Command-line: tail –f <file_name> • Mac: Console.app (Must have developer tools installed) • Windows: Baretail (http://www.baremetalsoft.com/baretail/ )
- 11. CONFIGURE EXCEPTION HANDLER TO EMAIL REPORTS • When a user of a live site encounters an error, Magento shows them a form (NOTE: on what conditions will Magento show a form vs a generic exception page) allowing them to submit the details that happened that caused that error. That exception will also be logged to var/log/exceptions.log • If you want to be notified about all exceptions via email, copy errors/ local.xml.template to errors/local.xml and configure it to send reports via email and enter your email.
- 13. GET TO THE BOTTOM OF THE SQLSTATE ERRORS • What do you do when Magento throws a generic SQLSTATE database error? • An “Integrity contraint violation”, or some other SQLSTATE error, doesn’t tell you much, unless you can view the error and the backtrace • Especially relevant for errors encountered in the admin panel • We have to hack two files (these hacks are harmless)…
- 14. GET TO THE BOTTOM OF THE SQLSTATE ERRORS Modify Zend_Db_Adapter_Pdo_Abstract to get backtraces for single queries
- 15. GET TO THE BOTTOM OF THE SQLSTATE ERRORS Modify Zend_Db_Statement_Pdo to get backtraces for transactional query errors
- 16. THINGS TO CHECK WHEN A CUSTOM MODULE DOESN’T LOAD Problem: You’ve created a basic skeleton of a module with a module xml file, config.xml file, layout file, and block, but the module isn’t showing. Here are some quick steps you can take to debug the issue: 1. Ensure that the module’s xml file in app/etc/modules/ is being loaded. Tip: Add an error to the module’s config file and then reload the page. If the page throws an error, the file is being loaded. 2. Ensure that the module’s config.xml file is being loaded using same technique above 3. Ensure that the layout file is getting loaded using same technique above 4. Ensure that caching is disabled and remove the cache directory (var/cache) manually if it isn’t 5. If you’re not working on a case-sensitive partition, ensure the cases of your class names and xml references are correct.
- 17. DEBUGGING BY PROCESS OF ELIMINATION Problem: You are working on a site with 5 third-party modules and 4 custom modules. You’ve heavily modified the way that products work in the system. You run into an error where products aren’t saving from the admin. • 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
- 18. ESOTERIC ERROR MESSAGE Problem: Your client tries to place an order in the admin. When doing so, they get a generic error message about the product stock quantity not being able to be saved (NOTE: replace with real example, preferably one that can be recreated easily). You check the error and exception logs, but you have nothing to work with. What do you do? • Take the error message and search the Magento codebase for the error. • Once you locate the error, set a breakpoint and debug the error from there.
- 19. 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? • NOTE: Fill in details • 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
- 21. QUICK TIPS: DEBUGGING SHIPPING METHOD RATES • Problem: Your shipping rates are configured like they should be, but when you add certain items to your cart, the shipping section is showing an error message like “No shipping rates found”. Magento provides no easy way to see what errors the carriers are returning, and so these errors can be hard to debug. • Modify the classes in app/code/core/Mage/Usa/Model/Shipping/Carrier/ <carrier_name>.php to log XML returned from carrier • UPS: Filename, line number • Fedex: Filename, line number • USPS: Filename, line number • Once you have the full XML response data from the carrier, you can determine the cause of the error. • Common causes: • The products in the cart have 0 weight • NOTE: Add additional items…
- 22. DON’T BE AFRAID TO HACK - TEMPORARILY • Find the source of the problem • Set a debug point, or add a Mage::log() function to log the important data
- 24. OVERVIEW OF ECLIPSE DEBUGGING • Breakpoints / conditional breakpoints • Stepping through code • Inspecting variables in local scope (especially relevant are the _data and _items arrays on models and collections) • Jumping back through the Call Stack to view variables in scope at that point in the stack • Watch expressions • Tip: Run code in current context using “Inspect”
- 25. BREAKPOINTS • Purposes • Identify that Magento is hitting a certain section of code (can also use Mage::log(__METHOD__ . ‘ ‘ . __LINE); for that) • Determine what a certain section of code does • Conditional breakpoints SWITCH TO ECLIPSE FOR WALKTHROUGH
- 26. INSPECTING VARIABLES • Inspecting variables in local scope • Many classes in Magento have recursive properties, so if you expand all properties, you’ll get an infinite nesting • The _data array stores all of the data present in a model • The _items array contains all of the items loaded in a collection SWITCH TO ECLIPSE FOR WALKTHROUGH
- 27. CALL STACK • Shows all code that has been run up to that point • Clicking to previous lines in the call stack changes the variables in the local scope SWITCH TO ECLIPSE FOR WALKTHROUGH
- 28. WATCH EXPRESSIONS • See what a certain expression would return if it was being run in the code at that point. Example: $product->getStatus(); • Run code in current context using “Inspect” • Use Ctl+Shift+I to run code in local scope SWITCH TO ECLIPSE FOR WALKTHROUGH
- 29. QUESTIONS?
- 30. ZEND STUDIO-ONLY FEATURES • Comparison between PDT and Zend Studio • For debugging, the biggest advantages of Zend Studio are: • Profiling • Tight Zend Server integration (helpful if Magento site is running on Zend Server in production) SWITCH TO Zend Studio FOR WALKTHROUGH