mmucklo / krumo Goto Github PK

I'd like to see the keys in arrays visibly lined up to their parent element, so they are more comfortably viewable.

In the screenshot above for example, the items in the yellow (1) box would be visibly lined evenly up (which they currently already are), and the items in the red (2) boxes would be visibly lined up (which they currently are not).

The lining up would be to find the longest key length of the items in that array, and then str_pad($key, X, " ", STR_PAD_RIGHT); the other items within that array so they're all of equal length. This would make the rest of the stuff after it (i.e. the "String(4) => "some value here") appear lined up, essentially Left Justifying everything starting with the Type.

Hopefully I was able to convey what I meant well enough, lol.

Also, I've manually done it to my own krumo class, but it'd be nice if it was done to this repo version as well, so I (and possibly others) don't have to manually do it each update; I have changed all <strong> and <em> tags in the class to <span> classes. I prefer to use the CSS to do all of my styling. =)

krumo's output doesn't inlclude a class's private and protected properties, but var_dump does.
Is there anyway to enhance this?

$arr = array(
...
    'last'  => 'Doolis,'
...
);

should be:

$arr = array(
...
    'last'  => 'Doolis',
...
);

currently there's no way to extract the output from Krumo::_css() since it's private. If I want to save the krumo output into multiple log files, I run into the problem that I am not able to even unset the setting beeing used internally (boolean $_css) to determine wether the css/js output should be attached or not.

Packagist isn't updating to the newest release even after a week. Can we please fix this up so I can >composer update to the newest version 💯

Is it because there is no dev-master branch?

The Krumo project started as PHP4/PHP5 library. In PHP4 there is neither visibility scope nor explicit static methods. There were different ways to distinguish what is static, public, or non-public. The most obvious way was to use the phpdoc tags for @access and @static. These became moot with the complete PHP5 adoption and the retirement of PHP4. In PHP5 you explicitly declare what methods and properties are static, and what properties and methods are not public. That makes it meaningless to keep both @static and @access public -- static methods are explicitly declared as such, and the publicly accessible methods are obvious.

Let's drop these PHP4 legacy remnants.

Sorry if I'm missing it somewhere. ravern/kint has a option to make the dump display expanded by using a ! in front of the command

!Kint::dump($somearray) or !dd($somearray)

Is there such a option with krumo? Hopefully with a cleaner syntax than putting ! in front :-)

Command krumo::$skin = "default" doesn't work.
How does one change the skin?

Waaaay back at the beginning, many years ago, PHP libraries were distributed in a different way, with a different format. They were zipped and downloaded and everyone had to put them in their project. The VERSION file inside the package is a legacy remnant of that time.

The current implementation is not optimal, because the VERSION file is read for every single dump Krumo makes:

    public static function version()
    {
        return trim(file_get_contents(__DIR__ . "/VERSION"));
    }
...
            if ($showVersion) {
                $version = static::version();
                ...
            }

Let's just drop the VERSION file and move to a class constant, like this

class Krumo
{
    const VERSION = '0.6.1';
    ...

And then reference that constant in all the places where the version needs to be printed. It will be way way faster and with a smaller footprint since there will be no function calls, no trimming and no external file reading.

The INI-file configuration approach is really ancient. There are several problems with it:

• there is overhead in reading and parsing it
• by default there is no configuration file, you have to set it up by copying krumo.sample.ini
• if there is no configuration file loaded, there is no default configuration (although there are fallback values in Krumo::_config()

The whole INI file concept can be dropped. All the configurations can be operated from the class itself using Krumo::setConfig(), or something similar. Additionally, in most cases it is the same configuration that is being used across, and these settings are put as default values for the configuration, most people will just run with it without ever changing it.

If not for anything else, it will make the installation of the library easier since there will be one less operation to deal with when you do not have to mingle with krumo.sample.ini

There are a couple of minor tweaks required to make Krumo PHP 8.1 compliant. Fixes were landed in #64 and #65 which should address these issues. Please help the Krumo team test PHP 8.1 with the next branch and report any issues here. Pending a clean bill of health we will probably release Krumo 0.7.0 by the end of the week.

Thanks @driehle for bringing this to our attention.

I found this library is very useful with debugging, but I came across an issue where using k() would send a header to the user, resulting in any cookies set later in the code to not be set at all (as they are also sent in the header).

So is it possible to queue a message to appear with a function is called, so you could queue a list of messages to be called at once later on so cookies are still able to be set? This could be done by using an array and a foreach loop but I thought it maybe more use to have this as a native method. Any help would be appreciated.

I have a code with differents Exceptions being inherited from Exception.
When i krumo an exception, i'm sad because there is not the trace.
But if i cast the exception in an array, i see the trace. (I did that because the old krumo didn't work on objects)

class TestException extends \Exception { }

function test() {
  throw new TestException("bad");
}

try
{
  test();
}
catch (Exception $e)
{
  krumo($e); // Object with 4 elements
  krumo((array)$e); // Array with 7 elements, including Exceptiontrace 
}

I want to open a dialog about a recent commit that I just landed. I had a string the was named $array[" name"] that I was outputting with Krumo. When you output something that has a space in the name, it's VERY hard to see in the HTML. I spent about an hour trying to print out $array["name"] because that's what krumo was displaying, because it was masking the space.

The new commit puts in ␣ in the name to show there is a space there. This may cause some problems for other people though. Right now it will do that for ANY spaces in the key name. I never use spaces in key names, but other people might.

For example if you had the data $array["foo bar"] = 12; (note the TWO spaces) the HTML output will display it as one space. We may have a lot of users with a lot of ␣ in their output if they use spaces. I'd like to make this features "smart" so it's not confusing for users, but I'm not 100% sure how.

I've updated to the new version a few minutes ago, and instantly got this error on every kd() or k() I did.

Reverted to previous version 944b2fc6b301f9f53b9ec2cb80024dee691d998b and issues were gone.
So I guess something went wrong in your cleanup :)

Refactoring the code(even by the automatic phpStorm-refactor) to use some code styling standard.

The current code-styling is really not accepted in the community(Public Static Function??)...

I've noticed that after 50 characters, a string is truncated, and then revealed in a subsequent div. Is there any option in the class to prevent this and output the entire string?

I have a class that with some properties that are objects themselves (e.g. datetime objects, or mysqli objects). These objects are nor immediately initialised, they will only be initialised when needed.
When trying to use krumo on a object defined by a class that contains uninitialised objects as properties, an error message is generated and the script ends.

the error message is:

: Uncaught Error: Typed property PatentCollection::$dbReader must not be accessed before initialization in .....
Stack trace:
#0 /srv/http/ipdev/includes_2018/krumo-master/class.krumo.php(1083): ReflectionProperty->getValue()
#1 /srv/http/ipdev/includes_2018/krumo-master/class.krumo.php(1285): Krumo::_vars()
#2 /srv/http/ipdev/includes_2018/krumo-master/class.krumo.php(888): Krumo::_object()
#3 /srv/http/ipdev/includes_2018/krumo-master/class.krumo.php(530): Krumo::_dump()
#4 /srv/http/ipdev/includes_2018/krumo-master/class.krumo.php(1640): Krumo::dump()

I guess that this may be solved by testing with https://www.php.net/manual/en/reflectionproperty.isinitialized.php
If a property appears to be not initialised, skip processing it.

The krumo alias functions (krumo() and k()) that call krumo class methods are meant to be quick to type and use. I would argue that the extra KRUMO_RETURN makes it somewhat clumsy to type and use.

As an alternative, there can be a separate method that captures the output of krumo::dump() which requires no other arguments, like this

	/**
	* Return the dump information about a variable
	* @param mixed $data,...
	* @return string
	*/
	static function fetch($data)
	{
		// disabled ?
		//
		if (!self::_debug())
		{
			return false;
		}

		ob_start();
                call_user_func_array(
			array(self, 'dump'),
			func_get_args()
			);

                return ob_get_clean();
	}

It has a smaller footprint, and is faster to type because you type fewer characters and you do not have to switch cases to uppercase:

krumo($arr, KRUMO_RETURN);	// 26 chars, mixed case because of the uppercase constant
krumo::fetch($arr);		// 21 chars, all lowercase

You can also pass several arguments as once, like this:

$html = krumo::fetch($first, $second, $third);

This will capture the output for all three arguments at once. This is another advantage over KRUMO_RETURN, because conventional krumo::dump() expects KRUMO_RETURN to be exactly the second argument. This again makes it clumsy to use variadic arguments when you want to return the dump instead of print it, like this:

$html = krumo($first, KRUMO_RETURN) 
    . krumo($second, KRUMO_RETURN) 
    . krumo($third, KRUMO_RETURN);

We're encountering these kind of issues more and more with the latest versions of Krumo.

Strict Standards:  Non-static method ride\web\base\controller\IndexController::indexAction() should not be called statically in /Users/User/Sites/Site/vendor/mmucklo/krumo/class.krumo.php on line 1215

Fatal error:  Using $this when not in object context in /Users/User/Sites/Site/vendor/ride/web-base/src/ride/web/base/controller/IndexController.php on line8

This is the snippet of our code which breaks Krumo:

<?php

namespace ride\web\base\controller;

class IndexController extends AbstractController {

    public function indexAction() {
        $this->setTemplateView('base/index');
    }

}

My debug output contains <!-- and Krumo doesn't escape this therefore everything after it is a HTML comment. See excerpt below.

...onMouseOver="krumo.over(this);" onMouseOut="krumo.out(this);">
<a class="krumo-name"><!--</a> <em class="krumo-type">String(<strong class="krumo-string-length">7</strong>)</em>  =&gt;  <strong class="krumo-string">&amp;lt;!--</strong></div></li><li class="kru...

I propose that when you click while pressing Shift, it un/expands all the children "arrows".

I already have the code for old krumo, which seems to be still working.
Maybe there is a better way in naming and method.
(krumo.toggleAll is adapted from Arialdo Martini's code on a sourceforge ticket)

In krumo.js, add these 2 functions

    krumo.toggleAll = function(el) {
            var ul = el.parentNode.getElementsByTagName('ul');
            var parentMode = (ul[0].parentNode.style.display == 'none')
                                    ? 'block'
                                    : 'none';

            for (var i=0; i<ul.length; i++) {
                            ul[i].parentNode.style.display = parentMode;

            }
    }

    krumo.clique = function(event,el) {
        if (event.shiftKey) krumo.toggleAll(el);
        else krumo.toggle(el);
    }

In class.krumo.php, change the function called on onclick

    krumo.toggle(this);

with

    krumo.clique(event, this);

Hello,
Getting this error when calling dump:

#0 Undefined index: class:: called at [.../www/vendor/mmucklo/krumo/class.krumo.php:532]

It doesn't break anything, just letting you know Raygun throws this at me.

That's a repeating theme with some other issues I posted today: the project carries a lot of legacy from its PHP4 origins.

The KRUMO_DIR constant is a tool to load the JS and CSS files when they are exposed in web-accessible folders. Now you can do all of that with DIR which will allow you to find all the files and folders you need relevant to project root.

There are 5 references to KRUMO_DIR in the code and they can all be replaced with __DIR__.

This is another legacy remnant (as VERSION in #49) from the early days of the project. The library now has README.md, where you can read how to install the library. The file itself is really old, it's from 7 years ago and it has not been updated to the latest changes: neither is anything about Composer inside it nor is a reference to krumo.sample.ini which replaced krumo.ini

It is pointless to maintain and update that file, so it is just best if it is dropped.

I get the below warning when using krumo 0.7.0 in a php 8.2.8 environment

Deprecated: Use of "static" in callables is deprecated in ..../class.krumo.php on line 1522
Deprecated: Use of "static" in callables is deprecated in ..../class.krumo.php on line 1523

corresponding lines in class.krumo.php are:

1522            $_    = preg_replace_callback( "/^([ \t]+)/", "static::convert_whitespace", $_);
1523            $_    = preg_replace_callback( "/([ \t]+)$/", "static::convert_whitespace", $_);

I don't know when this will change from deprecated to forbidden, but it is probably relevant to tackle this before the change.

It seems that latest version can't deal with stdObjects.

I've took example code from documentation:

<?php

include 'vendor/autoload.php';

$x1->x2->x3->x4->x5->x6->x7->x8->x9 = 'X10';
krumo($x1);

It dumps out that this is stdObj and I can't open it.

... (Object) stdClass

While it is a good practice to put your composer.lock in version control so that you can track the state of your project deployed dependencies, that's not the same for libraries such as Krumo.

You can read a very well detailed explanation here: https://stackoverflow.com/a/21589454

So let's put composer.lock in .gitignore and drop it

@bobdenotter and I are planning on doing some major code refactoring and clean up. We hope to get Krumo in a better state, more readable state. We will also be looking at potential new features.

One thought I had was trying to detect a hex color code and displaying the actual color. Similar to how we detect unixtimes and translate them.

What else should Krumo have that it doesn't have today?

On my next branch I'm thinking about changing krumo.ini to krumo.ini.sample. Right now every time I do a git pull, or untar a release it overwrites my krumo.ini. A lot of other applications ship with a config.sample that requests the user rename. This will prevent the file over writing issue.

What does everyone else think?