@wouterj Looks really interesting. Would it be possible to try to keep the same vertical height as before?

ref#18149,#18074

Would it be possible to try to keep the same vertical height as before?

Yes. I've now updated the styles to accomplish this. The margin, padding and background (for visible correctness) have now been removed. New after screenshot:

I don't understand the PHP 7.1 failures.

If anything helps"A non well formed numeric value encountered" is a common data conversion error str to time or number format.

See suggestions as patch directly innicolas-grekas#6

Thanks@nicolas-grekas for your patch! I've cherry-picked it into this PR and tried to fix the LoggerDataCollector (not sure if this is what was expected though, will test later this week in a Symfony app).

I hope the PHP 7.1 test failure is suddently fixed as well. I've tested it using PHP 7.1.0-beta2 on my local PC and don't get the error.

This is great! Is it possible in the component to have the objects dumped in a non-expanded state by default? I was thinking that for things like your contentDocument, it pushes the other content far down on the initial load of the page.

Thanks!

@weaverryan I've now collapsed all dumps by default (and expanded the first level for the log context).

Also tried to fix the tests.

New suggestions inthe latest commit ofnicolas-grekas#6 (needs#19656 to be at its best):

• add warnings in the "Logs" count, more important now that throwing exceptions in dev can be turned of (see[Debug] Better error handling #19568)
• properly remove sanitizeContext: VarDumper does the job.

PR rebased in my fork to benefit from latest VarDumper features. Don't forget to setframework.php_errors.log totrue inapp/config/config.yml until#19656 is merged.
This still needs work to put everything together in a nice way but I think my contrib can pause here as the difficult part related to tightly plugging VarDumper should be OK now.

Discovered a problem with this implementation (with all latest work by@nicolas-grekas): The logger panel is now completely unresponsive in the CMF sandbox (it has 251 debug messages with context that includes a Doctrine mapped document).

Is there anyway to work around this?

That's one of the reasons why I think this needs more work :) The dumps integration is a bit rough right now, but there is no issue with the base implementation, only more CSS to write and a few JS to fine tune the US. What about adding back the show/hide context button?

The serialized data is fine. We never guaranteed BC on the storage format of the profiler between minor versions (i.e. you cannot load a profile generated with X.Y in a X.Z runtime, you have to clear your profile storage when upgrading, which is done by default as they are stored in the cache).

regarding the DebugAccessDecisionManager and the FormDataExtractor, I think it is fine, as they are mostly meant to be consumed by the profiler collectors.

what's the status of this PR? I would really like to be able to merge it in time for 3.2 (end of dev by the end of the month).

With the great help of@nicolas-grekas, I think this PR is now finished and ready for review. I've just tested all changed profiler panels and fixed some small rendering issues.

Two glitches:

• one test needs a fix in DumpDataCollectorTest
• var-dumper ~3.2 needs to be added to the composer.json of SecurityBundle (require-dev)

thanks, applied the changes

👍

Thank you@wouterj.