You are here

June 2010

debugging drupal with firephp

This week I found myself trying to debug some code used in an autocomplete CCK widget on a Drupal site. Because this is code is AJAX and doesn't follow the normal pattern of a full themed drupal page load, many of the unglamorous but useful debugging techniques such as dumping arrays and objects as drupal messages or JS alerts are no help; the only message or alert I was seeing a lot of was a 500 error dialogue.

Luckily the devel module can work with the FirePHP library and firefox extension to allow developers to do simple debugging using the firebug console, and it works with AJAXy callbacks like autocomplete widgets. Here's how to set it up.

There are two main ways to get the FirePHP library into your drupal site. This snippet of code from the devel module illustrates the two methods it uses to try and find the relevant files:

// See
// Support Libraries API -
if (module_exists('libraries')) {
  $path = libraries_get_path('FirePHPCore') . '/lib/FirePHPCore/';
else {
  $path = './'. drupal_get_path('module', 'devel') .'/FirePHPCore/lib/FirePHPCore/';
if (file_exists($path .'fb.php')) {
  include_once $path .'fb.php';
  include_once $path .'FirePHP.class.php';
} if the libraries module is installed and enabled, devel will ask it to look for the code, otherwise it looks inside its own directory.

Keeping 3rd party libraries separate from drupal modules - which you'll want to upgrade at some stage - seems sensible to me, so I opted for the first option; I installed libraries module, and extracted the FirePHP library to sites/all/libraries, ending up with:


Naturally I already had firebug installed, but I also needed to grab the FirePHP addon for it.

Now to actually start debugging - the simplest way to get something into the firebug console is by using a devel module function which simply wraps the FirePHP fb function:


If it helps, you can also add labels and / or levels of severity easily, for example:

dfb($foo, 'probably bad', FirePHP::WARN);
dfb($bar, 'definitely bad', FirePHP::ERROR);

It took me a little while to work out why I wasn't seeing my debugging messages in the console at first - it turns out that I needed to enable the Net tab as well as the Console in firebug before it started working - it does tell you this on the FirePHP site but it took me a few minutes to spot it.

Another potential gotcha is that the devel module exposes a few permissions, and a user without these won't see the debugging info.

With my debugging messages showing up in the firebug console, I was able to fix my autocomplete widget in no time.

Finally I should mention a really good write up of this and several other drupal debugging techniques by Morten Wulff, and the fact that I'm using the release candidates of both the FirePHP library and the firefox addon and everything seems to be working well.

Happy debugging!

patching makes you feel good

This is going to be a more philosophical post than usual, with not a code snippet in sight. I'd like to share some thoughts on the motivations for, and benefits of, submitting patches (I'm talking about Drupal, but this could just as well apply to other open source projects). In case it's not obvious, the title is a reference to the ghostbusters theme tune!

The first time I read Eric Raymond's The Cathedral and the Bazaar (and some of his other essays, such as Homesteading the Noosphere), I had a slightly uneasy feeling. I think this was as a result of recognising the uncomfortable truth in Raymond's description of the motivation of Open Source hackers. In Homesteading Raymond describes what was probably my initial reaction:

"...many hackers resisted the analysis and showed a strong reluctance to admit that their behavior was motivated by a desire for peer repute or, as I incautiously labeled it at the time, ego satisfaction."

However, once the idea had sank in it seemed obvious - as many such insights do. In the Cathedral and the Bazaar, Raymond elaborates on what he sees as the goal of open source contributors:

"...the intangible of their own ego satisfaction and reputation among other hackers. (One may call their motivation altruistic, but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist). Voluntary cultures that work this way are not actually uncommon; one other in which I have long participated is science fiction fandom, which unlike hackerdom has long explicitly recognized egoboo (ego-boosting, or the enhancement of one's reputation among other fans) as the basic drive behind volunteer activity."

So, with this in mind, I am going to sit on the psychiatrist's couch, and make a really obvious statement; when one of my patches gets committed to a project on, it makes me feel good. I suppose that at least part of the reason is egoboo. When I admit that I really like it when the committer credits me by putting my handle in the commit message, or maybe even in the changelog file, there can be little doubt that this is egoboo. (This is particularly hard for a stoical Brit to acknowledge!)

I'll make myself feel a bit less egocentric by disputing Raymond's view of altruism; that the altruist is only in it for the ego satisfaction. If forced to choose a cynical view of altruism, I think I'd go with the game theory-style concept of reciprocal altruism; the idea is something along the lines of "I'm happy to give stuff to the community, because the community gives stuff back to me".

This leads us to a more practical reason for submitting patches to Drupal projects. Again this might seem self-evident, but if a module is useful for a site you're working on, but you identify and fix a bug, or add a feature or enhancement, you don't want to have to then maintain your own branch of the code. (Because you are going to keep the code up-to-date, aren't you?).

If you manage to get your patch committed then you can use the official release of the module, and be pretty confident your change is still going to be there when an update is released. This makes good business sense, and is surely an argument that can be wielded if bosses complain about time spent on sending patches upstream (or even worse if they start making noises about keeping the enhancements private for the sake of competitive advantage).

Having looked at the motivations for submitters of patches, how about the motivations of project maintainers? Raymond has this to say:

"..if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you as though you did every bit of the invention yourself and are just being becomingly modest about your innate genius."

Linus Torvalds and Larry Wall are mentioned as exponents, and beneficiaries of this approach. I wonder what our own (very modest) Dries thinks?

Of course there's the practical point that it's nice when someone else fixes your bugs and enhances your module, but the other side of the coin is the burden of reviewing patches and being confident that they represent an improvement to the project. This is a complex subject - the Drupal community has mechanisms such as the issue queues, with their status settings including Reviewed & Tested by the Community ["RTBC"], which hints at the fact that hopefully project maintainers can share the workload of assessing patches. There's no doubt that it's hard work maintaining a well-used module - all the more reason to try and encourage potential helpers and lieutenants.

In this post I've ruminated on the motivations for submitting patches to Drupal projects - from those serving the developer's ego, to more practical considerations of code maintenance - not forgetting that of being a good citizen of the Drupal community, of course. In thinking about what makes developers and particularly contributors to open source projects tick, I'd really encourage project maintainers to follow Eric Raymond's advice, and be generous with the plaudits when someone else fixes a bug or enhances your work. I'd also encourage anyone working with Drupal to take the time to submit patches; if you can get your patches committed upstream you've made your own job easier, and it might just make you feel good.