I have a custom module and a template to alter the appearance of my node submission forms, á la these instructions.

My module consists of three functions:

  • A hook_form_alter() that works fine
  • A hook_theme() that doesn't do anything but return an array, even if you enter other code before return (not sure if this is by design)
  • A hook_preprocess_HOOK() that is currently empty

dpm() doesn't seem to do anything in hook_preprocess_HOOK(), although krumo() on the same variables sort of works. It sets a Drupal message that reads Array: [n] items but can't be expanded or inspected at all.

In my template, print_r($form); prints out the form array as expected. dpm('self-aware roomba'); sets a Drupal message of "self-aware roomba" as expected. but dpm($form); does nothing and throws no error.

Everything except my hook_form_alter() is exactly as it appears in the linked tutorial. I even tried pulling out the entire hook_form_alter() to see if it works without it; it doesn't.

What could be causing dpm()/krumo() to fail silently?

  • is Devel module installed? dpm() comes from Devel module Aug 24, 2012 at 14:22
  • Yes, Devel is installed. dpm('self-aware roomba'); wouldn't work otherwise and krumo() wouldn't return Array: [n] items, it would just cause a fatal PHP error, which would cause my logs to not be empty.
    – beth
    Aug 24, 2012 at 14:26
  • so please place your code in your question and let me re-produce the errors ;) Aug 24, 2012 at 14:34
  • It is exactly identical to the code in the linked tutorial. It's a bit long to post it all in the question window. All the code is here: drupal.org/node/1092122
    – beth
    Aug 24, 2012 at 14:40
  • in which function (where) you are trying dpm()? Aug 24, 2012 at 14:42

2 Answers 2


I have run into an issue where dpm() and some other messages were eaten up by a 404 request in the background.


If dpm() or drupal_set_message() is called before the messages are printed out with theme_status_messages(), then you get to see them on the same page.

If dpm() or drupal_set_message() is called after theme_status_messages(), then those messages are delayed in $_SESSION until the next request that does theme_status_messages().

Some types of requests do NOT trigger theme_status_messages(). E.g. a form submit will only do the form processing, and then do a redirect, so the messages remain in the $_SESSION.

Also, it will only trigger on requests by the same visitor/client (this is why it is saved in session, which is client specific).

However, some requests that happen in the background do trigger theme_status_messages(), and can eat up your messages.

In my case this were requests to missing images, which resulted in full-blown html 404 pages WITH messages (and I did not get to see any of this, obviously).


The solution was to activate the "fast 404" feature.

  • That's a really nice piece of debugging, well done. My issue was that I had an SVG file 404ing, which wasn't covered in the default file extensions. Thanks for a great answer! Mar 31, 2014 at 9:57
  • Major up-votes for your research, @zhilevan! Fast 404 didn't solve this for me for some reason, but this was definitely the cause, as fixing the 404s instantly caused my dpm() to start showing up.
    – joe_flash
    Jan 20, 2016 at 2:45

test this my friend

$output = ob_get_contents();
  • This works but I get several versions of the same log message. If I understand correctly, all this is doing is collecting together the output and then rendering it via a php buffer? Is that right? Jan 13, 2014 at 5:45
  • @marblegravy yes ,right
    – Yuseferi
    Jan 13, 2014 at 6:28

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.