Add a floating tool bar with debug information a la symfony

Some work has been done here.
https://drupal.org/sandbox/dereine/1920628

Hi,
we took a different approach porting the WebProfiler bundle as Drupal module:

https://drupal.org/sandbox/lussoluca/2165731

Luca

Here is Drupal 7 module based upon PHP debug bar library.
https://drupal.org/sandbox/chi/2143457

Amazing, I was just thinking of this a couple of weeks ago, and I'd rather go with what @Chi comments on the debug bar and keep the symfony web profiler out of devel.

I'd like to know moshe's and salvis opinion on this before proceeding

Assigning to salvis for discussion :)

Yeah, the debug bar looks awesome! I'd love to move @chi's module into the devel project.

1. The most important remaining bit is implementing the query log of devel. We have some fancy ajax for retrieving the values for a given query and i'd like to keep that around if possible.
2. I'm also wondering what this means for all the krumo functions. Is the debug bar capable of showing these objects and handling recursion and all that?

The symfony webprofiler looks similar in architecture. I'm open to going with that if anyone makes a good case for it over debugBar. Otherwise, lets proceed with DebugBar.

A couple of things we should take into account about PHP Debug Library.

1. PHP Debug Bar requires psr/log so it kind of tricky to get it without Composer. But Composer is not a Drupal 7 way to install third-party library.
2. PHP Debug Bar comes with own jQuery instance (v1.10.2 at the moment). It may cause some issues.
   See: http://phpdebugbar.com/docs/rendering.html#managing-jquery-conflicts

1. Maybe we just suck it up and ask devel folks to run composer in order to fully install debugbar module.
2. Can anyone say whether we have a problem here? That conflict info was too unfamiliar for me to parse.

The patch adds devel_debug_bar submodule.

Wow, thanks Chi, I've got three questions from a preliminary review:

Is this something that needs to be a separate module? It feels like it should be just an option to enable / disable.
What happens with the limitations described in #7? The way I see it is that we could have a libraries module dependency or something to make sure that this is happening:

PHP DebugBar library should be installed to sites/all/libraries/vendor directory.

Also, not sure what happens with the Jquery specific version dependency here, do we suppose is there?

Finally, I think we should integrate this in D8 first.

I prefer this as a separate module. Cleaning up in this way is a good thing. We need to decide what to do with all the misc stuff that remains in devel.module

I don't see libraries module as being useful here. Realistically, noone else needs to add this library. I think using composer and a vendor dir is least bad solution.

Yes, I'd like to know more about jQuery problem (if any), and D8 should go first.

I'd like to know more about jQuery problem

Up to now, I haven't faced any problem with it. May be they will not be.

I tried this out and really like the UI.

1. I couldn't get a custom message to show up. Maybe you could add a helper function which does this?
2. We really need to integrate the query log into this.
3. We need the debugBar to disappear when devel_silent() == TRUE.

By the moment message can be added by this way. Of course shortcut function would be handy here.
\DevelDebugBar\DevelDebugBar::getInstance()['messages']->addMessage("hello world!");

I don't have much experience with Drupal 8 yet. What is right way to install third-party PHP libraries in Drupal 8? I found some discussion here but it may be out of date.
http://crossfunctional.net/blog/2013/may/indefinitive-guide-composer-dru...

P.S. Granted access to sandbox @pcambra and @moshe weitzman

Moving this to D8

Hi all,

The symfony webprofiler looks similar in architecture. I'm open to going with that if anyone makes a good case for it over debugBar. Otherwise, lets proceed with DebugBar.

Sorry, I haven't see any notification on this issue so I cannot reply before...

We have integrated the Symfony web profiler as a Drupal8 module, you can find here the latest version compatibile with D8-alpha8.

We adapt the original code to run into Drupal8 so we don't need any modification to composer.json (and we use the standard Drupal theme layer to do rendering). Also all infrastructure to deal with data-collectors and profile storage and management are already present into Drupal8 core (as part of Symfony HttpKernel component).

We have implemented data-collectors for query log, memory, timer, form, routing and we are planning a lot more.

Luca

Just played with the module and it works well for me. Do you plan on releasing this as a full project sometime soon?

Hi Chi,
we are implementing some more data collectors and do a polish to the UI then we release the module, I think in a month or so. Then we'll plan to add some other fancy things like data visualization on collected profiles.

Luca

Especially the fact that data is collected and not displayed on the actual page request makes this tool really powerful as you can show a lot of different data.

@devel-people
Given that the debug toolbar would cover quite some bits of the devel module it would just make sense to be part of the devel package, what do you think about that idea?

@Luca
I promised to help, hopefully on the weekend I will implement a couple of more data collectors.

@devel-people
Given that the debug toolbar would cover quite some bits of the devel module it would just make sense to be part of the devel package, what do you think about that idea?

Agreed, I guess the discussion was whether to go for Symfony toolbar or debug bar

The symfony toolbar has a big advantage: A lot of the complex code to deal with events/the HTTP kernel is already available by symfony itself.

I'm all in to have the tool included in devel, as @moshe says in #11, it would go to a submodule so the integration I guess would be easier.

Hi all,
webprofiler module now is a full project:

https://drupal.org/project/webprofiler

Luca

Are you guys still considering including the profiler in Devel or do you prefer to keep it standalone?

I've just committed another debug bar. It's much more simple than PHP Debug Bar or Symfony Webprofiler.
https://drupal.org/sandbox/chi/2241947

Here are another debug bars:
http://nette.github.io/tracy
http://www.php-debug.com

Some basic version of this should be in core, especially with the addition of route names instead of paths as the key ID for a page.

@pwolanin
At least the web profiler toolbar is written in a way that you can extend the entries in your modules,
so core could ship with just the most basic stuff (php version, (maybe memory, time) and route name).

All of those debug bars are interesting and surely useful.
The question here is different, we want a debug bar to show current page information or we want to profile a website to discover bottlenecks and problems?
In Webprofiler module the toolbar is just a "side effect" of the fact that we collect all page's data in a persistent storage.
IMHO Webprofiler is more interesting also because it shows how a module can integrate better with the Symfony components.

Then we can surely create a lite version for Devel core and provide extensions as contrib module but I don't think this make some differences.

@dawehner - yes, something basic like that in core - can we move this issue or create an another one for core?

@pwolanin
It would be really sad if we reinvent the wheel and basically require contrib to start from scratch again.
As the templates require some version of #2073811: Add a url generator twig extension it would be really great to use this new feature to push that issue.

@lussoluca
Would you be okay with moving the basic the basic framework into core? This potentially would require some licensing
changes for the images you and your colleges made etc.

@dawehner for me it's a great news to have some parts of webprofiler into core.
Which data collectors do you think we can include? It make sense to have route, time, memory into core and the others into Devel (or in an other module).
If we plan to use D3 to do data visualization we need to add it to the core too.

I talked with tim.plunkett about it, and he was not really convinced that this would add enough value to core.

Ok, no worry for core integration.

There is still interest in put Webprofiler in Devel?
My only concern is that a user who wants to use either Devel and Webprofiler will have two version of query and time loggers.

Meanwhile I've refactor the backend code to be more Drupal oriented and more modular.

I've been hearing more good things about WebProfiler so I looked at the module by @lussoluca and it also looks really strong. I tried to enable the module but am getting 'The service "form_builder" has a dependency on a non-existent service "form_validator".'. Maybe my core and webprofiler are incompatible? I updated D8 a couple days ago.

I'm inclined to add d3 and twig_routing to the webprofiler composer.json so that users can get those with Composer Manager.

I'd to move webprofiler into devel and add lussoluca as a devel co-maintainer.

We also need twig_trouting to go into D8 core or become a full Contrib project.

DatabaseDataCollector::panel shows a basic query listing. The current devel is richer, as it has three links, A+E+P links for showing arguments, explain, and placeholders. I'd really prefer not to regress here. If anyone could work on this Collector, I'd be grateful.

Hi moshe,
thanks for your time spent on trying webprofiler.

#35 form_builder service has changed on May 6 because of #2209977: Move form validation logic out of FormBuilder into a new class. I'm trying to maintain webprofiler's code aligned to the HEAD every day
#36 IMHO twig_routing should go into D8 core, it could be useful for other modules
#37 surely, we have a lot of work to do. A better interface for DatabaseCollector is planned and I'm working on it. I'll open an issue for this on webprofiler issue queue

I'm seeing a 500 error after enabling webprofiler with latest D8. I don't see any helpful information in my error log - sorry.

There is a core bug which prevents webprofiler to work. See here #2265087: Flaw in core causing fatal error

webprofiler project is very healthy and useful. i'm not sure how devel should change now that webprofiler is a strong project

We can choose to add Webprofiler as a submodule of Devel or maintain it as a separate project but in both case we should remove the common functionalities from Devel (the query and time/memory logger).

For me both are ok

+1 to extract common functions!
once we make uProfiler work [2329127] would be nice to integrate devel and webprofiler, for example devel should stay as agregator module

lussoluca and I are in agreement - webprofiler module is moving into Devel project. The best issue to watch is #2572009: Remove query logger and footer info