Kint debug tool for Drupal

Hi,

I had used your Sandbox project and really liked it as an alternative to Devel, I found it to be lighter on system resources and PHP memory. Just FYI, the link in your text above to the sandbox project is not working.

Do you intend to promote it to a full project? as it is a great idea and I think there is a need for another option for a debugging tool.

I looked into this a bit and this looks like a solid krumo replacement, AFAICT. Anyone else have an opinion?

#3 <-- great well I'll definitely use it when you do. Thanks

Relating this with #1853112: Replacement for Krumo?

+1 for replace Krumo with Kint.
I've been following this project for very long time, and emailed with Raveren. He's a cool guy and keeps the library in top shape. He's open to new features and he has been active maintaining the library for 2-3 years already. So that's always a good sign

The debugger is really rich and has many cool features (trace, printing variable/function names,etc, different colors for dumping inside a loop, tabular data, etc), but from outside looks like "oh, it's just Krumo"

The debugger is getting traction in other PHP frameworks, like Symfony and we could get benefits from that. For example: Kint in Twig https://github.com/barelon/CgKintBundle

There is a couple of minor issues (it uses a dd() function alias, like Drush ) but I think the integration (replacement of Krumo) could be straightforward.

This a screenshot of an D7 integration I did partly in 2012 http://take.ms/oz3jt with a custom minimalistic Kint theme I wanted to contribute to the project, but the project got refactored and finally I didn't have time to continue with this.
I would be happy to contribute as much as I can, specially in front-end stuff for the integration of Kint with Drupal 8

FYI, to loop these all together. There is also talk about getting LadyBug (MIT license) in core. #1804998: Add LadyBug from Symfony to Core to allow debugging variables within templates

I'd like to put this in Devel. I've requested Kint to be added to the packaging whitelist at #2191293: Kint library (PHP). If someone could RTBC that issue, I'd appreciate it.

If anyone could work on a D8 port of whats in the Sandbox, I'd appreciate that as well.

Wow, Kint just got whitelisted!

Libraries have changed a bit in D8 so the sooner we get started on that, the better.

Libraries are due to be simplified in D8 a lot in #1996238: Replace hook_library_info() by *.libraries.yml file. But we could proceed even before that gets committed.

See #2191395: Make dpm() and friends pluggable (with Krumo, Kint, Ladybug etc)

I ported to 8.x and simplified kint module from the sandbox. I pushed my proposed branch to drupal.org. See http://drupalcode.org/project/devel.git/shortlog/refs/heads/8.x-1.x-kint. I included the kint library right in the repo, just like we do for krumo.

Feedback is appreciated. I'd like to commit this to 8.x-1.x soon.

FYI, I don't see much value in pluggable backends for dpm() and friends. Each module can provide its own and user just picks his favorite debugging module. We don't have to over abstract this. To be honest, I think calling Kint::dump() directly is the ideal way to use this module.

Of course danielenko, participate!. Help us here reviewing moshe's commit.

Thanks moshe. It's working for me in latest 8.x.

Example:

  kint_trace();
  Kint::dump($page);
  kint($page);
  ksm($page);

Screnshot

Here is my review:

So for me it's good idea a minimalistic integration devel-kint, like moshe proposes with few aliases. Kint has lots of advanced modifiers like +Kint, -Kint, @Kint, etc , creating aliases for every single option gets overwhelming, so using raw Kint class is wise.

But if I want to use Kint::dump (without wrapper) you need to call require_kint() manually. I suppose nothing we can do about it. Maybe add to README ?

Also, I don't understand why we are creating a special sub-module for Kint. This decision is making Kint a 2nd citizen. Who is going to enable a extra module for some extra goodies? Why not to have Kint functionality enabled with devel module? Anyway kint.class is lazy-loaded.. no perf penalty.

Bugs and things to improve:
1. When using Kint through a wrapper (like ksm) we are losing the benefit of outputting the name of the variable. (See in the screenshot the variable $page) I think this is something to be fixed in the Kint side. I open an issue: https://github.com/raveren/kint/issues/106
1. If moshe insists on keeping it as submodule, at least, change module name from Kint to "Devel Kint", so searching for "devel" in the modules (Extend) page will show this module.
2. Deprecated user_access. Use Drupal::currentUser()->hasPermission
4. Add admin Settings to choose Kint theme and other variables (see config.php in github repo and an example of how to override config in this Symfony plugin: )
5. The Kint alias dd() doesn't conflict with Devel's dd() thanks to this line in Kint's code.
We should add a note to README.txt about this conflict? For those familiar with Kint, dd() is the main alias of Kint.
6. Library is currently in kint/kint-0.9/ .. I'm not a fan of including version number in name folder.
7. We are not using DRUPAL_ROOT in the path of the library. (see how has_krumo has a different way of requiring the Krumo library)
8. There is no point to check Kint::enabled() inside kint.module. This is an internal thing of Kint. I see no reason to double check it. See https://github.com/raveren/kint/blob/master/Kint.class.php#L194

I see no reason to update to Kint 1.0.0 until is stable, unless is a blocker.

I can help, but What we should fix now, and what we postpone after merging it to 8.x-1.x ?

i've gone ahead and merged my branch as is.

@corbacho - thanks for the review. i think all your points are sensible. please submit a follow up patch here or in a new issue. i do want to keep kint as its own submodule. thats easier for maintainers. i do agree we should rename it to devel_kint and 'Devel Kint'. This lets one enable it with `drush en devel_*` if you wish.

@danilenko_dn - thanks again for your sandbox code. i hope you will keep contributing in the devel issue queue.

this submodule will need a maintainer, so you guys are both encouraged to submit patches and earn that position like the other maintainers have done.

folks interested in better composer usage are welcome to add ideas to #2128353: D8 strategy for Composer Manager

I'm not sure about the submodule either, isn't this a tool to replace dpm and friends at the end?
Looks to me that the plugglabe system makes a lot of sense, that way then we could provide kint as the default and leave any contrib folks to keep maintaining krumo elsewhere and provide a setting.

I've fixed the user_access deprecated function in another issue.

Yes, this deprecates dpm() and friends. Thats not an argument for submodule or not.

Pluggable backends for dpm() and friends assumes that those systems have to use our function names. I don't see why thats true. In general, I think it is over engineering. Folks who disagree should describe why this complexity is justified.

dpm() has become a great tool to train new drupal developers with to get at data. It would be nice to keep that as an interface for debugging. ksm(), lbsm(), anyother_set_message() function adds more complexity in the API.

When working with other developers it would be nice to know that that left over dpm() call on the production machine that's causing function doesn't exist errors comes from devel module by convention as it seems common error. Talking to drupal developers, often that function name explicitly comes up in conversation. Which is why I say it's a strong part of the API.

#twocents

Opened a followup to start removing krumo: #2209705: Kill krumo and procedural debug functions I suggest we close this one and follow the conversation in there.

IMHO, if we document everything properly, and we find suitable alternatives, we can remove the wrappers.

Wrote a ContentEntity parser that can display Fields and their properties, see attached screenshot.

Code is on github: https://gist.github.com/Berdir/9335736

Not suited for a pull request as it's Drupal specific, but right now, it's not possible to add custom parsers through configuration it seems? Would be nice if that would be possible ;)

Uhm. Now with 100% more screenshots.

Thanks a lot @Berdir, I've opened an issue in Kint to see what's the right direction for this: https://github.com/raveren/kint/issues/107

Adding a related issue for Twig integration.

@Berdir that looks great.

Here is a patch with my suggestions from #15, except creating admin settings for the module, since this will require more agreement, and is better to open new issues.
-----------------------
Updated kint to 1.0.0-wip branch, since Raveren said is stable and contains fixes that we want.
Moved from /kint-0.9 directory to just /kint
I tried to improve the README, the .info.yml and function docs.
Added DRUPAL_ROOT to @include_once (replacing require_once), as we are doing for krumo.
Removed Kint::enabled() from our code, since this is already checked by the library.
------------------------

Now that I was checking the code and the differences between Krumo Vs Kint, I agree with Moshe that we shouldn't abstract devel aliases.
The old dsm($data, 'description'); doesn't support multiple arguments.
The new ksm($data1, $data2,... ); it does.
Just there, we would have broken the backwards compatibility. So I think is better to start from scratch with new aliases as we are doing. Restricting ourselves to stick to the old aliases, only bring limitations and no much benefits.

I agree with @pcambra that Krumo should die. But, since Kint is a 2nd-class citizen (submodule), we can't do anything about it. Hopefully in the future Moshe changes his opinion when Kint is more stable.

Is it ok to make a Kint submodule in the D7 branch ?

Looks good.

kint_require() is misnamed now as it uses include_once. What's the motivation for switching to include_once? Do you think sites will source Kint class from elsewhere and still be using this module?

No reason. I changed to load Kint the same way we are loading krumo in has_krumo(), I thought to avoid fatal errors if kint class is not there. But, probably is better require_once to see what's the error going on, instead of a blank page. Otherwise, no preferences from my side.
Here is same patch with require_once, as it was before

The patch deletes the old kint library but has no replacement?

Oops. Now with kint (1.0.0-wip)

dpm() has become a great tool to train new drupal developers with to get at data. It would be nice to keep that as an interface for debugging. ksm(), lbsm(), anyother_set_message() function adds more complexity in the API.

This is not a strong opinion, but:
In the last year I used both dpm() and Drupal\krumong\dpm() for debugging.
I personally perceived the shorter spelling for dpm() as a huge advantage. It made me use Devel dpm() a lot more than the Krumo NG version.

I perceived the same advantage for the other shortcuts, e.g. for Chrome PHP. I don't use them every day, but when I use them, i will spam them in a high frequency, and this makes me strongly prefer the shortcut over the spelled-out class + method name.

On the other hand, these shortcuts "pollute" the global namespace more than other functions. In other words, there can be only one module to occupy a specific function name.

If it is only one or two modules competing, and each defines only one or two shortcuts, that should be no problem. Although I am personally paranoid enough that I would implement some opt-in or opt-out mechanic.

Having it "pluggable" might not really be necessary. Instead, we could have the shortcuts in a separate file, the inclusion of which can be disabled e.g. in settings.php.

(I don't have strong feelings about this, I just want to explain my motivation)

Is there something else I can do to move this forward?

Woops, I miskakenly committed the library removal. Now the kint 1.0.0-wip branch is there. I'd love to get onto a tagged release of Kint ASAP.

I also converted the entity subtabs to use Kint. Lets iterate on the approach and make it work and look nice. You can see it at node/1/devel/load, for example.

Good stuff
* Issue summary updated
* Patch to fix has_kint function. It was not calling kint_require, so it loads a blank page when opening /node/1/devel ).
* Also patch contains a fast-fix to fix the "floating" issue. But the proper thing to do is to create a devel-theme upstream in Kint library with CSS that fits better to us. I would love to work on that.

Screenshot of /node/1/devel after patch:
http://monosnap.com/image/AtrfRSVRDeqJq91cp0Ix0rLfqcoQ4F

I'm interested to maintain kint submodule, if danilenko doesn't.

oops. Ignore previous patch. I spend too much time with JavaScript these days.

Committed. Lets open new issues for improvements.

Thanks for volunteering to maintain kint integration. I'm happy to have 2 kint co-maintainers if danilenko_dn also wants to maintain.

Are there any plans to backport this to Drupal 7?

The devel maintainers are not working on a backport, but I encourage anyone else to submit a patch.

D7 backport here.

Patch format might be invalid, but the back port seems to work properly. Just needs the patch to be re-created.

Patch in #47 applied cleanly for me. Attempting to resubmit it.

Try this...
Also, updated Kint to 1.0.10.

With kint, how do you obtain the path to an element?

Eg, with krumo, you double-click a property and you get a string that you can copy-paste into code, eg "...->foo['bar']->biz->baz".

Thanks for the patch; I have been struggling with krumo problems for the past couple years, and switching to kint fixes it.

I noticed that when I added the permission to my devel feature, the permission was listed alphabetically in the K's, rather than the D's with the rest of the Devel module listings.

@joachim Krumo doesn't have this - Unless I'm mistaken you're using the search_krumo contrib module

> @joachim Krumo doesn't have this - Unless I'm mistaken you're using the search_krumo contrib module

This was definitely something that came OOTB with Devel module on D7:

I filed a feature request on Kint, and there's apparently a pull request for it: https://github.com/raveren/kint/issues/194

My mistake - thanks for the info, I don't use that feature, but glad to see it's being moved in.

For some reason after applying the patch in #52 to D7 and enabling the new kint module I'm not able to use the ksm() function. It doesn't produce any output at all but there are no errors either. Any ideas what I might be doing wrong?

After months of frustration using Kint.
vote: -1
thumbs down :(

@chriscalip, do you care to expand on that with some more information? The issue at this point is just about making a D7 version of Kint available in Devel…

@Cottser
With objects/classes becoming much more involved, you got to take a leap of faith when invoking Kint, that it doesn't freeze your browser.

@chriscalip describes the exact problem I'm having in both Chrome and Firefox. I'm using drupal 8.2.4 and devel kint 8.x-1.0-beta1

Kint is terrible and with all the improvements that drupal 8 boasts I feel replacing krumo with this monstrosity will go down very badly with a lot of other developers too. Drupal always seem to get so close and then drop the ball somewhere. I guess this is it.

I found that this solved the problem but by reducing the depth seems to somewhat defeat the point.

// kint runs too slowly or crashes my browser when using the standard
// seven levels of depth provided by default in devel config.
require_once DRUPAL_ROOT . '/modules/devel/kint/kint/Kint.class.php';
Kint::$maxLevels = 3;

I'd just suggest install var_dumper extension for Chrome and using {{ dump() }}

> Kint is terrible and with all the improvements that drupal 8 boasts I feel replacing krumo with this monstrosity will go down very badly with a lot of other developers too.

Krumo is no longer maintained, so staying with it isn't an option unfortunately.

Also, would krumo be better at handling the large objects we get in D8? On D7, krumo simply wasn't pushed as hard as kint is on D8.

Kint is NOT the only library for inspecting variables that devel 8.x supports.

Personally I strongly suggest to use the Symfony var-dumper plugin shipped with devel >= 8.x-1.0-beta1 (see code here)
You can read in #2820205: Devel debug tool for Drupal 8 - Kint alternatives how to enable and use devel var-dumper integration

See #2820205: Devel debug tool for Drupal 8 - Kint alternatives for more alternatives to kint (feel free to improve).

> Personally I strongly suggest to use the Symfony var-dumper plugin shipped with devel >= 8.x-1.0-beta1 (see code here)

Just tried it, and while it may be better able to cope with what we throw at it, I find it's a LOT harder to read the text!

The patch in #52 is better, but needs to be updated for Bootstrap's default anti-XSS filtering. Similar to how Krumo was patched in #2855666: Make Krumo compatible with XSS injection protection to drupal_set_message().

Not backporting this to D7.