I've placed the Kint folder in the root of my site (/home/mydomain/public_html/devtools/kint/Kint.class.php) so I can use it in whatever I'm working on.

I've directly added the include_once in a basic PHP file and tested it, and it worked great. I also removed the include from the file and added it in php.ini under auto_prepend_file which also worked.

However, whether I directly include or use auto_prepend in either one of my WordPress sites or Drupal sites, I just get a WSOD in either one of them. Even turning on error reporting via:

ini_set('display_errors', 1);
error_reporting(E_ALL|E_STRICT);

to try and troubleshoot why it's not working, results in no errors shown or logged, just a WSOD. In fact, I would prefer to keep it always enabled in php.ini but since it breaks my CMS's I have to disable it there.

Any suggestions?

Thanks!

Today, I've pushed something to jnvsor/kint/2.x-dev. I've been working on this for about 3 months now, I've basically rewritten all of Kint from the ground up.

I'd like this to be a starting point for a new major version of kint.

Bugfixes

#50 #175 #203 #197 #182 #177 #176 And probably more too...

Plugins

Lots of kint is very rigid. It's not designed with extensibility in mind. Most of the time you want to customize behaviour you have to edit kint source code yourself. In some of the best cases you have to dump new files inside kint's directory tree. These are bad things for anyone that wants to install an update.

My branch has a very extensive plugin system, to the point where you can pretty much replace both the parsing and rendering systems entirely without ever touching kint source code. This makes it possible for user provided solutions to certain feature requests: #107 (High prio for over 2 years! :D) #185 #94 #189 #87 : No longer applies: All the config system did was set a few properties on the kint class, you can do that from anywhere and have an easier time of it and a cleaner codebase

Additionally, because the parser/renderer/plugins etc are properly decoupled, it can be meaningfully unit tested. (This provides a start at #26)

In fact, it's so decoupled that if you want you can just call the parser and renderer and leave the main Kint class out of the loop entirely. (TODO: Some plugins get hardcoded info from Kint class, max_str_length in Kint_Object_Blob for example)

Internals

Kint master internals are Lovecraftian - peer at them too long and your sanity will be devoured by the great old ones.

Sarcasm aside - kint seems to have been developed very organically, which isn't necessarily bad but tends to add technical debt.

• We have a parser that outputs HTML, so if you want a decorator that doesn't you first have to unparse the HTML (See 2db0845f7a9ac642d09947e6f000e57e3b91ac64 )
• For some reason the parser is actually a child class of the data objects it's supposed to produce (???)
• The parser tries valliantly (And fails miserably) to prevent recursion "ghosts" on referenced arrays at the root level (See #203, #204) I've explained why this can't be done before, but that's a complex topic so I'll leave that for the other issues.
• Parser plugins almost exclusively produce html, so they're by definition reliant on the rich renderer. Checks on Kint::$enabledMode are strewn throught the parser system.
• It's a deck of cards. Everything is far too tightly coupled.

Long story short: I gutted everything. Now the parser just returns data, and the renderer takes that data and does whatever with it. The individual parts are all smaller: The rich renderer is 10% smaller, the parser is 40% smaller, the JS renderer (The example for the unparsing problem) is also 40% smaller.

Lots of special case code has been moved from the parser and main kint class into plugins where they belong: Backtrace handling, tabular display, etc

Basically it's a big-ass cleanup and for the most part easier to grep

The catch

Well not catch so much as caveats.

This is a work in progress

While it works fine for basic debugging, most of the plugins aren't ported yet. ClassStatics, ClassMethods, Microtime, Closure and Trace have all been ported, but there's still a small mountain worth of missing ones (Including things like the tabular display that used to be hardcoded in the parser)

The plain renderer also hasn't been ported yet, so PLAIN WHITESPACE and CLI output modes won't work till that's done.

It's got a lot of good stuff, but it's not feature parity (Yet)

This is not a stable API

I'm very happy with the way the parser works. I've put a lot of thought into it and it seems to work beautifully. The problem is the renderer.

The renderer needs to know how to take data and turn it into output. Currently, the parser plugins can add a "Class" to a representation (Tab) and the renderer maps that class to a renderer plugin. This works fine but there's no way to alter the way a header is rendered, only a tab. I intend to make large changes to the plugin system until it's working well enough.

Here be monsters.

It's slow

Last I checked the parser was some 1000% faster than the old parser, but the renderer is significantly slower and it all evens out at a 50% slowdown (Last I checked... I've changed a lot since then)

I'm not actually sure why this is - when I stub out all the relevant functions so it's just outputting enough to let me know it's actually outputting at all, it's still far slower. I'm guessing it's some PHP internal optimization - probably something in static methods that PHP deems pure so it caches the result or some such.

All that said, it's not too slow - I don't see any difference in normal use. The pliability benefits of the new plugin system outweigh a speed difference I can't tell exists without tools. I'll take a closer look after I'm satisfied with the API.

It works in PHP 5.1

While I'd like to make a smiley and say this is just a joke about kint's strict version requirements (next month 5.1 will have been EOL for a decade) the truth is it's so old I couldn't find a way to get it working so while it absolutely should work on 5.1 I have NO way of proving that. If anyone can test it for me (Or show me an easy way to do it myself) that would be a big help.

The code style

Code style conversations are always purely subjective. Subjective enough to turn into flame wars so I'm not going to bother rooting for the code style I use here, or against the code style in master.

Instead I'm going to argue on consistency. Consistent code style is good right? We can agree on that right? Right?...

Anyway, I'm not very consistent. I drift between K&R, PSR, trololol-minified-php-ftw, and generally don't have anything consistent enough to write my own code style rules. So I let my computer do it for me.

php-cs-fixer guarantees consistent code. It also lets me write whatever sloppy nonsense I want to then fix it with a simple command. Because it's a program, we could also enforce it alongside a test suite with CI.

There are other purported php formatters out there but of the few I've tried php-cs-fixer is the best (One of them actually changed method naming styles and broke a system on me once... Yay) and the defaults are fairly sane and PSR compliant. Most importantly, I personally can attest that if I stuck with master's code style I'd have been at it for another 3 months :)

What needs to be done

If anyone has any ideas that could clean up the architecture I've made here that would be great

• I want to tweak the rendering system a bit so that plugins can effect headers as well as tabs, so I'll probably end up gutting that for the fifth time.
• It needs to be tested for 5.1 compat
• I need to find out what's going on with rendering performance. This should wait until all plugins are ported as that can effect performance too.
• A lot of plugins need to be ported
• A test suite would be nice, but lets get things working first.
• I want to decouple a few things that shouldn't be in the main Kint class (max_str_length should probably be on the renderer not the Kint class, the Trace plugin should have a configurable alias tracking system, etc)

There's the $parser_plugin_whitelist and there's the BlacklistPlugin with quite some occurrences of these problematic strings. Of course also in the test. I guess we can't simply replace the one strings provided by PHPUnit but maybe let's start by providing alternatives for the ones we currently have in Kint and deprecate the old ones for now.

use light-grey color (#ddd) makes the minitrace very difficult to read in almost all kint themes. The only theme in which use #ddd has sense is "solarized-dark"

Calling s() from console works great in Linux, however in Windows it doesn't show the unicode table drawing characters correctly.

I accept anything ranging between:
a) disable these characters altogether,
b) replace them with ordinary dashes and pipelines, or c) create a fix to show them correctly on Windows.

I get this error. As I noticed, this only applies to static private property

An exception (ReflectionException) was thrown in phar://<ROOT>/wp-content/plugins/zu-plus/includes/debug/kint.phar/src/Parser/ClassStaticsPlugin.php on line 94 while executing Kint Parser Plugin "Kint\Parser\ClassStaticsPlugin". Error message: Cannot access non-public member zu_Plus::$zukit_root

What could be the problem?

As discussed in https://github.com/kint-php/kint/issues/203 this is recursion tracking by reference. The array and object references are collected in a "register" and if they are encountered a second time, that is considered a recursion.

One of the benefits of this approach is that arrays are never tainted with markers, and at any time a plugin can pick the parsed array variable as it is.

I do use hashes to address the object references, but that's because it is faster that way instead of traversing the whole list of knownObjects.

@jnvsor has some concerns about memory leaks and performance, and I'll be looking forward for ways how to test these cases. So far I've only done the examples from https://github.com/kint-php/kint/issues/203 and the ParserTest.php unit test, and both work OK.

Structurally, the output of the recursions is the same as from var_dump(). Here's what I used to compare:

<?php

include 'vendor/autoload.php';

$a = ["Array 1"];
$b = ["Array 2"];
$a[] = &$b;
$b[] = &$a;

!d($a);
!d($b);

var_dump($a);
var_dump($b);

$r = (object) ['a' => 23, 'b' => 45];
$r->c =& $r;
!d($r);

var_dump($r);

There is a screenshot of the output here

I have file tst.php

require_once 'vendor/autoload.php';
d([1, 2, 3]);

run this file in cli with php-kint v3

and with php-kint v1

Why data displaying is not correct in php-kint v3?

Don't know why exactly but:

$a = ["Array 1"];
$b = ["Array 2"];
$a[] = &$b;
$b[] = &$a;

d($a);
d($b);

This shows the marker in $a in the second call.

I'm doing an experimental overhaul of the parser (It's looking good) so I'll probably come across more of these things.

When you for instance have an array of objects, you don't always want to see the contents of the objects, just the headers.

I imagine the icon to look like 3 horizontal lines

// in private function _getAllItems($url)
// from class Alienware extends \GiveMeSomeGoodNews\Core\Controller
\Kint::dump( $items ); //
var_dump( $items );
// ...

serialize()

a:4:{i:0;a:4:{s:5:"title";s:48:"Magicka: Wizard Wars Alienware Robe Key Giveaway";s:4:"guid";s:40:"ddcafe286003d79e0083dc32234b88a874c68aba";s:11:"description";s:513:"Go down in a blaze of glory with this exclusive Alienware Arena key for the Alienated Speedster robe. At the cost of 100 HP, you'll gain a 4% speed boost to outmaneuver your enemies and claim victory over their burnt corpses. With amazing Steam reviews like this: 8 elements, loads of fun, and beautiful C-H-A-O-S! Seriously get this game ASAP-[Nii-Wizards] Bacitoto Why haven't you gotten your exclusive robe and joined the action yet? Additional batch of keys added! About Magicka: Wizard Wars: Mag...";s:7:"pubDate";s:10:"1411954938";}i:1;a:4:{s:5:"title";s:47:"Kill The Bad Guy 33 Steam Discount Key Giveaway";s:4:"guid";s:40:"c3af1d6c9caae31d9f3058d51cd90c6808f2d560";s:11:"description";s:502:"Locate the target, execute a brilliantly sadistic plan, and watch the end result with this 33% Steam Discount for Kill The Bad Guy. Serving justice is just the side effect. Executing a brilliant plan intent on inflicting brutal pain is the real objective in Kill The Bad Guy. About Kill The Bad Guy: Does everyone deserve a second chance? Can crimes ever be forgotten? Hiding behind the mask of the average man on the street, and furtively blending into the background, many war criminals, ex-Mafia...";s:7:"pubDate";s:10:"1411954938";}i:2;a:4:{s:5:"title";s:39:"Broforce 25 Steam Discount Key Giveaway";s:4:"guid";s:40:"a4f301e1f8fc8d3414c2be65cd23f658ed55bebc";s:11:"description";s:504:"Never has it been more fun to turn the rest of the world into your own personal Brodom. Unleash liberty and freedom onto the rest of the world with this 25% Steam discount for Broforce. Bro with others or all on your own as the world once again turns to Broforce to raise the world to Brocon 1. So, what are you waiting for, a Brovitation? About Broforce: When evil threatens the world, the world calls on Broforce - an under-funded, over-powered paramilitary organization dealing exclusively in exce...";s:7:"pubDate";s:10:"1411954938";}i:3;a:4:{s:5:"title";s:45:"Shadow Warrior 75 Steam Discount Key Giveaway";s:4:"guid";s:40:"1764699fa1773b09b3e2d79558784d6f05b559b0";s:11:"description";s:505:"Need to stop a demonic invasion? A combination of guns, katana, magic, and wit are your weapons. Take this 75% Steam discount code for Shadow Warrior and decide what combination of death you will bring to the hoards of invading demons. About Shadow Warrior: Shadow Warrior tells the offbeat tale of Zilla Enterprise’s corporate shogun, Lo Wang, who is ordered by his employer to track down and acquire a legendary blade known as the Nobitsura Kage. Forced into a timeless battle, Lo Wang learns of th...";s:7:"pubDate";s:10:"1411954938";}}

Psalm has quite a few false positives, but most of them can be fixed with well positioned typehints (All of which are prefixed @psalm-X in code)

Some of these issues can't be fixed with typehints, or are clear bugs in psalm that probably shouldn't be fixed with typehints. Because of these we can't make static analysis required in CI. For now this is just a "todo list" and not high priority, since the code still works without it.

• vimeo/psalm#4509
• vimeo/psalm#8603
• vimeo/psalm#8719

Hi,

While working on a project and validating the HTML code of the page with the W3C Markup Validation Service, I noticed that the Kint library had some HTML errors:

Possible solution for the <style> tag error

The <style> tag must be contained in the <head> tag. So we could add it dynamically through JavaScript.

Context

• PHP: v8.1.2
• Kint: v5.0.1 (latest)
• Browser: Google Chrome v107.0.5304.107
• OS: Windows 10