1

Any of following codes in views-view-fields--MYVIEW.tpl.php make my browser unresponsive:

<?php kpr( $variables ); ?>

<?php kpr( $fields ); ?>

<?php kpr( $view ); ?>

I get the FireFox message:

A webpage is slowing down your browser. What would you like to do? Stop it. Wait.

If I select wait in hangs indefinitely but if I select stop I can see the output though I have to scan through the source-code. I can use other variables kpr($row) works for example.

I had similar results in Chrome.

How do I troubleshoot this?

  • 9
    There’s probably nothing to troubleshoot - the array simply has too much in it to be dumped out. Why not dump the array keys instead, then dump a specific element that you’re interested in. That will use fewer resources – Clive May 3 '18 at 17:34
  • views-view-fields--*.tpl.php template is for the row style output. kpr() is called for each variables and for each row. That's probably too much to be dumped out as Clive suggests. You can at least try to limit the number of rows that are outputted, in the pager settings. Perhaps select Display a specified number of items option with 1 output only. – osman May 8 '18 at 20:14
  • Use xdebug. These printed dumps are so large it’s crashing the browser. – Kevin May 8 '18 at 23:53
1

Instead of using kpr or devel or the like, switch to using a debugger like xdebug. Sometimes these arrays are so large that simply rendering them in the browser can crash it. This happened to me all the time with Drupal 8 and kint.

1

As others have said, the problem relates to the number of times you are calling the debug function and/or the size of the variable you're debugging. Sometimes the server will run out of memory and sometimes the browser will choke under the load of rendering the huge nested structure.
The latter seems like the case here based on your description.

One additional technique that hasn't been mentioned in other answers is to limit your code to only debug something a set number of times.

For example, your debug messages will print out for every row of the view, which could be a lot. If at first you just want to see the structure of one of these variables so that then you can make more targeted calls to the debug functions, you might only need to see the messages for the first row.

To do that you can use a static variable, like this:

static $debugged;
if (!$debugged) {
  kpr($some_variable);
  $debugged = TRUE;
}

That way, even if your code is run 100 times on a single page load, it will only print out once.

If you wanted to print a more than once, but not unlimited times, you can use a counter instead of just a TRUE/FALSE type check.

0

It might be really difficult to say what the problem is here.

It might be useful to look in the error logs to see why the browser is crashing.

What I think the reason might be it that the variables it to big te be printed so that it crashed the browser.

The kpr function is called for every row of the view so that may cause the big memory crash.

Try switching to XDebug, or XHprof (for ubuntu driven developments).

  • Because they're putting them in a views fields template, they will be called for every row of the view, which could potentially be a lot. – rooby May 9 '18 at 6:01
0

In cases like this I like to use Devel's dd() command. Which sends the output to a file on your server, rather than to the screen. Typically the file output is called drupal_debug.log in the configured drupal temp directory of the website.

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