My brute force solution to for "fixing" IE 6 bugs:
for (x in document.write) { document.write(x);}
Drupal for Firebug: Under-the-hood Made Easy
Let's start here: Drupal for Firebug is amazing. I'll even go so far as to say that it's more useful than Devel Themer. More details
below, but you should start by downloading the Drupal for Firebug Firefox
extension (or the
Chrome
one) and drush dl drupalforfirebug on a local
project and giving it a spin.
When I first saw Moshe demo the Devel Themer module at a Boston Drupal
meetup a few years back it blew my mind. At that point I'd worked out
some nifty tricks for inspecting Drupal's page generation innards,
things like var_dump(array_slice(func_get_args(),1)) and
tracing with xdebug. With Theme Developer I didn't need to add debug
code to templates and modules (always a bit of a dangerous proposition),
I could explore the template variables and tpl files through an entire
page's content, without needing to know where to insert my debug
statements ahead of time. And it looked really, really cool.
I still use Theme Developer at least once per project, but over time it's shortcomings have surfaced. For one, there are the issues with themes breaking when it's enabled and various JavaScript conflicts that can get a little hairy. But the biggest challenge is that it's just kind of heavy. It takes a while to enable, it adds some bloat to pages, and, when push comes to shove, it often is still just faster to add some debug code. It's an unfortunate fact that these pose significant obstacles to using TD as part of a developer's task-to-task workflow.
Enter Drupal for Firebug. What it does is pretty simple: it exposes information from your Drupal page load in a Firebug pane (or Chrome pop up). While it doesn't include some of the key information provided Devel Themer (namely template files used and suggestions), what it does include covers most of the elements I look for most often: user objects at load, view, update, etc., node objects, the SQL statement log and views rendered on the page. Add to this the ability to log you own object dumps and messages to DfF and it's a really powerful tool that comes pretty near eliminating the need for debug var_dumps while taking a lot of the smaller inspection needs off of Devel Themer's plate.
Except...for theme files. My #1 wish for this module is that the firep() logging function it provides would work in template files.
The logic of this is tricky, and it makes sense that it doesn't (the
Firebug data is exposed in $closure and therefor must be ready for the
page template, which is called up top), but a workaround to this would
make the module THE goto debugging solution for me. Secondly, if it
could also list template files used it would pretty much have the field
covered.
Anyone have any ideas how best to add thse features? Could DfF use some sort of AJAX magic to retrieve the data displayed after the full page render, perhaps?
What do you use to dig into Drupal?






Comments
14 April 2010
2 days 16 hours
This is truly a wondrous thing. No longer will I dpm nodes in the template and comment them out later. No longer will I have to create preprocess functions for views to view their makeup. No longer will I labor in silence, as Sisyphus, on the same task, again and again!
1 July 2009
51 weeks 12 hours
so, some lessons learned.
1. I do love this module. It's pretty awesome and I can't imagine why I'd need to print_r ever again
2. I learned that in order to get this to work, you have to print $closure in your page template (so, for most this would be page.tpl and page-front.tpl depending on what you need it for). I believe this is in the readme file
3. It can really slow down a site. I'd recommend using it locally vs on dev (definitely NOT on a production site).