In my app the footer is fixed and positioned at the bottom. The body had padding-bottom set as 133px. The debug bar overwrites that and sets it at 26px which interferes with my styling.

Can I suggest that the debug bar reads the padding first, and if it's not set or < 26 sets it, else ignores it?

After symfony/var-dumper was upgraded from v5.3.3 to v5.3.4 I'm getting:

Symfony\Component\VarDumper\Dumper\HtmlDumper::setDumpHeader(): Argument #1 ($header) must be of type string, null given, called in /Users/user/Documents/dev/project/vendor/maximebf/debugbar/src/DebugBar/DataFormatter/DebugBarVarDumper.php on line 288

Line 288 is $dumper->setDumpHeader(null);

Not sure what is going on here but I'm guessing this is a bug?

This restores compatibility with older PHP versions. v1.15.0 still allows PHP 5.3 or greater.

It'd be great if you could release this in a 1.15.x patch, I realise it'll be slightly annoying since other commits exist in master already which bump these requirements.

You can see the error here: https://travis-ci.org/lekoala/silverstripe-debugbar/jobs/508134678#L528

As I'm debugging my app, I found it desirable to know where duplicate SQL queries were being made so that I could consider where caching might be necessary.

This pull request adds the .phpdebugbar-widgets-sql-duplicate class to all queries that appear more than once. It also adds a .phpdebugbar-widgets-sql-duplicate-N class to each unique query that is duplicated.

This would fix an issue who uses MonologCollector with Monolog v2.

There is an issue when you try to use Bridge/MonologCollector because the abstract method signature has changed in Monolog v2. The diff: https://github.com/Seldaek/monolog/commit/06143b03e5c1598bfa6c6df65432010da0ecc28b#diff-d1d031ebe96084844fb53eb650bc404eR50

However, this change is a bit tricky. Because Monolog in v2 has increased PHP dependency to ^7.2, also added those void return type hints. So this change could break things for people who uses MonologCollector with PHP version lower than 7.1.

After the last update of your package, I have the following problem. When I'm loading a random webpage (debug-bar is enabled), every time I receive the following message.

A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://doggy.dev/packages/maximebf/php-debugbar/vendor/highlightjs/highlight.pack.js:1

Could you help me out with this issue?

Thanks in advance.

Would it be a good idea to clear the storage after a while? The collectors would keep on heaping up if you forget to do it by hand. I created a simple garbage collection method that runs every few requests that removes all files older then 24 hours. Would this be handy for all storages? See https://github.com/barryvdh/laravel-debugbar/commit/5aa061810042f432234ee062c7e2c01c9626cdc1

The memory_get_usage and memory_get_peak_usage functions have a $real_usage parameter. Update the MemoryCollector and PDOCollector collectors to allow the user to choose which type of memory usage to gather.

To recap, when $real_usage is set (and previously this was the hard-coded default), PHP returns the amount of memory allocated from the operating system by the PHP memory manager. This is typically done in large chunks of memory and is not very granular.

When $real_usage is cleared, PHP returns the amount of memory the user’s application has actually allocated from the PHP memory manager.

Clearing $real_usage has useful application especially for the PDOCollector. As an example, a query that returns only a few rows will often say that zero bytes were used when $real_usage is set. That’s because PHP was able to satisfy the memory requests from memory it had already allocated from the operating system. To contrast, the same query will show an expected few kilobytes of memory usage when $real_usage is set to false.

Hi,

We are new to php DebugBar and never have been used any other php debugger. After searching many debugger, we have found php DebugBar and install it on our system as per instructions given on the website.

We have installed this tool easily and no issue have been faced while installing. But when we merge the code (which is use to run DebugBar) in our simple test file then it giving us error that "Class 'DebugBar\StandardDebugBar' not found".

We have searched a lot to resolve this issue but nothing got.

Below is my code(test.php) where we are putting code:

My Project directory is: /projectname/test.php

And DebugBar directory is: /projectname/DebugBar/

Both the above things are in same project. DebugBar contains all the files downloaded at the the installing.

Can anyone provide the solution for this issue? Solution will be appreciated.

Would it be nice to show chained exceptions? This patch just adds the previous exception, the same as any other exception. Maybe it could be formatted differently or made clear it was chaining, so this is just an example.

When people are using the package, they have to define whether or not they want to include the vendor files. I guess this is okay, but wouldn't it be easier to avoid conflicting vendors? Loading jQuery 2 times wouldn't be optimal, but it doesn't really matter that much in development I think.

For jQuery, it should be possible to use jQuery.noConflict(true).

PhpDebugBar.jQuery = $.noConflict(true);
(function($) {
    //the debugbar code
})(PhpDebugBar.jQuery);

This would restore the original jQuery if possible and save it to a different variable (but that would be mapped to $ in the function. Only downside is that when you don't include the jquery from your vendors, it would remove all of jQuery, so you would always have to output jQuery, or do something like this (which doesn't seem really clean)

PhpDebugBar.jQuery = $.noConflict(true);
if(!jQuery){
    jQuery = PhpDebugBar.jQuery;
    $ = jQuery;
}

This would also prevent errors when older/newer jQuery versions are used (not that I encounted them, but could happen in the future)

This would also make it more of a 'drop-in' profiler tool, without much configuration (at least for the Laravel version)

Hello

I have tried using the Monolog Collector with version 3.0 and up of monolog. They changed of the "write" method, it no longer takes an array as a parameter. I solved the problem at home with an overload but if you want I can send you a PR

See https://github.com/Seldaek/monolog/blob/3.0.0-RC1/src/Monolog/Handler/AbstractProcessingHandler.php abstract protected function write(LogRecord $record): void;

to prevent big mess with user defined css, you could add display:block; in css files.

For example here : https://github.com/maximebf/php-debugbar/blob/master/src/DebugBar/Resources/widgets.css#L142

 dl.phpdebugbar-widgets-kvlist dd {
    margin-left: 160px;
    padding: 5px;
    border-top: 1px solid #eee;
    cursor: pointer;
    min-height: 17px;
    display:block;
  }

Yes @Tsdjimmy : I recently upgraded my PHP version from PHP7 to PHP8.. What is its solution..? **previous update composer Run composer update. Let me know if it worked.

Originally posted by @Tsdjimmy in https://github.com/maximebf/php-debugbar/issues/482#issuecomment-1005732455

I've read the docs, but in my project what happens is, that the following code just adds an additional DebugBar:

var debugbar = new PhpDebugBar.DebugBar();

debugbar.createIndicator('dbhost', 'cogs', 'connected db', 'right');

debugbar.setDataMap({
       'dbhost': ['time.duration_str', '0ms']
});

But of course I want to add the indicator to the existing bar.

What am I missing?

Issue is that we have other elements that have fixed positions at the bottom, so we either show them on top of debugbar (not nice looking) or we may miss those notifications when debugbar is open (again not cool due to missing info). Would be nice if we had an event we could observe that will tell us how much margin was added to the body to accommodate the debugbar size and add it accordingly to our own elements (for us it is some toast messages currently), or any other available info that we could use to adjust our layout when using it.

Just a really small thing i've noticed in your composer.json:

kriswallsmith/assetic is not maintained anymore. The new package should be assetic/framework from https://github.com/assetic-php/assetic

https://github.com/maximebf/php-debugbar/blob/c2e310320b7751a959f1590bb76530abbcfd2ce6/composer.json#L34

Keep up the great work. It helps alot!