Even though disabled, it will still increase the memory footprint of objects and the framework on live sites. Only installing it as require-dev would prevent that from happening.

Using "click to see fields", (besides it could be a tiny bit more nicely formatted :P ), it would be awesome if it showed the results of the query in the table?
At least, when it's a limit 1 query?

Is there any plans to make this compatible with 7.2. I notice there is a Object extends in DebugBar.php. Would this be the only amend to get it working with 7.2??

I've noticed the widget.css file was added back. We removed it previously because it was overriding the core package and moved everything to our own extension stylesheet. javascript/sqlqueries/widget.css

Commit

Use of getenv is now not suggested, but instead we should use SilverStripe\Core\Environment::getEnv() to ensure thread safe compatibility.

When logging out, or just manually destroying the session, the SilverStripeCollector attempts to loop over a null result of getting the session, causing a Warning to be thrown.

The master branch of this module supports SS4 but there's no tagged release. Any idea when this will happen?

Affects v1.0 and v1.1

https://travis-ci.org/lekoala/silverstripe-debugbar/jobs/508134678#L528

Fix at maximebf/php-debugbar#411 (upstream)

We should remove PHP 5.3 from our Travis builds, it's not supported in Travis any more

It’s often hard to tell from the outside if you’re writing an effective cache key. You can guess if e.g. a partial template cache applies by looking at the overall page load time, but that’s not very accurate. Or you can set a breakpoint in the logic that should be cached, which in reality is too much of a barrier and gets easily missed. If the toolbar told you “Your partial cache named ‘myCacheKey’ didn’t find any existing caches”, it’s much clearer

When running dev/build on a new site, without a populated database, it seems to break the build.

For feedback

DebugBarDatabaseProxy is SS 3.1 compatible, and DebugBarDatabaseNewProxy is SS 3.2+ compatible. It might be a good idea to set the minimum version requirement for this module to 3.2, deprecate the DebugBarDatabaseProxy class in the 0.x release line and remove it in 1.0.x to reduce duplication and maintenance burden.

I'm sure that there are still plenty of users on 3.1, but it's been EOL for some time now (current minimum supported version is 3.5).

I've identified that somewhere between v1.0.0-beta1 and v1.0.0, a regression has been introduced which results in severe memory leakage during long-running processes - particularly visible in my case during large unit test runs.

Unfortunately I don't have a deep understanding of the module's underpinnings, so I can't give any further detail on what is causing the issue. Should be able to reproduce this by running a large volume of DB queries on a CLI process and observing the difference in memory usage between 1.0.0-beta1 and 1.0.0.

I got this after updating from SS 3.4.1 to 3.5:

[Strict Notice] Declaration of DebugBarDatabaseNewProxy::benchmarkQuery() should be compatible with SS_Database::benchmarkQuery($sql, $callback, $parameters = Array)

On my 15" MacBook the tabs now split over two lines.

We need to do something to ensure that this stays on one line where possible.

I am confused about the usage of this module. After install it via composer, it didn't show up automatically, even when request with "debug" and "debug_request".

Is there any step I need go through to make this module work? Maybe I need to change some configurations?

The assumption that we can handle and log error levels and above and have them not halt page execution is incorrect with PSR-3.

The currently NullHandler override of the core logger ends up producing a white screen whenever errors are thrown.

We need to remove the handler and handling for log messages with those levels.

Although it highlights which queries are apparently duplicates, it would be nice to filter them by "duplicate only" and grouped by statement, to see where there could be some optimisations.

It would be nice if the Request-tab would include the output from ?debug and ?debug_request url variables.
I understand that this is not very easy to incorporate, but I think it would add a lot of value.

To make way for pre-processed assets (e.g. #53).

Currently the assets/debugbar.css for example has some customisations. We should use a location that is obvious that it's a third party file that shouldn't be touched.

Acceptance criteria

• Latest version of php-debugbar's assets are copied through to assets/vendor/php-debugbar
• Customisations to assets/debugbar.css as well as the other CSS and Javascript files in that folder are moved to a new folder (e.g. css/)
• Documentation makes it easy for devs to find out which files to change when contributing

Tests are missing. I think adding either Behat or Unit tests would be a good thing to make sure everything stays stable.

It would be awesome to display cached variables: name, value, ttl

use SilverStripe\Core\Cache\FilesystemCacheFactory;
...
$cache = new FilesystemCacheFactory('data');
$this->cache = $cache->create('EventsAPI');
$this->cache->set('token', 'test', 3600);

As a developer,
I want to be able to disable certain tabs (e.g. Templates or SiteConfig),
Because I may not like or want them for my dev environments

Hi There,

Just seem to be having an issue getting this working on the front end of the website (admin shows find). I am including my own jQuery, the required CSS/JS from debug bar is loaded, and when I try to debug the DebugBar using in my Page Controller init() function:

$foo = DebugBar::WhyDisabled();
d($foo);

The returned result is 'I don't know why'

There are no errors that I can see being logged (both JS/PHP)

If I can supply you with any useful info I can..

Using SilverStripe 3.5

I'm getting this error.
I'm using PHP 5.6
Mac OSX
Apache 2.4
Silverstripe 3.6.1

I ran multiple flushes, with no change.
Uninstall and flush again, and the site works again.

Fatal error: Call to a member function getTitle() on null in .../debugbar/code/DebugBarSilverStripeCollector.php on line 174
--

1 | 0.0006 | 240496 | {main}( ) | ../main.php:0
2 | 4.7042 | 7525160 | Director::direct( ) | ../main.php:191
3 | 131.4706 | 23252328 | RequestProcessor->postRequest( ) | ../Director.php:183
4 | 131.4707 | 23252552 | DebugBarRequestFilter->postRequest( ) | ../RequestProcessor.php:42
5 | 131.4707 | 23252672 | DebugBar::renderDebugBar( ) | ../DebugBarRequestFilter.php:57
6 | 131.4707 | 23254512 | DebugBar\JavascriptRenderer->render( ) | ../DebugBar.php:226
7 | 131.4707 | 23254808 | DebugBar\JavascriptRenderer->getJsInitializationCode( ) | ../JavascriptRenderer.php:981
8 | 131.4708 | 23255144 | DebugBar\JavascriptRenderer->getJsControlsDefinitionCode( ) | ../JavascriptRenderer.php:1015
9 | 131.4710 | 23268080 | DebugBarSilverStripeCollector->getWidgets( ) | ../JavascriptRenderer.php:1059

Any ideas on how to fix?

It would be great if you could supply a tagged version according with a changelog.

This way it's easier for composer to cache the package.

Also requirement of original debugbar as * is quite unstable if that package has a non-BC major version.

Getting an error from nginx when debugbar enabled at the CMS

2018/05/29 00:14:35 [error] 15667#15667: *903 upstream sent too big header while reading response header from upstream, client: 127.0.0.1, server: *.run.local.pro, request: "GET /admin/pages/treeview HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "run.local.pro", referrer: "http://run.local.pro/admin/pages/"

I feel the currently used icons are not really the best choice. Here's my thought:

• database is a more sensible icon for database
• list for Parameters?
• envelope for Messages
• cookie (Not yet available :( ) for cookies (duh)
• file-code-o for templates
• check for Requirements? (this is a tricky one)

Silverstripe: 4.1.2
Php: 7.1.12
Jquery: 3.3.1
Silverstripe-debugbar: 2.x-dev and others

i get a javascript error on the front end - not in the cms and can't figure out why:

Line: 1115: undefined is not a function (near '...jq(document).ajaxComplete...')

Hey @lekoala :)

As this module now has Travis configuration which runs Codecov.io code coverage, could you enable TravisCI and ScrutinizerCI? Codecov.io should enable automatically once a successful coverage run on Travis completes.

Versions

silverstripe/cms => 4.3.3
lekoala/silverstripe-debugbar => 2.0.3

Problem

Enabling config_collector disabled the Search extension.

Information

I just installed silverstripe-debugbar on a SilverStripe installation based on silverstripe/recipe-cms 4.3 with FulltextSearchable::enable(), and noticed that my $SearchForm was not being printed.

I have not dug much into it, but seems like config_collector modifies the configurations disabling the search extension.
After disabling config_collector, the Search functionality came back.

The results from d(ContentController::get_extensions()) where different after enabling config_collector

Hi if you use as suggested install method - it throws error like this because it is gonna try to add 1.1-dev

composer require --dev lekoala/silverstripe-debugbar

lekoala/silverstripe-debugbar 1.1.x-dev requires silverstripe/framework ~3.2 

My silverstripe is 4.0.0 - So I just used.

"lekoala/silverstripe-debugbar":"dev-master"

If i put this in _ss_environment.php i still get the debug bar.

putenv('DEBUGBAR_DISABLE=true');

If i want to remove / add this per environment (not based on dev/live) how should I do that?

Not sure why this modules required: silverstripe/siteconfig, silverstripe/admin
But it will be nice to use debugbar without silverstripe CMS installed

@robbieaverill Thanks for writing awesome docs! I do wonder if they're a bit too scattered though - it's quite likely that devs will miss essential docs because they're spread across a dozen pages. Could we condense this into the README? I think in general, anchor links plus a long README are preferrable to mini-pages with half a screen of content. That definitely has it's limits, e.g. the GraphQL module README has grown too large. But in general, there's a lot of power in the ability to skim read by scrolling, and use browser search on a single page.

On my setup i block standard (old) jquery but use my own which i include when rendering the templates.

Unfortunately debugbar wants to inject the javascript before my own jquery is put to requirements, so it's called before and voila - ReferenceError: jQuery is not defined

For now i have to inject my own jquery in Page_Controller::init to get debugbar work, another approach to inject required javascript as late as possible would be great.

Maybe RequestFilter could work? https://docs.silverstripe.org/en/3.3/developer_guides/controllers/requestfilters/

Hi,
Can't get it working on ss3.6.2 on php7.1, not in frontend and not in admin. Environment is dev (setting in _ss_environment.php).
Should it work with this combination?

As per @chillu's comment here

2 examples thereof reside within silverstripe/auditor and silverstripe/fulltextsearch modules.
This causes an issue with DebugBarDatabaseNewProxy::__construct() which expects a MySQLDatabase object parameter.

Steps to reproduce:

1. Set up a vanilla ss3 install composer create-project silverstripe/installer ss3
2. Install auditor module composer require silverstripe/auditor or composer require silverstripe/fulltextsearch
3. Install debugbar composer require lekoala/silverstripe-debugbar
4. dev/build and flush, then when visiting the front-end of your new site the below error is produced

silverstirpe/auditor example:

silverstripe/fulltextsearch example:

Doesn't this work with Silverstripe 4.1? I'm getting errors when running the site after installing this:

[Emergency] Uncaught SilverStripe\Core\Injector\InjectorNotFoundException: ReflectionException: Class Psr\SimpleCache\CacheInterface.cacheblock does not exist in /Library/WebServer/Documents/rtv_ss4/vendor/silverstripe/framework/src/Core/Injector/InjectionCreator.php:17 Stack trace: #0 

Trace
SilverStripe\Core\Injector\InjectionCreator->create(Psr\SimpleCache\CacheInterface.cacheblock, Array) 
Injector.php:585
SilverStripe\Core\Injector\Injector->instantiate(Array, Psr\SimpleCache\CacheInterface.cacheblock, singleton) 
Injector.php:988
SilverStripe\Core\Injector\Injector->getNamedService(Psr\SimpleCache\CacheInterface.cacheblock, 1, Array) 
Injector.php:941
SilverStripe\Core\Injector\Injector->get(Psr\SimpleCache\CacheInterface.cacheblock) 
SSViewer.php:558
SilverStripe\View\SSViewer->getPartialCacheStore() 
SSViewer.php:596
SilverStripe\View\SSViewer->includeGeneratedTemplate(/Library/WebServer/Documents/rtv_ss4/silverstripe-cache/_www/.cachevendor.silverstripe.assets.templates.SilverStripe.Assets.Flysystem.PublicAssetAdapter_HTAccess.ss, SilverStripe\View\ArrayData, , Array, ) 
SSViewer.php:674
SilverStripe\View\SSViewer->process(SilverStripe\View\ArrayData, , ) 
SSViewerProxy.php:36
LeKoala\DebugBar\Proxy\SSViewerProxy->process(SilverStripe\View\ArrayData) 
AssetAdapter.php:191
SilverStripe\Assets\Flysystem\AssetAdapter->renderTemplate(SilverStripe\Assets\Flysystem\PublicAssetAdapter_HTAccess) 
AssetAdapter.php:154
SilverStripe\Assets\Flysystem\AssetAdapter->configureServer(1) 
AssetAdapter.php:120
SilverStripe\Assets\Flysystem\AssetAdapter->flush() 
FlysystemAssetStore.php:897
SilverStripe\Assets\Flysystem\FlysystemAssetStore::flush() 
FlushMiddleware.php:22
SilverStripe\Control\Middleware\FlushMiddleware->process(SilverStripe\Control\HTTPRequest, Closure) 
HTTPMiddlewareAware.php:62
SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}(SilverStripe\Control\HTTPRequest) 
RequestProcessor.php:66
SilverStripe\Control\RequestProcessor->process(SilverStripe\Control\HTTPRequest, Closure) 
HTTPMiddlewareAware.php:62
SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}(SilverStripe\Control\HTTPRequest) 
SessionMiddleware.php:20
SilverStripe\Control\Middleware\SessionMiddleware->process(SilverStripe\Control\HTTPRequest, Closure) 
HTTPMiddlewareAware.php:62
SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}(SilverStripe\Control\HTTPRequest) 
AllowedHostsMiddleware.php:60
SilverStripe\Control\Middleware\AllowedHostsMiddleware->process(SilverStripe\Control\HTTPRequest, Closure) 
HTTPMiddlewareAware.php:62
SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}(SilverStripe\Control\HTTPRequest) 
TrustedProxyMiddleware.php:176
SilverStripe\Control\Middleware\TrustedProxyMiddleware->process(SilverStripe\Control\HTTPRequest, Closure) 
HTTPMiddlewareAware.php:62
SilverStripe\Control\Director->SilverStripe\Control\Middleware\{closure}(SilverStripe\Control\HTTPRequest) 
HTTPMiddlewareAware.php:65
SilverStripe\Control\Director->callMiddleware(SilverStripe\Control\HTTPRequest, Closure) 
Director.php:370
SilverStripe\Control\Director->handleRequest(SilverStripe\Control\HTTPRequest) 
HTTPApplication.php:48
SilverStripe\Control\HTTPApplication->SilverStripe\Control\{closure}(SilverStripe\Control\HTTPRequest) 
call_user_func(Closure, SilverStripe\Control\HTTPRequest) 
HTTPApplication.php:66
SilverStripe\Control\HTTPApplication->SilverStripe\Control\{closure}(SilverStripe\Control\HTTPRequest) 
call_user_func(Closure, SilverStripe\Control\HTTPRequest) 
ErrorControlChainMiddleware.php:56
SilverStripe\Core\Startup\ErrorControlChainMiddleware->SilverStripe\Core\Startup\{closure}(SilverStripe\Core\Startup\ErrorControlChain) 
call_user_func(Closure, SilverStripe\Core\Startup\ErrorControlChain) 
ErrorControlChain.php:236
SilverStripe\Core\Startup\ErrorControlChain->step() 
ErrorControlChain.php:226
SilverStripe\Core\Startup\ErrorControlChain->execute() 
ErrorControlChainMiddleware.php:69
SilverStripe\Core\Startup\ErrorControlChainMiddleware->process(SilverStripe\Control\HTTPRequest, Closure) 
HTTPMiddlewareAware.php:62
SilverStripe\Control\HTTPApplication->SilverStripe\Control\Middleware\{closure}(SilverStripe\Control\HTTPRequest) 
HTTPMiddlewareAware.php:65
SilverStripe\Control\HTTPApplication->callMiddleware(SilverStripe\Control\HTTPRequest, Closure) 
HTTPApplication.php:67
SilverStripe\Control\HTTPApplication->execute(SilverStripe\Control\HTTPRequest, Closure, 1) 
HTTPApplication.php:49
SilverStripe\Control\HTTPApplication->handle(SilverStripe\Control\HTTPRequest) 
index.php:26

The readme needs some information on the Config tab.

We should update any links that reference docs/en files, and update "Config tab is for SiteConfig" etc.

Hey @lekoala

With the completed merge of the following PRs, the module seems to be stable enough for a 1.0.0 release - what do you think?

• #37
• #38
• #39
• #40
• #41
• #42

The last step would probably be to flesh our the documentation for this module a little more and include some screenshots etc, which I am working on at the moment. I'll push a pull request when it's done.

Our team will be looking at upgrading this for SS4 in the next week or two as well adding a couple of new features which are not really doable in SS3.

Any thoughts on this?

Any plans for SS4 compatibility?

The debugbar inline script is loaded before the javascripts are included when the Requirements::set_force_js_to_bottom flag is set to true.

Written up a proxy module at https://github.com/tractorcow/silverstripe-proxy-db. This allows registration of a shared proxy database that multiple modules can decorate.

Also see:

• silverstripe/silverstripe-fulltextsearch#201
• silverstripe/silverstripe-auditor#16

isAdminUrl check returns false negative if debugbar is used in a subfolder

e.g. url is localhost://mydevelopent/admin

It's right where the menu trigger is in the CMS. Not sure how to fix that...

Is there a possibility to highlight the sql queries?

I just saw:

71 statements were executed, 12 of which were duplicated

but i don't know how to easily find those 12...

Tooltips get an opacity of 70%, making them pretty unreadable. Standard 100% would probably do fine