Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[ErrorHandler] Add SapiErrorRendererSelector for context-based error rendering #60033

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

Open
wants to merge 1 commit into
base: 7.3
Choose a base branch
Loading
from

Conversation

yceruto
Copy link
Member

@yceruto yceruto commented Mar 24, 2025

Q A
Branch? 7.3
Bug fix? no
New feature? yes
Deprecations? no
Issues -
License MIT

Alternative approach to #58456 (same goal), using a factory selector to pick the correct error renderer based on the context (PHP_SAPI). One advantage of this solution is that it works even if TwigBundle is not installed as the selector/decider doesn't depend on it.

image

@yceruto
Copy link
Member Author

yceruto commented Mar 25, 2025

Now after updating some related tests, I'm concerned that this might break some functional tests out there (after upgrading to 7.3) for example: testing HTML error pages using WebTestCase won't work anymore if these tests are checking for more than just the error message.

Should we consider this a BC break?

Copilot

This comment was marked as resolved.

@yceruto yceruto force-pushed the cli_errors branch 2 times, most recently from b30fac0 to c281ec6 Compare April 1, 2025 19:18
@Spomky
Copy link
Contributor

Spomky commented Apr 8, 2025

Hi,

Thanks, it looks good to me at first glance.
I'll test it on my side to see how it behaves.

@Spomky
Copy link
Contributor

Spomky commented Apr 8, 2025

testing HTML error pages using WebTestCase won't work anymore if these tests are checking for more than just the error message.

Is there a way to opt-in for this feature (e.g. a dedicated env var)?

@yceruto
Copy link
Member Author

yceruto commented Apr 8, 2025

testing HTML error pages using WebTestCase won't work anymore if these tests are checking for more than just the error message.

Is there a way to opt-in for this feature (e.g. a dedicated env var)?

This small change restores the previous behavior. We could document this adjustment for situations where you specifically want to test the actual HTML error page:

-    ->alias('error_renderer.default', 'error_handler.error_renderer.default')
+    ->alias('error_renderer.default', 'error_renderer.html')

Most functional/end-to-end tests have a dedicated config file. That could be better than using an env var, since you can enable or disable this behavior case by case.

@yceruto
Copy link
Member Author

yceruto commented Apr 8, 2025

Or we could add a new framework option to opt-in for this behavior, include a deprecation notice to make it the default in 8.0, and update the recipe file to set it as the default for new projects. What do you think?

@Spomky
Copy link
Contributor

Spomky commented Apr 8, 2025

Sounds good 👍

@yceruto yceruto added the ❄️ Feature Freeze Important Pull Requests to finish before the next Symfony "feature freeze" label Apr 9, 2025
@yceruto yceruto removed the ❄️ Feature Freeze Important Pull Requests to finish before the next Symfony "feature freeze" label May 2, 2025
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.

3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.