dpm() does not display any results on screen

Question

I have the same problem as file_scan_directory() takes about 10 seconds to execute. I just tried the dpm(func_get_args()) suggestion, and unfortunately it doesn't show anything to me.

I've cleared all the caches, and run the cron tasks. What am I missing?

Answer 1

Make sure you have print $messages; in your page.tpl.phptemplate file. By default, devel (dpm) is configured to print it's content in the message area of the site. So if your template for some reason does not render the contents of $messages, you won't see anything.

Answer 2

1. Sometimes krumo($variable) might work when dpm($variable) doesn't.

2. Sometimes print dpm($variable) might work when dpm($variable) doesn't.

3. 2. might also be the solution when there's no print $messages in your page.tpl.php anymore. Maybe you can add it back.

Answer 3

You must be logged-in to the Drupal site, with the correct permissions to access Devel. Log in as admin should do it.

Answer 4

I'd highly recommend devel_debug_log. It requires the devel module, and it gives you the ddl() function. ddl adds a page to your reports in configuration, so it's similar to printing to watchdog, but you have a nice clean page where you can send your debug messages, and not worry about race-type conditions where your messages might get cleared before you have a chance to see them--or, as in your case, theme issues.

(This is also an EXTREMELY useful tool if you're trying to build out any sort of API, as all those requests would never show you any kind of dpm() messages.)

Answer 5

Ensure that you have enabled and installed the Devel module as dpm() is a function declared in this module.

dpm() description taken from here.

Prints a variable to the ‘message’ area of the page using drupal_set_message(). You can use this function to keep track of one or more variables when you’re working on the code running your site. Because the Devel module now comes with Krumo, the output is compact and unobtrusive.

dpm($input, $name = NULL)

If, for some reason, you are not using Krumo, you can use the $name parameter to distinguish between different calls to dpm().

After you have downloaded and enabled Devel, try the answer from file_scan_directory() takes about 10 seconds to execute again and it should work.

Answer 6

If you want to print it from inside a function without touching (or having) a template file, try this:

$nid = 3;
$node = node_load($nid);
dpm($node);
print theme('status_messages'); 

Answer 7

This is sometimes a result of a resource on the page returning a 404.

Drupal renders the 404 page and in doing so fetches (and clears) the messages from the session and puts them on the 404 page that you don't see. Then when the main page fetches the messages there are none left.

You can open the network tab and check to see if any resources have a 404 status.

An easy solution here is to enable fast 404 by uncommenting this line in settings.php:

# drupal_fast_404();

Another good solution here is to use devel_debug_log as suggested by SlakeFistcrunch.

Answer 8

Sometimes the message can be cut or won't work in case of AJAX.

More reliable method is to do just (then remove after finish):

var_dump($data); die();

Or you can use dd() (part of Devel as well), e.g.

dd(func_get_args());

then check your log file (in temp folder), e.g.

$ tail -f /tmp/drupal_debug.txt

Using above method is more convenient, quicker and it may support AJAX or other request without breaking the current site rendering.

---

If you still like dpm(), try also using kint() (enable the included Kint submodule for these pretty print of variables).

Answer 9

If only some dpm() calls do not work, it can be due to dpm() crashing. I saw it happening in the following scenario in a custom form submit handler:

function mymodule_formid_submit($form, &$form_state) {
  dpm($form_state);
}

I believe the error condition was caught by an exception handler in dpm(), because the page was displaying fine, no WSOD or something, just no dpm() message either. The error is probably undetected recursion, because using ddl($form_state) instead resulted in browser maxing out on memory when watching the corresponding object in the report generated by the Devel Debug Log module.

As a workaround, try to print only a (relevant) part of the object, like dpm($form_state['values']) or dpm(array_keys($form_state)).

Answer 10

For Drupal 8

Make sure status_messages is an enabled block in /admin/structure/block and inside a used region of your theme

And depending on your theme's setup you might have to actually print it manually inside your page.html.twig template

{{ page.status_messages }}