@gharlan I don't fully understand your problem, but of course we're interested in making the WDT work for everyone. However, we're very reluctant to adding new configuration options. Can you think of a way to solve this issue without adding that option? Thanks!

Maybe show a small indicator of 'problems' in the Ajax request list?

Maybe show a small indicator of 'problems' in the Ajax request list?

The issue with that is that it would require exposing an API to know whether there is a problem for a profile when knowing its token. And building this API would force to implement a new feature for collectors to be able to get the info (as the API need to be extendable). It makes the feature hard to implement IMO

We already expose the Profiler Token :) so we can also expose a simple value like 'NOK' to indicate there are problems but no details about whats wrong.

In fact, you have the Profiler token, so you can use that call an API like you do with WDT on the main request now.

@sstok the issue is knowing how to determine this NOK value. There is no API to get information about whether one of the panel considers that there is a violation currently. The only thing we have is the AJAX request rendering the HTML of the toolbar.

However, we're very reluctant to adding new configuration options.

I support this. 👍
(But I'm not sure if this were a good config option anyway ;))

Can you think of a way to solve this issue without adding that option?

Without integration into the core: I guess I could achieve this somehow in a bundle but I'm not sure how easy it is to change the js behavior of the toolbar.

With integration of the new possibility into core: maybe the toolbar replacement could be initiated by a special response header (X-WDT-REPLACE or something like this)?
So I would have to add the header by myself (e.g. in a listener).

Ah right, I forgot the profile data is rendered server-side :)

FYI, if I understand the issue correctly, the guys from Oro did something like this in Oro Platform and OroCRM though I didn't look into how they actually implemented it. Maybe @DimaSoroka can provide us some insights.

@javiereguiluz is it normal that the ajax-debug bar still blink after all ajax requests finished?

@mayeco personally I think this is a bug and I reported it here: #15439 However, if you read people's comments, they think it's OK as it is. I still believe this is a bug.

@javiereguiluz I also think is a bug

I would also appreciate this feature and think it could be implemented in a sensible way using the idea of @gharlan :

• If the toolbar should be replaced with information from the ajax request, an additional header is set, like X-WDT-REPLACE and the value true/1
• The toolbar, after receiving the ajax request, now knows it should be replaced, and it knows the new X-DEBUG-TOKEN, so it could make an ajax call to get a complete replacement of the toolbar
• No new configuration is needed, and being able to switch the toolbar to a different X-DEBUG-TOKEN (and/or the option to load the toolbar via ajax) may also be useful in other instances

So the main obstacle is the possibility of loading/updating the toolbar via ajax. As far as I can tell the toolbar is 99% JS anyway, which should make it easier. Is this a feature which would be considered in this way?

This would be an amazing feature. I use Symfony for the back end and react for the front end. It would be very useful to have the information update on each ajax call as if it were a full page load.

Another idea would be to provide a JS api that could be used after an AJAX to cause a reload. There are various hacks in the wild that worked for SF2, but I haven't found or put the effort into making it work for SF3.

The main issue I see with the idea @iquito suggested would be how to know if the WDT should be replaced or just an AJAX request added to the list.

@jeffreymb The toolbar can read HTTP response headers, so when reading X-WDT-REPLACE in a response it would know to replace itself. If the header is not set, it would behave as it currently does by adding an ajax request to the toolbar.

The main advantage of this approach is ease-of-use - as a developer you just add a header to a response and the toolbar is replaced. No API or intricate knowledge of the toolbar is required.

I just created a PR for this feature and would welcome feedback!