[VarDumper] 2.6.7 dump() breaks all API Doc platforms and Profiler

[MichaelHindley]

#14478

Used to be that you could call dump() and check the profiler without having a broken api response, with this change that is completely broken now. Not only do you get html in your response when the content-type is set to json , but the request is missing from the profiler so you can't even debug it properly.

For example, you can't dump() and check the events or doctrine queries for a RESTful request anymore, is this really intended behaviour?

Also in some cases the output of dump() is way too big to be handled in a api doc interface such as Swagger or NelmioApiDoc and breaks the browser where you could just view the profiler otherwise and selectively choose among the various dump statements.

The VarDumper was a easy way to do debug things in a RESTful environment, now it's completely useless in that regard. Using rest clients (such as in phpstorm) and having it give you the corresponding profiler automatically was such a great feature, this no longer works if you want to do any debugging at the same time.

[fabpot]

ping @nicolas-grekas

[nicolas-grekas]

I'd say this is a variant of #13915 and #14373: we all want more control over the destination (and thus the format) of the dumps. Now with 4 different expectations for doing this, I have to think about a common solution...

[jaltamir]

This new behaviour also breaks AJAX requests. For example, it's no longer possible to debug an ajax request for datatables.

It would be great to allow old behaviour.

[nicolas-grekas]

@NihilNovi @jaltamir could you please tell me if #14609 at least partially fixes the issue?

[jaltamir]

@nicolas-grekas It works

[MichaelHindley]

@nicolas-grekas #14609 does partially work, I don't think X-Requested-With is in the headers on xdomain requests though. I can see the same behavior on those, for instance in a virtual environment setup that utilizes CORS.

[nicolas-grekas]

Additionally checking for the Origin header should be the right fix then

[MichaelHindley]

On further testing, neither NelmioApiDoc or Swagger works with the changes in #14609 since they don't actually send AJAX requests in their API interfaces.

[nicolas-grekas]

See comments in #14609

[nicolas-grekas]

@NihilNovi can you please try #14640, setting debug.dump_destination to php://stderr or /dev/null

[MichaelHindley]

@nicolas-grekas I will do it tomorrow, unusually hectic week, sorry for my unresponsiveness :)

[teohhanhui]

If you use Postman for testing your API, dump still does not work as expected. Is there any workaround?

[nicolas-grekas]

Did you enable the DebugBundle and use the mentioned config option? Otherwise please open an issue describing your use case. Thanks

[teohhanhui]

Doesn't the config option debug.dump_destination take effect everywhere dump is being called, including the CLI and where the content type is actually HTML? That doesn't seem like an ideal workaround. (Because who would want to turn that config option on and off before doing dump?)

This issue is about us trying to be smart and avoid doing inline dumps when we shouldn't. I'm just pointing out a use case (a completely "normal" HTTP request, but which response content type is not HTML; you don't have to use Postman for this, you might as well just be loading the URL directly from the browser) where it's still broken. Perhaps we can add a second argument to dump to avoid inline dumps (just an idea)...

[teohhanhui]

After looking at #14478 I'd argue that it's wrong. Why do inline dumps where it'll break the response, when the dumps can still be collected by the profiler?

[nicolas-grekas]

#14478 fits its own reasoning, behavior and usefulness. If it doesn't fit your use case, you can use debug.dump_destination to unconditionally dump somewhere else (being CLI, HTML, or whatever context). Or you can use your own custom configuration. Maybe we can help, but for that, you'd need to open an issue (comments in closed issues can't be tracked correctly), and you'd need also to describe your use case precisely. Thanks