Logs panel (profiler) has a significantly slower page load, basically renders before tabs are applied.

My experience is this is not really related to debug/deprecation/container logs, but (duplicate) var dumping.

edit: on the upside.. they are all searchable 😓

👍🏻 This is good :)
Nice to see your implementation

@ro0NL I appreciate your efforts here a lot. I like the idea and I want to have this in Symfony ... but I don't like the implementation. Also, I think it's too late to make this right on time for Symfony 3.4 feature freeze.

In my opinion, the interface should be like this: the table headers (Channel and Level) should be intelligent and include the following elements.

1. The channel table header should work like this GitHub element:

That's how I can easily filter log messages by any channel ... and it doesn't matter how many channels there are.

2. The level table header should display a range slider to select the minimum level of the log messages you want to see. I wouldn't let the user freely select anything ("I want to see critical and debug messages" <-- it doesn't make sense to me). I prefer to let the user select "debug or higher", "critical or higher", etc.

Something like this, but not so ugly:

Well.. if we can filter by leveland channel; that be awesome. I can imagine it's useful with lots of (user-defined) channels within the debug level.

I like the slider approach; intuitively raising the log level. However this does not solve my real usecase; disable debug to expose what's critical.

edit:

"critical or higher", etc.

(Lets say "warning or higher", or only critical ;)) that's exactly what's needed yes. Your slider UI probably implies both points can be set, thats cool 🎉

Also see#24244 which improves the overall experience on heavy requests/logs panel, addresses#24263 (comment)

nice idea@ro0NL 👍 !
just few comments from my side

@keradus comments addressed. For now all open :) as@javiereguiluz mentioned; this might be too simple. Yet as first step to proper log filtering i hope to see something in 3.4 yes.

@ro0NL ( cc@javiereguiluz )

As I said in my issue#23038 early june, I think it could be a really cool tool (even in a simple implementation) for 3.4 launch

Many thanks !

I like this. But... it's not mission critical and we don't want to release something that's not as polished as it could be. I tend to agree with@javiereguiluz when it comes to visual things. Though... is it possible to merge this before feature freeze and tweak the visuals after?@ro0NL would you be able to tweak the visuals like Javier talked about? Or would@javiereguiluz need to do that (and does he have the bandwidth... I'm terrible at design stuff)

@weaverryan if we leave out channel filtering first, i might give this a try this weekend. So focus on the level filter, which is what this PR is about really :) (but filtering channels is valid, for sure).

Hope to get@ogizanagi pov as welll, since he wrote the var-dumper search UI. Perhaps he has a plan...

First thought was;<input type="range" multiple> and be done. That doesnt exist today though, but we do have HTML5 drag&drop api.

I'm terrible at design stuff

Yep. This needs to be prepared, but first we need a plan :)

I love@javiereguiluz examples:

• The channel UI suggestion based on the Github labels filters UI would be perfect as is.
• For the log level selection, indeed amultiple range widget with ticks and labels would be great, but has to be done manually as there is no native way to achieve it AFAIK.

No plan right now, I can give it a try...but that'll wait for 4.1 I think 😅

📝 might be useful:https://codepen.io/trevanhetzel/pen/rOVrGK

I think it would be fine to do log level now, then channel filtering later. It may still be a challenge to get something quickly (and dependably) that looks nice. But, I'd love if you could make that happen@ro0NL :)

Range inputs can bestyled native actually. Shocking.

Maybe combine to range inputs for lower/upper bound. I believe@javiereguiluz proposal implies that.. going to jsfiddle NOW :)

Got somethinghttps://jsfiddle.net/z2ov274f/

Let me know if this works for you. I think it just might do 👍

@ro0NL I think you are over-delivering here 😄 I don't think we need a multi-range slider. A user wants to see"debug logs or higher","info logs or higher","warning logs or higher", etc. A step-by-step slider like this one would be enough:

Yes indeed, simple is better :)

The problem is we always include debug then; thus the noise.

@ro0NL make "info" the initial value of the slider. Problem solved!

@ro0NL DYT my idea offilter logs by channel can be acheived in this same PR?

I am really sure it is a good feature for a developer

The use case is simple, when we reach this section of profiler's log, we come here for a very specific reason, so the more specific the data is visualy, the best it is :)

@javiereguiluz you're right. Increasing the slider, means indeed "info/warning/etc. or higher". I had this mindset where it increases from the first level (debug till warning, debug till error, etc.).

The right boundary is fixed, not the left one :)

Anyway made the multiple range thingy a gist, can probably use it sometime :-) Ill try to finish this one this weekend.@noniagriconomie ill check channels as well, to see if something simple is possible.

Latest version after some discussion with@javiereguiluz

https://jsfiddle.net/m2xq73ba/

Almost there.

edit: i also just realized for this UX to be right we need to go from critical to debug, so left-to-right.

It's kinda working :) Screenshot updated.

• buttons only, range slider removed (it did not bring much value). yet it still works as a slider!
• css colors picked with care
• debug disabled by default in twigbundle
• i suggest to remove tabs profiler in favor of log level filters (container tab excluded) so that both tables (twig+profiler) are the same.
• what about level DEBUG for missing translations only in debug mode?

https://jsfiddle.net/po23sLge/ 😂

Indeed, I'd be in favor of removing theDebug tab to be merged in the first one (but deprecations should be kept appart. Not sure about silenced notices), and keep debug disabled by default, like it is on exception pages. It also have another advantage: it's didactic and hints you can change the levels to show:

I see both active and inactive pills. I understand I can disable some levels.

I can't see any difference, wrongly assume these are tabs.

Perhaps that's where the slider was more obvious. But clearly, I'd not put both.

What about pills with a checkbox? (like a filter).

IMO multi select input would be better (and take less space in the view)
and after it could be easier to duplicate with channels's multi select input

About the checkbox/filter issues... im not sure =/ i tend to agree with@javiereguiluz

I wouldn't let the user freely select anything ("I want to see critical and debug messages" <-- it doesn't make sense to me).

It's about increasing/decreasing severity, not necessarily "filter by field".

and after it could be easier to duplicate with channels's multi select input

Im not aiming for channel filters anymore with this PR, so should not be a blocker, nor do they have to be the same widget style in the future.

Moving to 4.1. Rebase on master might be needed, where PHP 7.1 features can be used btw.

Just for the record:#23247 is about filtering logs completely so they aren't even written to the profiler (for performance reasons) while this PR is about filtering logs when viewing them in the profiler.

👍 for this feature, would be a nice addition!

I'm willing to finish this, and quite happy with my work so far actually :)

But there are many ways we can solve this UX-wise, and perhaps we should aim for a simpler approach.

Im curious if e.g.@javiereguiluz@ogizanagi ... has some time to help me move forward, or willing to takeover from here on.

Can we resume the work here. It seems that we are almost there. Having this in 4.2 would be great.@javiereguiluz ?

For merge on master of course

UI tweaks can happen during the stabilization phase.

Thank you@ro0NL.