It is not always the fault of Drupal

Take a look at following HTML snippet:

<img src="/sites/default/files/LOGO_adview_70_0_4.png" style="display: none;">

If you know a bit of css, you'll know that the image will be hidden in your browser. However, we had no idea where the inline style element came from, it shouldn't be there at all. We are using a simple node list generated by Views and after looking in the templates, custom modules, filters and tinymce settings we decided that this couldn't be a Drupal problem and had to look somewhere else.

In comes Adblock Plus, which is probably the first add-on I always install in my browser on a fresh OS install to block those annoying banners. And in our case, the add-on worked a bit to good. Take a close look at the name of the image file: LOGO_adview_70_0_4.png. The adview in the name is were things went wrong: when editing the same node again, Adblock Plus automatically added the inline style element in the HTML which is saved when updating the node.

It's really amazing how much time you can waste in debugging sessions.


drupal, bughunt, planet

Some simple debugging tips for Drupal

It was a funny week when it comes to squashing bugs in a few projects I'm involved with. Less is more and this is also true when it comes to debugging I guess, always look in common places if you encouter strange things. So here's a small list I'm really going to add on my checklist of debugging tips:

1: Always look in watchdog first. Almost everything within Drupal comes from the database and quite often when data is (partially) missing, it's because a query goes wrong. My use case: developer 1 defines some fields in the views ui and than implemented a views_query_alter hook in a module. Two days later, developer 2 decided to change the fields and poof, the query_alter completely freaked out, no content was shown and developer 1 didn't even knew about the views change. After 3 hours, he noticed the watchdog error and saw a field was missing.

2: Export your views to files and install journal. Exporting the views into a file gives you history if you use a code repository. You can easily switch back to a state where you were absolutely certain your site worked flawlessly. When someone else decides to override your default view, journal comes in handy since it adds a required textarea on the views UI (and also all other settings pages) where one has to fill in something about the changes. And even if he or she is very cryptic about it, you at least know who might have borked up your installation.

3: Never trust other people's commits. I learned that the hard way this week. I was confident my module worked fine, even the simple tests I wrote were passing and suddenly watchdog (remember rule 1) was growing with error messages. A colleague added some code which had absolutely nothing todo with my functionality so I figured something was still wrong with mine. A few hours of frustration later, I noticed a small word in an array was changed from 'field' to 'a' which caused the error messages appearing in the log. I had no idea where this came from, so I looked at the commit history (please, use a code repository) and I found the exact moment where this (desastrous) change occured - nobody knows why and how. Of course, these things happen and I'm pretty sure it probably happened to me too where I accidently changed some code without knowing so.

4: Only 16 chars! If you add your own watchdog messages, always remember the type is limited 16 characters. This is actually one I have to blame myself for. I decided to add a lot of watchdog messages for every action that happened into my module, so I could track down any errors that occured. However, all my types looked like modulename_action. The irony here lies in the fact that the name of the module was 16 chars long and when the errors started to popup, the action suffix was cut off when inserted into the database, so I had no idea where to look first. A quick look at the table structure of watchdog triggered a loud ironic laughter in the room and another hard lesson learned.


drupal, bughunt, planet
Subscribe to RSS - bughunt

You are here