3

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

Earlier we used devel module in drupal 7 ,by using dpm() function it shows very neat and clean structure ,it was so easy to find out the values of variables.

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

why debugging became so complex in drupal 8?

5

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!

  • I disagree with the documentation. What if you have to debug on a server that does not have Xdebug, ie: Pantheon?. You'll probably have to pull your site locally which is time consuming. IMO, Xdebug is over kill, considering the learning curve to install it, for someone who is just a front-end dev. Makes sense for back-end but for front-end, it's not necessary. – No Sssweat Apr 3 '18 at 22:31
  • I use a good IDE @NoSssweat, It integrates with Pantheon should the need ever arise. Front end Drupal devs (themers if you like) have always needed to know PHP for Drupal anyway, with one-click debugging solutions available in any serious IDE I just don’t think the barrier to entry is there any more. It takes an hour to learn how to do it forever, and that’s got to be worth the investment IMO – Clive Apr 3 '18 at 23:17
  • @Clive integrates with Pantheon indeed, but just for uploading/committing files, drush, yata, yata, yata, but not for Xdebug. You'll need to use Kalabox to pull site locally and then and only then you can Xdebug a Pantheon site, once you set it up. Also, does Xdebug show you the available methods like kint() can? (see my answer). My point here, I wouldn't categorize Xdebug as the easiest method based on all the hoops that you have to jump through just to get setup. From a pure theming perspective not worth it IMO. – No Sssweat Apr 4 '18 at 0:43
  • @NoSssweat I’m not including the (very minimal) set up in this answer - OP wanted to know what the easiest way to debug code is. The easiest way to debug code is to use a debugger. Printing vars in html might mean you don’t have to spend a small amount of time learning the tools, but the actual job of debugging is harder and less efficient. Not to mention infinitely more frustrating. – Clive Apr 4 '18 at 1:02
  • And yes, any semi-decent IDE will show you the available methods on an object very quickly. Plus link you to the class definition, and allow you to view all variables in current scope and globally, set watches, navigate the class hierarchy in a flash, help you visualise the backtrace that led you to where you are, add breakpoints on the fly without invoking a page refresh, and countless others. All kint() can do is show one var at a time, statically, and take up a shed load of resources when using it in any Drupal theming because of the size and recursive nature of the associated objects – Clive Apr 4 '18 at 1:14
10

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

Using Devel Kint, which comes with the Devel module.


Welcome to Kint 101

Important: in order to use kint() in a twig file you need to enable debuging for twig.

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

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

  • Whats about static class properties tab,which information it provides,where and when it will used – user52318 Apr 4 '18 at 4:57
  • @Vikramfz16 in the case for user, not much. It's just a different way to access those properties, but these already have methods to access them. Most likely, you will not need them. – No Sssweat Apr 4 '18 at 8:34
  • Incredibly helpful - thank you. I also wanted to strip the debug tags, so I used the following... using your example: {{ content.user.id()|striptags|trim }}. But - I read that striptags can cause issues if stripping a URL. So in this case, for the production site with debug switched off, just using |trim worked nicely. – Jayden Lawson Dec 4 '18 at 10:34
4

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

Your Answer

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