Skip to content

[VarDumper] dd() can fallback to a plain text dumper if no suitable Dumper found #58151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

pierresh
Copy link

@pierresh pierresh commented Sep 3, 2024

Q A
Branch? 7.2
Bug fix? no
New feature? yes
Deprecations? no
Issues Fix #49754 #54772
License MIT

Thanks to this change dd() fallbacks to a simple plain text dumber if no suitable dumper can be found (discussed also in #58070). So that it could adapt to any situation, even if the consumer did not send any accept headers by default, like Guzzle.

I tested and it works well with:

  • PHPUnit
  • Chrome dev tools (results with HTML tags)
  • APIs consumed with Guzzle without accept headers (results in plain text)

This is useful if the consumer cannot handle HTML tags and is not a CLI

The current situation is that it is handled by the HtmlDumper but the HTML tags make the result unreadable
@carsonbot carsonbot added this to the 7.2 milestone Sep 3, 2024
@pierresh pierresh changed the title feat: dd() can fallback to a plain text dumper if no suitable Dumper found [VarDumper]: dd() can fallback to a plain text dumper if no suitable Dumper found Sep 3, 2024
@pierresh pierresh changed the title [VarDumper]: dd() can fallback to a plain text dumper if no suitable Dumper found [VarDumper] dd() can fallback to a plain text dumper if no suitable Dumper found Sep 3, 2024
@nicolas-grekas
Copy link
Member

Let's work on #58070

@pierresh
Copy link
Author

pierresh commented Oct 9, 2024

Understood, but #58070 does not solve any problems raised in #49754 and #54772.
This is a more theoretically correct but fundamentally, dd() still feedbacks unreadable outputs when debugging a JSON API.

@nicolas-grekas
Copy link
Member

To my understanding, it would.

@pierresh
Copy link
Author

pierresh commented Oct 9, 2024

There are currently two dumpers. In case of a debugging an JSON API:

  • CLIDumper does not return anything.
  • HTMLDumper returns HTML tags, which are readable only if the consumer supports HTML rendering.

Therefore, #58070 will not resolve the problems raised in #49754 and #54772, as both require a plain text dumper. In these issues, the consumer does not support HTML rendering.

@nicolas-grekas
Copy link
Member

Something might make you think otherwise, but CliDumper does output something: plain text dumps. So it fits.

@pierresh
Copy link
Author

pierresh commented Oct 9, 2024

Unless I am mistaken CLiDumper outputs to php://stdout.
This cannot be seen in Google Chrome dev tools and/or received by Guzzle. Thus useless when debugging a JSON API.

@stof
Copy link
Member

stof commented Oct 9, 2024

@pierresh when running in a CGI-based SAPI, the stdout is the HTTP response.

@nicolas-grekas
Copy link
Member

And the output destination is configurable so you can do what you want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

make HtmlDumper output more developer friendly
4 participants