[TwigBundle] Register TwigBridge extensions first #25756
Conversation
|
I really like the idea of having a "safe" instance of Twig just for the profiler. |
|
I am not sure if having a safe Twig instance for the profiler is actually doable. We do not know what panels added by third-party libraries do require. The same is true for the exception controller. As soon as someone creates a custom exception page we cannot know anymore which Twig features they use there. |
|
I tried really hard to fallback on a safe exception page using a safe Twig instance when an exception is thrown in the initial exception page but was not able to make it work completely, mainly because of our BC policy. So I saw that we can now add Twig extensions by priority (#24777). What about using it to load the TwigBridge extensions first by default and just stops there for now. It will still be better than the current situation. |
| foreach ($container->findTaggedServiceIds('twig.extension', true) as $id => $attributes) { | ||
| $definition->addMethodCall('addExtension', array(new Reference($id))); | ||
| $methodCall = array( |
There was a problem hiding this comment.
I'd suggest to put this declaration on one line
|
Thank you @fancyweb. |
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
The only extension that is really needed to display the current exception page is the
CodeExtensionso 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
ExceptionControllerfor 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$servicesarray is unset which is not the case in further versions. So in 3.4+, theExceptionControllercan 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 ?