[BUGFIX] Fix contentAs feature when used on Layout level#469
[BUGFIX] Fix contentAs feature when used on Layout level#469smichaelsen wants to merge 1 commit intoTYPO3:mainfrom
Conversation
|
Thanks for the report and fix. Would you be able to add a functional test case for this? You can have a look at the existing tests. |
|
Thanks for your feedback, Mathias. I fear I can't add a test at the moment (deadlines and stuff). Would that block my PR from being merged? |
|
Of course not. I'll have a look at this. |
a1631a9 to
4ea540e
Compare
|
@NamelessCoder I've added a test for this now which looks basically correct but still fails. Can you have a look? |
NamelessCoder
left a comment
There was a problem hiding this comment.
Two main issues need to be addressed:
- There is copy/paste content in the example PHP file doc comment and it should not assign a "layout" variable.
- More importantly, the way these variables are assigned will "bleed" them after the section is rendered because they are assigned not in a copy of the variable provider, but in the root instance from which copies are derived. This puts the variables in all sections rendered after, makes the variable available to the layout file as well and overwrites any identically named variable that was passed to the template being rendered.
The second point is rather complex, I know. Solving it kind of implies that we must also clone the rendering context when rendering sections-in-template from a layout (same as in the "rendering template" case) and this has other side effects as well because the template no longer has access to the original rendering context.
You could experiment with removing the case I annotated. We might be able to live with the side effects...
src/View/AbstractTemplateView.php
Outdated
| if ($this->getCurrentRenderingType() === self::RENDERING_LAYOUT) { | ||
| // in case we render a layout right now, we will render a section inside a TEMPLATE. | ||
| $renderingTypeOnNextLevel = self::RENDERING_TEMPLATE; | ||
| foreach ($variables as $key => $value) { |
There was a problem hiding this comment.
This is the dangerous line. It operates on the not-cloned RenderingContext retrieved from getCurrentRenderingContext so assigning variables here, bleeds the variables to other sections and the layout's subsequent code.
There was a problem hiding this comment.
$renderingContext = $this->getCurrentRenderingContext();
$renderingTypeOnNextLevel = $this->getCurrentRenderingType();
if ($this->getCurrentRenderingType() === self::RENDERING_LAYOUT) {
// in case we render a layout right now, we will render a section inside a TEMPLATE.
$renderingTypeOnNextLevel = self::RENDERING_TEMPLATE;
if (empty($variables)) {
$variables = $renderingContext->getVariableProvider()->getAll();
}
}
$variableProvider = $renderingContext->getVariableProvider()->getScopeCopy($variables);
$renderingContext = clone $renderingContext;
$renderingContext->setVariableProvider($variableProvider);
`<f:render section="MySection" contentAs="content">some content</f:section>` did not work when called from a Layout because the `contentAs` variable was not passed to the template section in that case.
4ea540e to
68db27f
Compare
<f:render section="MySection" contentAs="content">some content</f:section>does not work when called from a Layout because thecontentvariable is not passed to the section in that case.