-
-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
[DX] A simpler way to define custom error pages #24049
Comments
If the By the way, this could be done for 3.4 too: if this option is not set in the TwigBundle, use classic bundle inheritance, else, load error templates from the resolved directory. This should be possible with a compiler pass |
I think it should be a general convention, I means, not only for TwigBundle's errors templates. Although each bundle is free to add its own custom Twig's path. There is an open PR #23339 proposing to move them to |
@yceruto I agree with what you say, but considering that 100% of real projects need to customize the error pages, why not making that simpler? If the only way to customize is This proposal could be compatible with your proposal too. Want to customize error pages fast? Create That way we could solve @Pierstoval issue too: you can either use the simple and fast path ( |
There is something really important too: If Proposing a customizable extension point with a simple configuration option is to me the BEST possible solution for templates overrides. EasyAdminBundle uses something similar: auto-discovery in |
Just as a reminder, people tend to use bundle templates inheritance systems, while it should be much better to use twig paths. IMO this practice should be encouraged, and maybe a new syntax could be used to resolve a bundle view directory just to create a new namespace for it and allow better overriding systems: Before: # app/config/config.yml
twig:
paths:
'%kernel.project_dir%/vendor/symfony/twig-bundle/Resources/views/Exception': Error
'%kernel.project_dir%/vendor/friendsofsymfony/user-bundle/Resources/views': FOS After: # app/config/config.yml
twig:
paths:
'@TwigBundle/Exception': Error
'@FOSUserBundle': User |
@javiereguiluz I see your point and I'm in favor of simplest way to do this and I think there is some way to reach it if what we want is
Thus, when a It's just an idea, something might be missing and of course, I did ignored BC breaks. |
Also it could be confused, since it puts the overridden bundle templates in a location that can conflict with the app templates inside the main |
@Pierstoval gave the correct purpose imo. # app/config/config.yml
twig:
paths:
'@TwigBundle/Exception': Error
'@FOSUserBundle': User Are we sticking with that solution or is the solution from @javiereguiluz the way to go? Or are both solutions possible? |
IMHO @Pierstoval's proposal doesn't help to solve this issue :/ because the symfony/src/Symfony/Bundle/WebProfilerBundle/Controller/ExceptionController.php Lines 109 to 112 in c3d1262
symfony/src/Symfony/Bundle/TwigBundle/Controller/ExceptionController.php Lines 102 to 127 in 59094b4
and this proposal For now, the approved convention for |
Let's close because thanks to @yceruto overriding bundles templates is now much simpler. Also, even the error pages path is a bit weird, it's the standard way of doing things in Symfony, so it's better to not introduce yet another way of doing this. Thanks! |
How to Customize Error Pages in Symfony apps has bugged me since day one. In the past we could understand why it worked that way. But now that Twig is a first class citizen, in-app bundles are gone and bundle inheritance is in question we could reconsider this.
The Proposal
Make Symfony/Twig/TwigBundle look for in the
templates/error/
directory for custom error pages, and keep using the same logic to pick the template (error500.json.twig
,error.xml.twig
, etc.)This change could be made for Symfony 4.0, which introduces the new
templates/
directory at project root, but we may need to deprecate or change something in Symfony 3.4 in preparation for that.The text was updated successfully, but these errors were encountered: