Lullabot Ideas
We know stuff. We empower you to know stuff too.
Drupal: Exposed
Article by Angie ByronNovember 1, 2010 - 9:05am
Peeking behind the curtain at what makes Drupal tick
Here at Lullabot, we've trained hundreds of new Drupalistas in public workshops and on-site private trainings over the years. One of the primary things that people new to Drupal struggle with, once they grasp the basic concept of the hook system and the theme system, is figuring out the "big picture" of what all they actually have to work with to customize their own Drupal sites.
This article will expose a couple of quick core hacks* that we sometimes use in class to help gain insight into all of the hooks, template files, and theme functions that Drupal makes available on a specific page request.
* Note: Under normal circumstances, we would never recommend that you "hack core" (modify core files). However, temporarily, on a local test site, and for educational purposes only, sometimes it's okay. Maybe. ;)
Hooks
The Drupal API site offers a comprehensive list of all core hooks that Drupal registers. But unless you have the very simplest of sites, chances are you have one or more contributed modules as well which aren't (currently) displayed on that site. Furthermore, a huge list of what hooks exist doesn't help you when you really want to know what hooks your particular Drupal site exposes so that you know where you can cut in and customize Drupal's behaviour.
Fortunately, all hooks in Drupal run through a function called module_implements(). So you can do a quick hack there to gain insight into what hooks fire on a given page.
In includes/module.inc, find the module_implements() function (around line 595 in Drupal 7, and 415 in Drupal 6). At the top of the function, just after the line:
<?php
function module_implements($hook, $sort = FALSE, $reset = FALSE) {
?>add:
<?php
drupal_set_message("hook_$hook");
?>This gives you output similar to this (click for full version):
Note that there are also hooks that fire after the page is displayed, which won't be visible until the next page load.
Theme system
The Theme Developer module lets you highlight any section of a Drupal page in a Firebug-esque manner and find out where it comes from. This is incredibly useful when you want to override one specific part of the page.
But sometimes, it can be useful to get a "bird's eye" picture of all of the template files and theme functions that make up a given page.
All output on the page is routed through a function called theme() before being presented to the browser. This makes it a nifty place to add some small hacks to gain insight as to what's going on when a page is rendered.
Template files
In includes/theme.inc in the theme() function, around line 925 (Drupal 7) or 730 (Drupal 6), change:
<?php
$output = $render_function($template_file, $variables);
?>to:
<?php
$output = '<div style="border: 1px dashed red">' . $hook . $extension;
$output .= $render_function($template_file, $variables);
$output .= '</div>';
?>This simple hack will give you a picture such as this when you reload the page (click for full version):
Theme functions
A similar hack can show you all the theme functions that create a page. This is not recommended to run with the previous hack or you will have a mess. :)
In includes/theme.inc in the Drupal 7 theme() function, around line 880, change:
<?php
$output = $info['function']($variables);
?>to:
<?php
$output = '<div style="border: 1px dashed red">' . $info['function'];
$output .= $info['function']($variables);
$output .= '</div>';
?>The same hack in Drupal 6's theme() function is around line 655, change:
<?php
$output = call_user_func_array($info['function'], $args);
?>to:
<?php
$output = '<div style="border: 1px dashed red">' . $info['function'];
$output .= call_user_func_array($info['function'], $args);
$output .= '</div>';
?>This gives you output similar to this (click for full version):
Other suggestions?
Are there any other quick hacks you can suggest for gaining insight into what's going on under Drupal's hood?
About this 'bot
Angela Byron is the Drupal 7 core maintainer, recipient of the Google-O'Reilly Open 2008 Source Award for Best Contributor, and an Open Source evangelist who lives and breathes Drupal. She got her start as a Google Summer of Code student in 2005 and since then...
Comments
Hey, cool
Thank you for this! This newbie appreciates it.
The content of this field is
The content of this field is kept private and will not be shown publicly.
Great article, Angie! I too
Great article, Angie! I too sometimes hack core on a development site if I need to gain more insight into a specific problem. Khalid of 2bits.com has a few good hacks for this purpose too (like his memory.inc patch for tracking how much memory is being used on page requests).
One that I use sometimes (apologies if the code is not actually 100% correct) is:
<?php$hook = 'hookname';
$implementations = module_implements($hook);
print theme_item_list($implementations, 'Implementations of ' . $hook, 'ul');
?>
This way, I can see which currently enabled modules are implementing a given hook on my site. This could in theory be used in conjunction with your first example to show implementations of all hooks on your site.
Hello Angie, i was trying
Hello Angie,
i was trying something similar in the meantime, trying to build a module displaying the order of execution of all hooks for the running page, but i discovered that the way hooks are invoked is not very consistent. Not all hooks run through module_implements(). Starting with bootstrap hooks ('boot', 'exit'), there are many other examples. Try to search for 'module_invoke(' in the sources. Or am i mistaking?
Devel Themer
the last two bits of core hacks can be avoided if you use devel_themer on your local development system. whenever i need the template names or the theme functions, i just enable the module. give it a try.
maybe the module_implements hack would be a nice feature for the devel module. but i am clueless as how to do it. maybe i'll just post it in the issue queue.
Oldie but a goodie
I still use Angie's tip from '07 on Quick and Dirty debugging using drupal_set_message: http://www.lullabot.com/articles/quick-and-dirty-debugging
This is really helpful for exposing a lot of what is going on in Drupal when there is an error. A slight change I make is for it to also show debugging messages for warnings (Development sites only of course).
Very useful
Hi Angie,
I think this is fantastic advice, I've been a Drupal dev for nearly 3 years and I think I would still find this useful, sometimes its nice to be able to do things like this rather than go through the code line by line or hook by hook with a debugger like XDebug.
Keep the tips coming!
Non-intrusively
I find it much more productive to use a good debugger (phpED, PhpStorm, etc.) and set breakpoints in core to examine variables and function execution. No modification of code that way, no chance of forgetting to undo hacks. I can't imagine serious development without a debugger and a local test site.
good tool—different problem space
debuggers are not very good at all for providing a broad overview of how a page is assembled but are very good for drilling down into one particular facet.
Great tips
Thanks for the post, really good tips and I always find it interesting to read how others are using / developing with Drupal!
Keep it coming.
pete
Great Tips
Usefull when you have to figure out stuff for unconnected users, where devel_themer cannot be used
"SVN update" at the end cleans up the mess
This is fantastic. I think it's important to distinguish between "debugging" and "learning Drupal." The technique Angie explains here is primarily a learning tool, not a debugging tool.
If you have your pure Drupal core committed to SVN or another version control system, cleaning up the fun is so easy. It occurs to me that I could make a patch of a whole set of these hacks that I could apply when I need to, and then clean it all up just as fast.
Also what's "nice" about these hacks, (and why kittens won't suffer :), is that the existence of the hackishness is totally transparent via the UI. You aren't going to forget that you hacked core.
It's the hacks you forget about that are the real danger.
Thanks much,
Shai
The term 'exposing' is better
Hi Shai,
I think that the term that Angie herself used is the best: exposing. Learning is when you learn how something works (e.g., Drupal) but when you do know it you sometimes need to investigate it. Exposing is one way of investigation.
Amir Simantov
Drupal trainer in Israel
facebook apps/ iphone apps with drupal???
I really dont know much about writing code but drupal has been awesome to create websites without touching code anyway now i want to create a facebook app and an iphone app how do i do that with drupal i heard people use drupal as a back end so is there a video for it or how do i do it??? wehre can i find info on how to create apps without touching code??
thanks!
Dependent CCK fields
Hi Angie
Not sure this is right place to ask this question, but after searching the net and referring so many materials I couldn't find a solution to this fundamental issue. Hope you could give me some direction.
Lets say I have two content type, one is Make and other is Model so Models come under a Make, for ex: (Another example would be Country and Cities in the country - without using taxonomy but as content types)
Now in another content type I need to show these two fields to user to select. First user will select Make and based on the selection I need to populate (filter) the Model list so that user will select model under that make (Similarly city in a particular country not all cities)
How to I do this with existing modules (CCK)
Thank you very much
good cms
i love drupal cms