Troubleshooting a Drupal module

  With over 33 thousand projects listed on Drupal.org, the first thing many developers do when faced with a functionality to build out, is to do a quick search to see whether there are any existing modules that can be used to help implement the desired functionality. While many popular modules have extensive documentations, working examples, and community support, there are far more that are smaller, less widely used modules, that may be early in it's life, or simply serve a relatively niche purpose, lacking extensive documentations. It would be simple to forgo these modules in favor of more mainstream ones, however in doing so we'd be doing ourselves a large disservice, failing to capitalize on possible time savings that could be had, and a bigger disservice to the continued advancement of the Drupal community as a whole, in not fostering the growth of new projects. If you did find a lesser known project that fits the bill for what you need, chances are that it's in alpha/beta/pre-production state and you may encounter a bug when using it. Some may think that at this point, it's not worth the time nor effort to continue to use the module, and in some cases that may be true, but for those who perseveres and finds delight in the resolving of issues and contributing to the sum of human knowledge, there are some techniques that we can make use of.  

1. Psychic debugging

Coined by Raymond Chen (https://blogs.msdn.microsoft.com/oldnewthing) This may be an unfamiliar term for something we're all very familiar with in some form, and it tends to work best for smaller projects. Basically we draw on our experiences with prior projects and attempt to skim the project code, looking at high level functions to get a sense for the proper flow of the application, ignoring the specific details and assume each functions work as they should. This is where following coding standard really helps with assisting us in getting a quick idea of how the module work. This technique will often help expose issues relating to the logic of the application, such as a function meant to execute an update on a node when a node is deleted. More details on psychic debugging can be found here (https://blogs.msdn.microsoft.com/oldnewthing/20070423-00/?p=27163).  

2. Rubber duck debugging

  Maybe we're only one coffee into our usual five-coffee routine, or have just spent too much time looking at code without a break, but sometime we become blind to issues that are right in front of our nose. This is where having a rubber duck (dog, cat, pencil, paper clip, QA guy) handy can be very helpful. Take a step back and start from the beginning of the problem area, and explain the code to your captive audience, making *zero* assumptions about their knowledge of the codebase.  This can really help flush out any assumptions we tend to make subconsciously as we read the same code over and over again, and it's doubly effective when you're the author of the problematic code. This technique can often manifest itselfs unknowingly when asking a co-worker to come take a look at the code you're having issues with, and in explaining the situation to them, suddenly stumbling upon the realization of where the problem lies. They're then thanked profusely and sent on their way, having no real clue what just transpired, and what they did to earn such gratitude.  

3. Debugger assisted debugging

What if as a car mechanic, you had the full schematics to every car that came into your garage, and for every engine problem you could trace the passage of every droplet of gas from the gas tank to the combustion chamber, the expelling of the exhaust gas through the manifold out the tailpipe, and the ability to check the exact temperature, pressure, composition and other properties of every single component within the car, wouldn't that be helpful? That was the glorious revelation afforded to me, when during my junior years, a senior colleague did a presentation on the use of xdebug in debugging drupal modules. Previously I had been using dpm() to print statements and expose various variables as needed, but there were limitations with this approach and it was not nearly as comprehensive nor convenient as using a proper debugger such as provided by the popular IDE PhpStorm. With a debugger you're able to expose essentially all variables within the application, see the backtrace of a function call, and follow an interaction from the beginning to the end, and see exactly where the bug occurs and what caused it. I cannot espouse the virtues of incorporating a debugger into your daily workflow enough, and strongly encourage everyone to take the plunge and try it out. The set up of xdebug is dependant on a number of variables and beyond the scope of this post, but there are numerous resources that goes into great details on how to get started such as this awesome tutorial (https://confluence.jetbrains.com/display/PhpStorm/Zero-configuration+Web+Application+Debugging+with+Xdebug+and+PhpStorm) by JetBrains, the developer of PhpStorm.  

4. Call a friend

Tried and true, it's never a bad idea to get a second eye and perspective on a problem. Your friend may have run into similar cases in the past and can point out the issue right away, saving you valuable development hours! With the above techniques, hopefully you're able to figure out the issue, and if you wrote up a patch, be sure to post it back to the projects page!