[Twig][Exception] Unknown filter instead of real exception message #25610
Comments
|
You can see the bug if you use this project : https://github.com/fancyweb/symfony-standard/tree/issue-25610. Start the server and go on the default page. |
|
Happened to me as well, in Symfony 4.0, right after running Ubuntu update. PHP was not updated (7.1.7), so I'm not sure what's the reason. |
|
Do you mean you don't get the more helpful error message? |
|
I get this instead of my exception. Edit : the real exception is way below, which is not intuitive. |
|
Never mind, I am looking at the project you linked to in #25610 (comment). |
|
The link is in the second message of this issue. |
|
hmm, if the instantiation of Twig extensions is triggering exceptions, this would indeed leave Twig in an unusable state (and so create issues when trying to use it to render the custom exception page) |
fabpot
added a commit
that referenced
this issue
Feb 7, 2018
This PR was squashed before being merged into the 3.4 branch (closes #25756). Discussion ---------- [TwigBundle] Register TwigBridge extensions first | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #25610 | License | MIT | Doc PR | - The only extension that is really needed to display the current exception page is the `CodeExtension` so we could only prepend this one. However, prepending all of them seems safer to me in the long term. Also I deeply looked into why this problem only appeared in 3.4 and found the reason. Before 3.4 it actually never reaches the `ExceptionController` for this kind of error because it cannot be resolved because it needs a twig instance in its constructor. This instance is directly taken from the container. Before 3.4 when an exception is thrown when you try to get a service from the container, the instance stored in the `$services` array is unset which is not the case in further versions. So in 3.4+, the `ExceptionController` can be resolved because the instance of twig is still in the container even after the initial exception. It also means these kind of exceptions are displayed with bugs on all versions before 3.4 I guess. Actually it shows the message 2 times : one for the initial exception and the other one when it tries to resolve the `ExceptionController`. Maybe another solution might be to use a dedicated twig instance with the right settings just for the exception page ? Commits ------- c8465ed [TwigBundle] Register TwigBridge extensions first
symfony-splitter
pushed a commit
to symfony/twig-bundle
that referenced
this issue
Feb 7, 2018
This PR was squashed before being merged into the 3.4 branch (closes #25756). Discussion ---------- [TwigBundle] Register TwigBridge extensions first | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#25610 | License | MIT | Doc PR | - The only extension that is really needed to display the current exception page is the `CodeExtension` so we could only prepend this one. However, prepending all of them seems safer to me in the long term. Also I deeply looked into why this problem only appeared in 3.4 and found the reason. Before 3.4 it actually never reaches the `ExceptionController` for this kind of error because it cannot be resolved because it needs a twig instance in its constructor. This instance is directly taken from the container. Before 3.4 when an exception is thrown when you try to get a service from the container, the instance stored in the `$services` array is unset which is not the case in further versions. So in 3.4+, the `ExceptionController` can be resolved because the instance of twig is still in the container even after the initial exception. It also means these kind of exceptions are displayed with bugs on all versions before 3.4 I guess. Actually it shows the message 2 times : one for the initial exception and the other one when it tries to resolve the `ExceptionController`. Maybe another solution might be to use a dedicated twig instance with the right settings just for the exception page ? Commits ------- c8465ed97f [TwigBundle] Register TwigBridge extensions first
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since 3.4 (bug is not there in 3.3), if one of my app Twig extensions throws an exception, I end up with the following message instead of the real exception message :
From what I've found, this is because my app Twig extension is added before the Symfony Twig Bridge
CodeExtensionwhich is the one that adds theabbr_classTwig filter. This filter is used in the defaultexception.html.twigtemplate and ends up being never registered. However, it seems it is also the case in previous Symfony version so I don't get why it only bugs in 3.4...Reproducer incoming
The text was updated successfully, but these errors were encountered: