You are hereBlogs / dave's blog / Debugging Drupal
Debugging Drupal
These are my notes from a talk given by Rich Yumul at DrupalCamp LA 2010. Rich is at Sage Tree Solutions.
Steps for Debugging
- Reproduce the bug in the wild
- Reproduce the bug in your development environment
- Identify where it's failling
- Identify why it's failing
- SQUASH THAT BUG
Tools
- Local dev/testing environment, MAMP or WAMP
- IDE - Netbeans or Eclipse
- XDebug/Zend Debugger
- Firebug/Webkit/IE Developer Toolbar
- tail -f, grep, less, vim, ssh
Where to check the Values
Browser - Primarily, I use FireBug
Drupal - In Drupal, there are places you can look to find more information about each bug, such as Watchdog
Server - In the actual code, you'll want to use a debugger.
The Usual Suspects
- PHP Error (from the Server) - the plain text messages you see at the top of the page when something fails
- $messages variable (from Drupal) - the notices you see at the top of the screen
- Watchdog (from Drupal) - accessible at admin/reports
- Apache's error_log (from the Server)
- php_error_log (from the Server)
- Firebug console (from the Browser)
Browser Tool Comparison
On the browser side, Firebug is a great tool. Webkit is somewhat on-par with Firebug, but it doesn't have a shortcut key to inspect elements on the webpage (with Firebug, it's ctrl-c.) The IE Developer Toolbar is good for inspecting CSS styles that are applied to your HTML elements, but that is pretty much it.
DrupalForFirebug Module
You need FireFox or Chrome, and the drupalforfirebug.module installed on your Drupal site. In addition to Firebug, you need the drupalforfirebug FireFox Add-on. Once all these are installed, you'll be able to look under the hood and inspect the SQL, the forms that get sent, as well as the users, nodes, views, and page variables.
You also gain access to the firep() function; if you call this function from within your Drupal code, a message will be sent back to your browser, but will not be displayed to the casual user. It's not best practice to do debugging on a production server... but sometimes, you just can't get away from it.
Devel Module
It's nice to click on the Devel tab and see all the values of each node page, but Devel is much more than that.
- dpr() is an alias for devel_printr()
- dvr() does a var_dump
- dpm()/dvm() spit out a variable in the page messages
- dd() opens up a log file in you server's temp directory and spits out the message to the log file.
Up to this point, we've basically been echoing variable information back to the browser or to log files. In order to see what's happening in the code as it's being executed, we're going to be
Setting up a Debugger
First, you have to set it up on the server side. You have to configure your php.ini to make sure the debugging extensions are enabled. Next, configure your debugger to use the correct ports et. al. on your server.
Using a Debugger
First, set your break points; next, connect your debugger to the server, and then hit a series of pages that can reproduce that bug.
- dave's blog
- Login to post comments
