If I have a module that I installed and its causing a conflict with another module, how do I trace it down to see which is causing the conflict? Let's say the error message doesnt' give any useful information in finding the culprit module. How would one go about find the module causing the issue?

  • This is a very general question, and I don't think that there is a common way to debug/trace for all type of errors.
    – Elin Y.
    Commented Jan 7, 2014 at 17:15
  • 1
    xdebug is an option which should help you narrow down the offending functions. Can you also update the question to include the error messages in case someone else recognises them.
    – digital
    Commented Jan 7, 2014 at 17:16
  • You can also use ddebug_backtrace() if you have Devel module installed. It gives a krumo output with a function stack at the top of the page.
    – Elin Y.
    Commented Jan 7, 2014 at 17:22

3 Answers 3


Have a look in /var/log/httpd/error_log.


You can use the debugging methods mentioned in the comments, especially ddebug_backtrace.

Another, more manual option, is, to disable other enabled modules one by one, until the error goes away. Once you know the culprit, search the issue queue of that module (and the new module) and/or use the debug statement (or drupal_debug from the devel module) to narrow down the problem.

Some pointers on how to debug: https://drupal.stackexchange.com/questions/545/how-do-i-debug-drupal How do I debug my Feeds import not importing a field

And then of course, you should look at the web-server logs (apache, etc). Another way to debug issues like that, when you get the white screen of death, is, to execute a drush command on the command line - like cc or something like that. Often, the error message gets printed to STDOUT.


My method was to edit the core set_message() function in the /includes folder and add in PHP's debug_backtrace() function in there to see the full output of where the module is causing the issue.

This way works for me since I don't have to have xdebug installed or have to go anywhere else. I think its the easiest way to do a backtrace from my point of view.

If there is a better more efficient way do let me know.

  • Editing core to debug weird problems is perfectly acceptable, assuming you revert your changes once you are done. Tracking whole sites in git or svn really helps here.
    – mpdonadio
    Commented Jan 8, 2014 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.