Drupal - What is easiest way to debug variables in nodes, views, blocks and page twig templates?

What is easiest way to debug variables in nodes,views,blocks and page template

Welcome to Kint 101

Installing

Using Kint with Devel 8.x-2.1, which comes with the Devel module.

Using Kint with Devel 4.0.1. Kint no longer comes with Devel, you'll need to do
composer require kint-php/kint and apply patch.

Important: in order to use kint() in a twig file you need to enable debugging for twig. If you're not debugging inside a twig/template file, you can skip this part.

If you have Drupal Console installed drupal site:mode dev, remember to set it back to drupal site:mode prod when your developing is done.

If you don't have Drupal Console, do the following:

You enable Twig Debugging in sites/default/services.yml. (If services.yml does not yet exist; copy default.services.yml and copy it to services.yml.)

Set the debug variable to true. And clear cache.

parameters:
  twig.config:
    debug: true

Remember to turn debug back to false after you're done developing.

Source Debugging Twig templates

Now do the following to prevent issues with Devel 8.x-2.1, skip this part if using Devel 4.0.1

For starters, you are likely to run into this issue when you try a kint dump, specially if you just try
{{ kint() }} without passing any parameters

enter image description here

This is due to the array or object being too big for your server resources to handle the default kint settings.

Edit /modules/devel/kint/kint/config.default.php and set $_kintSettings['maxLevels'] to a lower number to reduce recursion and the memory needed for dumping variables. The default is 7, I have mine set to 4. If 4 still doesn't work for you, keep lowering the number.

Ok, lets use kint

Note: If you're trying to dbug when logged out, you'll need to give Access kint information permission to the anonymous user role.

For Example, in comments.html.twig we do a {{ kint(content) }} and you will see

enter image description here

Tip #1 Do not click the + button, it's pure Evil

The + button will automatically open every single children and their children.

Instead, click on anywhere on the bar but the + button, for example, click here

enter image description here

Look how nice a tidy our Kint is

enter image description here

Also what is the easiest way to get protected variables values.

Getting a value

Lets say we're interested in the User. So click on user, but again do not click on the + button. You will see this

enter image description here

The id is protected, how do we get this value?

Tip #2 click on the available methods tab

This will reveal all methods that we can use here

enter image description here

So simply go with the one that makes most since, here being id() to get the user id.

{{ content.user.id() }}


why debugging became so complex in drupal 8?

It's not, as long as you know how to use Kint

Using all the above tips and tricks, I was able to answer this question Show comment author e-mail in comment.html.twig


What is easiest way to debug variables in nodes,views,blocks and page template.

Straight from the documentation:

Far and beyond the best way to deal with printing out variables is to use Xdebug.

If you use the other non-xdebug methods noted below you will have many recursive things rendering which may result in pages and pages of information that are not useful to you.

So using a proper debugger is the recommended approach. You might be tempted to use var_dump, or an extension thereof like the kint() tool included with devel, because it’s perceived to have less setup. But to reinforce the official documentation, I’d strongly advise you not to do that.

The hour it takes you to research and implement XDebug will be saved over and over again as you find yourself to be a much more effective debugger. Var dumping is an ok approach to debugging, but it’s pretty old fashioned, and becomes a frankly poor approach when compared to using XDebug in and IDE that knows how to integrate with it properly.

Plus you won’t run into resourcing issues - no more 500 errors when you try to ksm($vars) in a page preprocess method. No more waiting 30 seconds for the page to become responsive again after accidentally clicking the wrong part of the output.

Also what is the easiest way to get protected variables values.

Protected properties are just that: protected. You’re not supposed to be able to get easy access to them unless the author of the class exposed a method for you to do so, or they’re designed to be available via magic methods. If such methods exist, you can use them, or if you’re determined to break convention you can get them via reflection. This isn’t an issue Drupal can or would attempt to solve.

Of course, your debugger will show you the values of protected properties without you having to hunt for them.

why debugging became so complex in drupal 8?

It actually got easier in my opinion, I guess it depends on your outlook and experience. Yes there’s a small amount of overhead now, you have to set up a debugger, but anyone doing any development should have a debugger ready to go. You only set it up once, then you can use it in every project forever more with a couple of clicks, no extra code, no remembering to remove that debug code when you’re done, no 500 errors when one Twig call to kint() slips through to production where the devel module is disabled.

It’s not even a worthy comparison IMO, the debugger beats everything static var dumping can do every time. Once you’ve converted, I promise you won’t think about going back!


You can use twig_tweak module.

You can use {{ drupal_dump(var) }} or its alias {{ dd(var) }} to get a variable dump which works even if twig debug mode is disabled.

Here is full list of functionalities : Twig Tweak Cheat Sheet

Tags:

Debugging

8