Discount Competence

I’ve spent the last 2 days trying to debug a problem with a drupal module that is installed on one of the sites at work. The problem was with a module called img_assist. Basically it allows for a user-friendly way to add images to drupal nodes by creating the image as a node itself.

The big problem with this bug was that it only exhibited itself on the live site. Not on the QA server and not on the Dev server. So, the immediate question is, of course: What is different? Well the answer to that question is more complicated than it sounds, and it was actually the source of my most of my woes. After doing a code diff and being sure that the directory structure and file permissions were the same, I was left with only one possibility: The data. My search began with looking in the database for tables that were related to this module. There was one, but it was empty on all three machines, — not it. Great. Now it was up to trying to figure out what tables the code bastardized for its own purposes — first guess ‘node’. So, upon searching the node table, I was able to find that the images were getting created as ‘nodes’, now all I had to do was figure out what wasn’t getting set, and I was all good.

This wasn’t as easy as it sounds like it may have been. From what I was told this just “stopped working”. Now, I know this almost never happens, but what that really meant was that I wasn’t going to get any more help from the people in charge of this site. First I tracked down a few suspect functions and started printing some of their values embedded in comments (remember, I couldn’t run a debugger because the problem was only present on the live server). I know I could have taken a database dump and debugged it on a clone machine, but waiting to get everything I needed for that would have taken longer than I had to do this. Anyway this didn’t help all that much — everything looked good. Evey time I did this, I had to save the change to the dev server, push to the qa server, push from qa to live, run the script on both dev and live, and examine the source in both places to find the difference. The last step was just one too many, so I started to print the messages to the watchdog function.

When it got to the point that I had about 45 watchdog statements in one function, I finally started to see some differences between dev and live. I noticed that the image width on the live server was was ‘45′ and the the width on the dev server was 450. Now I was getting somewhere. After about 30 more minutes and 10 more watchdog lines I decided to take a 10th and closer look at the data in the database. This application, like so many others on the Drupal platform saved its ‘persistent’ variables in the ‘variable’ table, what this basically means is that your data is stored as name/value pairs with the value being a serialized string (even if the value is just a string). The value of the maximum width on the dev server was ’s:7:”450×650″;’, the maximum width on the live server was ’s:7:”450X650″;’. This was something that I had overlooked all of the previous times I looked at it. So, I set the value to the string containing the lowercase ‘x’. It worked!

I was appalled, disgusted, and very angry. I couldn’t understand how a developer could write a module that made such a stupid mistake. I also couldn’t understand how the ‘people in charge’ didn’t realize that the very same second that they reset the maximum size in this module on the live site this stopped working.

I’m not blaming Drupal this time. I am, however, blaming the third-party vendor that built the site for us, and the developer that wrote this module. Attention to detail is everything in this business and clearly neither the contractor nor the module developer cared enough to fix, or more likely even notice a silly little bug like this.

I’m disgusted with the whole thing. But what do I know?