maximebf / php-debugbar Goto Github PK
View Code? Open in Web Editor NEWDebug bar for PHP
Home Page: phpdebugbar.com
License: MIT License
Debug bar for PHP
Home Page: phpdebugbar.com
License: MIT License
I've noticed that if we use another version of FontAwesome in our project, it gets replaced by php-debugbar's embedded one. Basically it overwrites the path where FontAwesome font will loaded through @font-face
rule.
So if we're using a newer version of FontAwesome in our project, all new icons are broken until php-debugbar also update its own FontAwesome bundle.
Ideally we would have an option to didn't embed FontAwesome, leaving that responsibility to our application.
Right now the template widget doesn't have to possibiltiy to add data. Would it be possible to add data key/values to the templatewidget?
A mix with the current template widget and the variable widget, when you click on the title, the variable list opens up (similar to sql queries, but named keys and prettified values)
I'm not sure every template supports it, but at least Smart, Twig and Blade have variables I'm currently displaying all views as a variable widget (and before with message widget), but the downside is that longer template names are cut off, possible timing data isn't shown and alle variables are just one big item, would be nicer if that was just a list so individual items could be opened.
Whenever I load a page in which the debugbar is initially closed (completely closed into the php icon, not minimized), and then I open it, the header tabs display in their text version, which causes them to overflow the header. Of course, this only happens when there are enough tabs to cause them to need to switch to the no-text, icon-only, mini-design versions.
(In that image, "Request" and "Guest" are both tabs that should be in the header.) Either resizing the browser, or reloading the page with the debugbar open causes the tabs to properly switch to icon-only mode. But this is an extra step that is annoying. Seems like the resize handler should be fired when the debugbar is initially opened. (I'm using Chrome 32.)
Uncaught ReferenceError: hljs is not defined (widgets.js:57)
Versions:
@barryvdh, this is while using: https://github.com/barryvdh/laravel-debugbar
TraceablePDO.php, line 40
The errorInfo method calls $this->errorInfo(), rather than $this->pdo->errorInfo(), causing infinite recursion.
How can I reduce the panel font size (it is quite large for my liking) ;-)
When I want to see Database info and click on the tab, it opens. But it would be nice/faster to be able to close it also, by clicking on it again. Feels more natural then having to click the tiny x in the corner.
What do you think?
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 barryvdh/laravel-debugbar@5aa0618
There is a problem in profiling of Twig templates that causes absence of profiling data if a whole page (from to ) is in template. It happens because you need to run $debugbarRenderer->render() and $debugbarRenderer->renderHead() before you run $twig->render(...)
Is there any way to solve this?
In http://phpdebugbar.com/docs/bridge-collectors.html#twig you have $debugbar->addCollector(new DebugBar\Bridge\Twig\TwigDataCollector($env));
But it is not TwigDataCollector
but TwigCollector
Hey,
Thanks for this awesome piece of software. Lovin' it!
I have one small issue with the key/value list.
The key column in the kvlist widget is now fixed to 140px.
When I use the Config collector some (well, actually most) of my keys are wider than 140px and will interfere with the values behind it.
Adding:
min-width: 140px;
width: auto;
to dl.phpdebugbar-widgets-kvlist dt in widgets.css should do the trick.
The documentation says we should call <?php echo $renderer->renderHead() ?>
in the <head>
of our page, but presumably we would want to put <?php echo $renderer->render() ?>
as late as possible, just before </body>
so that our collectors can finish.
However, if jQuery
is included at the top of our page, and jQuery.noConflict
isn't called until the end, then everything in-between (our actual page content) will be using the wrong version of jQuery.
I think jQuery.noConflict
should be moved to the bottom of renderHead()
instead of at the top of render()
. This way it will be available to all the JS assets, but not longer.
Just a little thought to improve integration with frameworks.
You write directly to the session/headers with php, which is fine, but some frameworks (like Laravel) use different Session drivers and Symfony to control the headers on responses etc.
I can override the functions when extending the DebugBar (like here https://github.com/barryvdh/laravel-debugbar/blob/master/src/Barryvdh/Debugbar/LaravelDebugBar.php) but now I have to replace the entire class where this is used. It would be easier if there was also some concept of a 'driver' (which use native php function by default), so a specific Laravel/Symfony driver can be created, that just sets/gets/checks the session etc, so that only that has to be replaced.
Or perhaps just some functions (sessionSet/Get/Has() and sendHeaders($array) for example). This way I don't have to check every small change, but only those implementations.
When you include phpdebugbar, it breaks the local storage mechanism. Originally, the issues was spotted in Firefox, however, Chrome was OK. After some investigations, I've reproduced the issue in every browser, thanks jsfiddle. This code doesn't work, localStorage is set to 'undefined'
alert(typeof(localStorage));
if (typeof(localStorage) == 'undefined') {
// provide mock localStorage object for dumb browsers
var localStorage = {
setItem: function(key, value) {},
getItem: function(key) { return null; }
};
}
localStorage.setItem('test', 'yes');
alert(localStorage.getItem('test'));
http://jsfiddle.net/kPRRy/
but if you remove this piece
if (typeof(localStorage) == 'undefined') {
// provide mock localStorage object for dumb browsers
var localStorage = {
setItem: function(key, value) {},
getItem: function(key) { return null; }
};
}
it magically works
http://jsfiddle.net/trGZU/
Can we introduce a better way to mock localStorage?
Removing var in front of localStorage works for me
http://jsfiddle.net/apXg5/
Hello,
I was looking into the OpenHandler and Storages to save the data to a file instead of the headers (or session), but I have a few questions.
It doesn't really matter much I guess, but now it seems to make a lot of files, without cleaning them up. (And the find function isn't really easy to create with the default Laravel Cache manager)
Thanks!
Is it possible to have the PDO data collector automatically substitute the params for each query into the query string?
When you have multiple collections, an hash is shown in a dropdown. This is very cool functionality, but the hash is pretty large (and doesn't mean anything to me), so would it be possible to make it shorter?
For ajax requests it could just be something like the time (11:01:45) or an ascending number instead of the hash?
Could this project's front-end dependencies be updated ? Particularly the FontAwesome set which โ in the version in use โ uses generic class names that clash with applications the debug bar is installed on.
Ideally I think this project's dependencies should be managed by Bower in order for them to be kept up to date.
The same thing can be said about the jQuery dependency that is now more than two years (!!) old.
We use font-awesome 4.1.0 and make use of the new icons. These icons do not appear because your fontawesome 4.0.3 css overrides our 4.1.0 fontawesome css.
I really like debugbar! And I really like Laravel. There is a collector for the Slim Framework. Will there be a collector for Laravel in the near future too?
Thanks!
When using the RequestDataCollector objects that are put into session are flattened (seemingly for display/memory limiting purposes) - The problem is that it actually modifies the session variables to hold these new flat strings. The line of code that breaks it is in the base DataCollector line 39:
foreach ($vars as &$v) {
Removal of the & fixes the problem but I'm not sure if that is the desired solution.
When viewing messages with var_dumps, I often want to copy the message to clipboard, but the message collapse when clicking, so that makes it hard to select the data.
What would you think on adding a copy-to-clipboard feature?
Either by a button/link, for example with https://github.com/zeroclipboard/ZeroClipboard or using something similar to this http://stackoverflow.com/questions/17527870/how-does-trello-access-the-users-clipboard to use Ctrl+C to copy the last clicked message/query etc.
On a page with multiple ajax calls, I want the first dataset (First request) to be selected by default. Right now the last request is selected by default.
How can we achieve this ?
In the latest commit (6fd6a67), most of the vendor files were removed (which is good), but also the fonts from font-awesome.
Could you add those back? The icons don't work without them.
I'm trying to implement the AJAX data collecting with the following collectors set up:
// Add Request collector (for post, get, session and server)
$debugbar->addCollector(new DebugBar\DataCollector\RequestDataCollector());
// Add PDO collector for DB requests
$pdo = new DebugBar\DataCollector\PDO\TraceablePDO(DB::getInstance());
$debugbar->addCollector(new DebugBar\DataCollector\PDO\PDOCollector($pdo));
For AJAX calls I've set the option:
$debugbar->sendDataInHeaders();
Now, when loading the page and its subsequently AJAX request the data collecting for the Requests is working perfect! However no PDO activity seems to be collected. There is a "phpdebugbar-1" header present. And as far as I can read the actual header the number of statements is 0.
Any ideas how to get this to work? Would be a massive help! Thanks.
Thanks for good debug bar.
But, if debug bar is enabled, browser`s rendering is too slow.
Chrome show 'waiting for localhost'.
Firefox show 'Will you stop script(highlight.pack.js)?'.
I think that it`s caused by highlight.pack.js.
Is highlight.pack.js important?
Right now, formatting of variables is done by just outputting print_r($var, true). This works most of the time, but there are some edge cases that don't really work.
For example, dumping the entire Laravel application container would fail because of recursion/size (but you probably aren't going to do that), but also dumping a var that might contain binary data. This fails because it can't be json_encoded.
Also, var_dump might provide more information (string size etc).
What would you thinking about using a third-party formatter? For example Kint: https://github.com/raveren/kint
This has a kintLite function in the current version (and will move to a 'plain' parser, which in 1.0 which has the same result)
I suggest we create a DebugBar\Dumper class, which has a (static?) method to dump a variable (ie. formatVar), which can be used to replace the print_r in MessageCollector and the formatVar in DataCollector.
This way we can easily switch out the formatter if there is a better one.
Until kint is stable, we could easily copy the kintLite function and use that in the Dumper class.
See https://github.com/raveren/kint/blob/master/Kint.class.php#L619
Suggested function would be DebugBar\Dumper::formatVar($var, $depth)
Opening the debug bar hides the bottom of the page. The page-bottom should be offset this much in order to allow viewing of both at the same time.
Possible solution: the body should have padding-bottom INCREASED by the value returned by window.getComputedStyle(document.getElementsByClassName('phpdebugbar').item(0)).height
when the debug bar is
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)
Can we have a new tag for the current state please?
Hey guys,
thanks for the DebugBar - unfortunately it seems that it doesn't supported Propel 2 (the new major version of Propel).
Is support for it coming anytime soon?
Thanks.
In the example here:
http://phpdebugbar.com/docs/base-collectors.html#exceptions
we define an ExceptionsCollector, but in order to add exceptions to the collector, we have to insert an addException() call in the catch statement for each potential exception.
Adding this in my own code would be annoying, but not insurmountable. However, if I want to log caught exceptions in libraries I'm using, I am left with a great challenge, as I certainly do not want to modify every exception catch clause in my third party libraries. Theoretically, I should not be concerned with caught exception in third party code, but in practice, I sometimes am very concerned.
I'm wondering if there is a way to make all exceptions report to the ExceptionCollector, without adding code to every single catch clause. I realize this is a tall order, since a caught exception, by its very nature, is not visible to any code above the catch clause. But I thought it might still be worth thinking about, at least.
One thought I had was if we could modify the constructor for the Exception base class, which all other exceptions extend, we could inject in there a call to the addException() method. That's not something I find myself attempting to do on a regular, day-to-day basis, but apparently it's called monkey patching, and is not supported in PHP proper, but only with RunKit. Honestly, that looks like a can of worms I'm not sure I want to open. And I'm not even sure it would work.
Also, I guess if you modify the Exception constructor like that, and then addException() itself threw an exception, you'd have a nasty little infinite loop, wouldn't you?
So, here's what I'm wondering. Has anyone tried something like what I described above? If so, did it work? If not, do you think it might? Is my concern about an infinite loop valid? Is there another, better way to do this? Is this something anyone else cares about, or am I being peculiar here?
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.
Could you help me out with this issue?
Thanks in advance.
If I read the docs correctly, it's possible to handle ajax requests that return HTML by embedding the JS like so:
<p>my ajax content</p>
<?php echo $renderer->render(false) ?>
But in my case, I have AJAX requests returning JSON content, so I can't embed JS inside them.
Is there any way to have the debug bar update with the data of the AJAX request?
If not, I was thinking of several possibilities:
Any other idea? Any preference?
Wouldn't it make more sense to only display the count next to a tab, when the count > 0? This way it would also 'pop' out more when there is a log/exception etc.
What do you think? Should I create a PR for this?
It looks like the problem from #107 issue wasn't fixed by yesterday's commit.
ReferenceError: hljs is not defined
if (hljs) {
There are to many generic css class-names that makes that i cant use it and i bet more people will have the same issues. ALL class-classes needs to be prefixed to avoid conflicts with existing css.
Examples for none-prefixed classes:
active
list-item
key
value
toolbar
icon-search
status
sql
etc..
Not very important, but it could be a nice feature to add syntax highlighting to SQL queries and stacktraces.
Most popular seem to be https://github.com/isagalaev/highlight.js (with bower support or custom packages with only a few languages), alternatives are: https://github.com/ccampbell/rainbow and https://code.google.com/p/google-code-prettify/
I created a new branch "serverhandler" where the goal is to have the possibility to execute commands on the server from the debugbar.
The code is already implemented but I would love some feedback before merging.
The open handler is moved to the new architecture.
The Bridge\CacheCache\CacheCacheCollector (moved from Bridge\CacheCacheCollector) also implements the new ServerHandler\ServerHandlerFactoryInterface
Collectors which implement one of the interfaces in the ServerHandler namespace will automatically be registered as handlers when a ServerHandler\Server is instanciated
Combined with the new AssetProvider interface, collectors can provide their own javascript interface and server handlers. This can lead to very powerful widgets.
For example, the CacheCache collector, uses the cache widgets which has a "clear" and "clear key" buttons.
In javascript, you can use PhpDebugBar.DebugBar.instance.callServer('handlername', 'commandname', {...data...}, callback) to call the server
JavascriptRenderer::setServerHandlerUrl() must be called before these features become available.
The demo is also updated.
I am working on a project that connects to two databases (one for read and one for write). Is there a way to trace the two connections as one? This is the error that happens right now when I try to assign two PDO connections.
Fatal error: Uncaught exception 'DebugBar\DebugBarException' with message ''pdo' is already a registered collector'
Thanks!
I want to extend timeline by some additional data - parameters, in my case.
It would be great to show the parameters when we click on them, to prevent veeeery long labels in timeline...
I guess it could be some additional optional param in startMeasure
method...
Initial discussion was here:
barryvdh/laravel-debugbar#124
Hello, I am experiencing a weird issue tracking Ajax calls:
it looks like JQuery events and subsequent ajax calls they trigger are properly reported in the Debugbar when they're set on first page render... but for some reasons Debugbar doesn't track any Ajax call I trigger attaching functions to events at a later time.
Now, I'm not so good at JS/JQuery and I'm having a hard time figuring out if that's the normal behaviour or I'm having issues in the way my scripts are built (which, by the way, are doing what they're supposed to).
Thanks for any help you might provide!
The error occurs on line 45 of src/DebugBar/DataCollector/DataCollector.php
.
I'm using DebugBar with barryvdh's laravel-debugbar.
I think it is probably failing on a BLOB column in MySQL (Asterisk's recording
column on the voicemail_messages
table.) Definitely not a common problem, and I'm not sure if it's an issue with php-debugbar or @barryvdh's laravel-debugbar to be honest.
Do you think there is a sane way to add collectors for cache operations (add, set, get, incr) etc to the debug bar?
The class Product in demo/bridge/doctrine/product/ is not namespaced and, in my project, therefore collides with another class that I deliberately dont want to move out of the root namespace.
Could this be corrected, as it is just a demo anyway?
I installed this package to get a debug bar. But instead I got a debug bar and something else (Kint) that reformats my xdebug output. I didn't want it and didn't ask for it. I would recommend removing it. Don't install things for users that they aren't expecting or asking for, no matter how useful of a tool it may be.
What is it "PhpInfoCollector" class ?
I see php file, is it empty class ? Does it do nothing?
class PhpInfoCollector extends DataCollector
{
/**
* {@inheritDoc}
*/
public function collect()
{
return array(
'version' => PHP_VERSION
);
}
/**
* {@inheritDoc}
*/
public function getName()
{
return 'php';
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.