-
-
Notifications
You must be signed in to change notification settings - Fork 364
[TwigComponent] Add support for namespaced templates in TemplateMap #1070
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
Conversation
*/ | ||
private function parseTemplateName(string $name): mixed | ||
{ | ||
if (isset($name[0]) && '@' == $name[0]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (isset($name[0]) && '@' == $name[0]) { | |
if ('@' === $name[0] ?? '') { |
but also test is missing to prove the fix is working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea - a test would be ideal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test added, and branch rebased which now incorporates @weaverryan's latest test fixes. All green now here as well!
@stloyd I corrected the loose comparison. The (copied) code from Twig also used loose comparison. I guess because in this case loose comparison would be faster and if the type didn't match it would also fail (i.e. nothing would equal '@' anyway) and the type is already guaranteed because of the parameter type hint. For the same reason I kept the isset
instead of ??
because it only needs one check to know to fail while the ??
would always do the assignment and then do the comparison always.
bb1286c
to
fcfa2d6
Compare
fcfa2d6
to
be663d1
Compare
Thank you Bart! |
…within namespaced template (sneakyvv) This PR was merged into the 2.x branch. Discussion ---------- [TwigComponent][LiveComponent] Fix Live embedded component within namespaced template | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | | License | MIT This fix is related to #1070 . That PR made sure that a namespaced template could also be found in the TemplateMap, which contains paths without the namespace, so that the right template name (or actually obscuring hash) is used for the host template reference for live embedded components within such a template (which is used to find the right blocks during a re-render). However, because the Parser was still using the namespaced template name to calculate the deterministic index number for an embedded template, it would not match with the index of the stripped / namespace-less template name, causing it to have a different index for the embedded template during re-render then during parsing, resulting in a template not found error. This PR now also strips namespaces from template names during parsing. Commits ------- ad84cf7 [TwigComponent] Fix Live embedded component with namespace
…yvv) This PR was merged into the 2.x branch. Discussion ---------- [TwigComponent] Remove obsolete TemplateNameParser It no longer parses (and should not have been stripping namespaces as it did before) | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Issues | | License | MIT As discussed in #1772 (comment), the code added in #1070 (& expanded in #1082) was not needed (even incorrect, based upon a decorator TemplateIterator of Shopware). Commits ------- 99cb909 Remove obsolete TemplateNameParser
Problem
If a template is rendered as "@MyNamespace/some/template.html.twig", and it contains an embedded live component, then that name is used for the host template attribute. When obscuring this name, an error is thrown, because it cannot be found in the template map (which consists of real file paths).
Solution
Parse the name when compiling a ComponentNode, just like the FilesystemLoader would, so it becomes "some/template.html.twig"