Problem/Motivation

The krumo library is not maintained anymore, and it's getting outdated.
* Kint is a modern good alternative. http://raveren.github.io/kint/
* It's GPL licensed.
* Adopted by other PHP Frameworks
* It's regularly maintained by the author, and he's open to add new features and collaborate with us.

Proposed Resolution

* Replacing Krumo is being considered. But in the meanwhile, it will live side-by-side with Krumo, having different aliases. (ksm instead of dsm, for example).
* Implementing Kint as a submodule in devel 8.x
* Although some aliases for Kint are provided. It's encouraged the use of kint_require(), and using Kint class directly. For example Kint::dump($var)

Original report

Hello! I have sandbox with working module, that adds Kint debug tool to drupal. Module can let you use functions like kint() and kint_trace(). Also it allows to use Kint class everywhere.

Kint is not under GPL license, so i fork it on github and did some changes for more Drupal-friendly and used Kint as library.

Is it possible to add this module as submodule of Devel? I would get help with review of module and some help for adapting this to Devel, if you think this is a good idea.

Please give me some feedback and your think about it. I would glad to work on this module as a part of Devel.

PS: D8 branch of sandbox just now is very crappy and has issues related to licensing. But D7 branch works perfect.
PPS: Sorry for my bad english (:

Files: 
CommentFileSizeAuthor
#56 krumo path.png37.88 KBjoachim
#52 devel-kint-integration-d7-2034919-52.patch171.99 KBpeterpoe
PASSED: [[SimpleTest]]: [MySQL] 36 pass(es). View
#50 devel-kint-integration-d7-2034919-50.patch177.52 KBmarkdorison
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in devel-kint-integration-d7-2034919-50.patch. View
#47 devel-kint-integration-d7-2034919-47.patch177.52 KBpeterpoe
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in devel-kint-integration-d7-2034919-47.patch. View
#37 devel_entity_tab_fix_2034919_37.patch891 bytescorbacho
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch devel_entity_tab_fix_2034919_37.patch. Unable to apply patch. See the log in the details link for more information. View
#30 devel-kint-integration-2034919-30.patch301.09 KBcorbacho
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Invalid patch format in devel-kint-integration-2034919-30.patch. View
#26 devel-kint-integration-2034919-26.patch126.69 KBcorbacho
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 45 pass(es). View
#22 content_entity_example.png252.19 KBBerdir
#15 Extend d8.kal 2014-02-23 13-54-04 2014-02-23 15-59-22.jpg89.94 KBcorbacho

Comments

davidmac’s picture

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.

danilenko_dn’s picture

Issue summary: View changes
danilenko_dn’s picture

Thanks! I've replaced link in issue body with correct.

Yep, i'd like to promote module to a full project, but for now i haven't enough time for this. But definitely will in future ;)

moshe weitzman’s picture

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

davidmac’s picture

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

pcambra’s picture

corbacho’s picture

+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

joelpittet’s picture

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

moshe weitzman’s picture

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.

moshe weitzman’s picture

Wow, Kint just got whitelisted!

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

moshe weitzman’s picture

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.

donquixote’s picture

moshe weitzman’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Active » Needs review

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.

danilenko_dn’s picture

@moshe weitzman, it is awesome! Can i participate developing?

btw, Kint 0.9 is old, new distribution is in 1.0.0-wip branch. Also i fiorked and modified Kint distribution (pull request on GitHub) and my modifications allows to use Kint without editing original Kint distribution and rewriting Kint's settings for customizations. If Rokas will accept my pull request - it will be easy to add kint as alternative tool for debugging into Devel.

corbacho’s picture

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 ?

moshe weitzman’s picture

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

pcambra’s picture

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.

moshe weitzman’s picture

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.

joelpittet’s picture

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

pcambra’s picture

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.

Berdir’s picture

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 ;)

Berdir’s picture

FileSize
252.19 KB

Uhm. Now with 100% more screenshots.

pcambra’s picture

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

Cottser’s picture

Adding a related issue for Twig integration.

moshe weitzman’s picture

Component: devel » kint
corbacho’s picture

FileSize
126.69 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 45 pass(es). View

@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 ?

moshe weitzman’s picture

Status: Needs review » Postponed (maintainer needs more info)

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?

corbacho’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
126.69 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 45 pass(es). View

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

moshe weitzman’s picture

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

corbacho’s picture

FileSize
301.09 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Invalid patch format in devel-kint-integration-2034919-30.patch. View

Oops. Now with kint (1.0.0-wip)

Status: Needs review » Needs work

The last submitted patch, 30: devel-kint-integration-2034919-30.patch, failed testing.

donquixote’s picture

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)

corbacho’s picture

Status: Needs work » Needs review

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

  • Commit 580c360 on 8.x-1.x authored by corbacho, committed by moshe weitzman:
    Issue #2034919 by corbacho | danilenko_dn: Kint debug tool for Drupal.
    
moshe weitzman’s picture

Status: Needs review » Fixed

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.

corbacho’s picture

Issue summary: View changes
Status: Fixed » Needs review
FileSize
926 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch devel_entity_tab_fix_2034919_36.patch. Unable to apply patch. See the log in the details link for more information. View

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.

corbacho’s picture

Issue summary: View changes
FileSize
891 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch devel_entity_tab_fix_2034919_37.patch. Unable to apply patch. See the log in the details link for more information. View

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

moshe weitzman’s picture

Status: Needs review » Fixed

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.

ivanjaros’s picture

I just hope there will soon be the orange Krumo theme available because I really hate the default styling :D

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

The last submitted patch, 36: devel_entity_tab_fix_2034919_36.patch, failed testing.

Status: Closed (fixed) » Needs work

The last submitted patch, 37: devel_entity_tab_fix_2034919_37.patch, failed testing.

pcambra’s picture

Status: Needs work » Closed (fixed)
JordanMagnuson’s picture

Are there any plans to backport this to Drupal 7?

moshe weitzman’s picture

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

peterpoe’s picture

Version: 8.x-1.x-dev » 7.x-1.x-dev
Status: Closed (fixed) » Needs review
FileSize
177.52 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in devel-kint-integration-d7-2034919-47.patch. View

D7 backport here.

Status: Needs review » Needs work

The last submitted patch, 47: devel-kint-integration-d7-2034919-47.patch, failed testing.

moonray’s picture

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

markdorison’s picture

Status: Needs work » Needs review
FileSize
177.52 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in devel-kint-integration-d7-2034919-50.patch. View

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

Status: Needs review » Needs work

The last submitted patch, 50: devel-kint-integration-d7-2034919-50.patch, failed testing.

peterpoe’s picture

Status: Needs work » Needs review
FileSize
171.99 KB
PASSED: [[SimpleTest]]: [MySQL] 36 pass(es). View

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

joachim’s picture

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".

ptmkenny’s picture

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.

Derimagia’s picture

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

joachim’s picture

Issue summary: View changes
FileSize
37.88 KB

> @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

Derimagia’s picture

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

attheshow’s picture

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?

chriscalip’s picture

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

Cottser’s picture

@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…

chriscalip’s picture

@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.

markledger’s picture

@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() }}

joachim’s picture

> 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.

willzyx’s picture

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).

joachim’s picture

> 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!