8000 Bridge\Twig\TwigEngine doesn't support valid template names · Issue #12942 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Bridge\Twig\TwigEngine doesn't support valid template names #12942

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.

Sign up for GitHub

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

Jump to bottom
Closed
trappar opened this issue Dec 11, 2014 · 1 comment
Closed

Bridge\Twig\TwigEngine doesn't support valid template names #12942

trappar opened this issue Dec 11, 2014 · 1 comment

Comments

@trappar
Copy link
trappar commented Dec 11, 2014

Darn, I wrote out a whole bug report with a lot more detail than this one and then somehow it didn't submit and I lost it. I only just noticed now that I'm not at my dev box.. so here it goes again.. this time from memory.

The Symfony Best Practices templates subsection says that templates in /app should be able to have names like default/index.html.twig (no double colon syntax). This works fine until you enable another rendering engine in the FrameworkBundle configuration.

With another renderer enabled Symfony starts using the DelegatingEngine, which checks each renderer's "supports" method against the template name to determine compatibility. This is where the problem resides. In this case the TwigEngine throws an exception saying that it doesn't support names like base.html.twig (with no leading ::)

So it seems like there are kind of two problems here:

  1. When you only have one renderer defined in the configuration the renderer::supports methods are never called, what's the point in those methods if they are only called some of the time?
  2. The regex expression used to determine template compatibility for twig in these cases is outdated and doesn't support the current conventions.
@trappar
Copy link
Author
trappar commented Dec 11, 2014

Just found some related issues. Looks like it's already fixed in an unreleased version as of two days ago here: #12894

I'll go ahead and close this.

@trappar trappar closed this as completed Dec 11, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@trappar
0