(This falls squarely under the "Well, duh!" category, but remembering how long I used PHP without the benefit of a debugger myself, I figure it bears repeating.)

The flip side of Drupal's elegant and flexible system of hooks is that when you’re building a site that relies on lots of different modules, things can start to get a little bit slippery if you need to troubleshoot which module is hooking into the core and how/where/when.

A common “poor man’s debugging technique” is the time-honored method of peppering your code with lots of print_r($foo) or drupal_set_message($foo) statements. A lot of the time this is perfectly adequate, although it’s easy to forget and leave the occasional stray debugging statement buried deep in your code, only to be noticed after it’s already been deployed for two weeks. It’s also hard to get a comprehensive overview of exactly what’s happening in the system at the precise moment you suspect something is going wrong.

Enter the debugger. I've been using the free Zend Executable Debugger Eclipse Plugin with good results, but there are several other options out there if Eclipse is not your thing. As you may have guessed, “Free” in this case also means “Potentially tricky to install,” but the first time you catch a gremlin lurking at a breakpoint deep inside your PHP code, you’ll wonder how you ever lived without it.

For example, this afternoon I was scratching my head as to why a form radio button element wasn't properly displaying its default value; I looked in the database and saw it right there. What I didn't see, however, was the invisible carriage return character in the #options array. It might have taken me quite a bit longer to figure out what was going on without benefit of a debugging breakpoint.