DrupalCampToronto finished up Saturday night, and if I'm not mistaken, it was a whopping success. It certainly went well in terms of raw numbers: 150+ registrations and 22 sessions (plus who-knows-how-many random chat sessions in unused rooms). And judging by the straw polls I took at my sessions, there was a lot of learning going on. I need to record notes on the two sessions I led, and lessons learned for next time, because there will be a next time. Also, hopefully, notes from the sessions that I attended, though there weren't many because I put in a bunch of time at the registration desk.

First up is the Debugging Techniques Swap Meet (slides: pdf ppt keynote). I wanted a session on debugging because there are precious few resources for debugging Drupal problems. Part of this is due to the structure of the Drupal documentation, but it's also due to the many layers of technology involved in Drupal projects. I'm much more familiar with debugging techniques for HTML, CSS and Javascript than for the server side of things. Since I'm not a debugging guru, and it was a BarCamp, I decided to frame the session as a discussion rather than a listen-to-me-talk session.

I started with a discussion of hardware- and OS-level problems. I'm definitely less of a UNIX jockey than some of the other attendees -- I don't even use screen (yet), for chrissakes -- but kbahey had led a terrific session on Friday about optimizing Drupal that included many useful tools. Optimizing isn't quite the same as debugging, but when it comes to filesystem-level bugs, they tend to be permission problems that are not easily diagnosed with tools. I encourage people to look at Khalid's slides and learn how to tail -f their various system logs.

Moving up to the Apache layer, there are still not many tools that can help with debugging here. Know your way around the conf file format, ensure that the critical modules (mod_rewrite, mod_php) are enabled, and that directories can overwrite permissions using a custom .htaccess file. Also, tail -f /var/log/httpd/error_log can help with problems. Someone mentioned a syntax highlighter for these error logs that make them easier to read, but I can't remember what it's called. It might be this GeSHi thing.

Further up, we've got PHP. Again, in general it's good to know the conf file format, and to check that those php_ini directives can be modified from Drupal's settings.php files. Check the Apache error log if you're getting a blank screen -- that means it's a PHP error. The debugging tools I knew of were phpinfo() and the Zend debugger. Many folks scoffed with great scoffing scoffs at my mention of Zend. They claim Komodo is better. Interested parties should investigate; I'm not an IDE person and have never used Komodo. Ashok pointed out that Eclipse has a PHP plugin, and if I were an IDE person, that's probably what I'd use, but it doesn't come with its own debugger, only support for third parties.

Oy, I can't talk about PHP bugs without talking about this one wacky problem some of us at Trellon ran into a few weeks ago. If you're having trouble setting the maximum file upload size in the Drupal admin section, even after correctly setting max_post_size and upload_max_filesize, you should know that Drupal automatically sets the maximum file upload size to half of post_max_size. If you've got them set to equal amounts, it won't solve the problem.

Then there's Drupal itself. There are a few modules you should install on your staging site. Your first stop should be the devel module, which is a swiss army knife for aiding all sorts of development tasks. The trace module provides a customizable stack trace for errors -- a huge improvement on the current error-reporting system. Finally, the drush module looks awesome. It provides a command-line shell interface for Drupal, making some admin stuff very easy.

In the non-module area, there are a million ways to log messages in various places. There's watchdog(), but that's not very immediate. There's drupal_set_message(), of course. You can write to the various log files, or use the dprint_r() and db_queryd() functions that come with the devel module.

Now for the front-end stuff. This post is getting a bit long, so I'll just say: FireBug, WebKit, Drosera, IE Developer Tools. Refer to the slides for more options.

And now, a bulleted list of miscellanea that people contributed:

  1. Use CSS or HTML validation tools if you're having issues. They can tell you about unclosed DIVs, for instance. Various FireFox plugins can help with this. Total Validator was recommended.
  2. If you're stumped by a CSS or HTML problem, try changing the DOCTYPE declaration at the top of the page.
  3. The JavaScript IDE Aptana sounds cool, but it also sounds Rails-centric.
  4. Don't forget to ask in IRC! Lots of Drupal developers hang out in #jquery, as well as #drupal obviously.
  5. The coder module is a "Developer Module that assists with code review and version upgrade." It was endorsed by many people at the session.
  6. We're getting out of debugging territory with this one (who had the gall to go off topic? Oh yeah, it was me.), but module_builder is good for quickly and easily building module skeletons with nicely documented hooks and skeleton code.
  7. I frequently encounter a blank screen immediately after loading a custom module for the first time. This means there's a PHP error in the code, but it also means the whole site is down until you can disable the module. In order to do this, you'll have to go into MySQL and find the "system" table in your Drupal database. Find the entry that corresponds to your module and change the "status" field to 0. Follow a similar procedure for blocks, except use the "blocks" table. The aforementioned drush module can also take care of this.
  8. Finally, empty the cache on the server and the browser to avoid being confounded by cache issues when debugging.

I hope this list is useful, and Google-able. Feel free to add your own tips or resources in the comments.