TYPO3 Core

Just checked https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/fluid_styled_content/Configuration/TypoScript/Static/Setup/lib.fluidContent.ts and partialRootPaths.10 should be ok. Can you check the typoscript object browser to see what paths are set.

TSOB says:
page.10.partialRootPaths.10 = fileadmin/templates/Partials

Changing the priority of the partial to 200 doesn't solve the problem.

The cause of the problem lies in typo3_src-8.2.1/vendor/typo3fluid/fluid/src/View/AbstractTemplateView.php.

Method render():

$this->baseRenderingContext is not set. It should be set by the method "setRenderingContext()", which gets called from __construct().
However, the constructor does not get called. I tried putting a simple "die()" in the constructor, which had no effect.

still present on 8.3-dev (latest master)

Regarding:

The cause of the problem lies in typo3_src-8.2.1/vendor/typo3fluid/fluid/src/View/AbstractTemplateView.php.

This is not correct. StandaloneView overwrites the constructor and supplies its own RenderingContext. The method is not expected to be called when rendering via StandaloneView. The baseRenderingContext is set by `setRenderingContext` which is called in StandaloneView::__construct. So, that part is completely in order and not the cause of this problem. Furthermore, if no rendering context was set, you would see fatal PHP errors (yes, it is a less than ideal approach to use a completely overwritten constructor, but there are reasons why this is done. The main hint is that the view is standalone).

Still working to find the cause and solve the problem.

I've been trying for some hours now to reproduce this problem with no luck. Using a blank site with only fluid_styled_content TS loaded and the following custom setup:

page = PAGE
page.10 < styles.content.get

page.200 = FLUIDTEMPLATE
page.200.file = fileadmin/templates/Index.html
page.200.partialRootPaths {
    10 = fileadmin/templates/Partials/
}

page.300 = FLUIDTEMPLATE
page.300.file = fileadmin/templates/Other.html
page.300.partialRootPaths {
    10 = fileadmin/templates/OtherPartials/
}

With all paths containing exactly the Footer.html template.

I get the correct expected result when rendering any of those objects. In CMS the View instance creates a fresh rendering context on each FLUIDTEMPLATE object and the Fluid compiler generates three different compiled partial templates.

The one thing I was able to find were some redundant lines in the AbstractTemplateView class which caches partial identifiers in the View - which is not necessary (done at very next level inside TemplateParser anyway). This would break code where a custom View implements SingletonInterface (Views should never do this) or is treated as a singleton by code (e.g. stored in an internal cache and reused). I will prepare a fix for that but I can't see how it would affect this issue.

So please re-confirm that this is still an issue and if it is, include your entire TS object including the `.file`, `.templateName` or whatever you use. If it is no longer a problem please close the issue.

Claus, thank you for your investigation.
I could not reproduce the problem in an almost blank TYPO3 8.3.1 either. Maybe it was solved somewhere between 8.2.1 and 8.3.1.

Issue can be closed.

Hey, here is a sitepackage to reproduce the error.
https://github.com/benjaminkott/example_package

As soon as the variable with a fluid styled content applied, paths for the page will be overwritten then the ones from fsc are used.

Daniel Goerz wrote:

Hi,
what is the status here? Björn, I doubt you are still on it after 3 months, right? ;)

I was able to reproduce this while trying to solve this SO issue: http://stackoverflow.com/questions/41418911/typo3-v8-5-with-fluidtemplate-and-fsc-partials-not-working
Reproduces it as desribed in the SO question.

The same bug occurs if 2 or more extensions use the same name for a layout. e.g. news uses the layout name "General". If you have an extension that uses the same name it will result in broken output.

How did 8.7 even get released with a MAJOR breaking bug like this? Basically renders 8.7 useless to anyone who needs to develop extensions or even install them..