1

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. – Елин Й. Jan 7 '14 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 Jan 7 '14 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. – Елин Й. Jan 7 '14 at 17:22
1

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

| improve this answer | |
2

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.

| improve this answer | |
1

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.

| improve this answer | |
  • 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 Jan 8 '14 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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