TYPO3 8 LTS renders headers again, ignoring tt_content.fluidcontent_content.10 >

[spackmat]

Hi,

I have a provider extension with some fluidcontent content elements.

In Typo3 7 LTS, they were not enclosed in a frame div and I removed the rendering of the standard header field with tt_content.fluidcontent_content.10 >.

I installed a fresh TYPO3 8 LTS and installed my extension, but now, all my content elements are wrapped inside such code:

<div id="c3" class="frame frame-default frame-type-fluidcontent_content frame-layout-0">
    <header><h2 class="">Content of standard header</h2></header>
    [My rendered fluidcontent code]
</div>

So at first, tt_content.fluidcontent_content.10 > seems to be ignored in TYPO3 8. And second, TYPO3 8 renders this frame div around my content elements.

Both is new and bad, since there is CSS like section + section which is now unreachable, because of this code.

Am I getting something wrong? Any ideas, how I can get rid of this again? At the moment, this prevents me from upgrading all my projects to TYPO3 8 LTS.

P.S. I found this breaking change in TYPO3 8, which explains, why tt_content.fluidcontent_content.10 > doesn't work anymore. Regarding to this, the frame div should have been removed with 8 LTS, not reintroduced. I am confused.

Regarding to the Feature #79622, a simple <f:section name="Header" /> in a custom element should deactivate the content element header with ease. But I have neither luck with it.

[spackmat]

So, after a couple of hours of investigation, I found a solution raising some more questions.

1. The Layout Default.html of fluid_styled_content is used for my content elements, which all call <f:layout name="Content" />, which is also in effect (means: changes there are rendered, too)? I can override the Default.html in my provider extension, that solves my problem and gives back the control over the rendered code. But why is the Default.html used at all? This behaviour seems to be new in TYPO3 8. A closer look to the TypoScript Object Browser reveals, that tt_content.fluidcontent_content.templateName ist set to Generic and this template calls <f:layout name="Default" />. That's the reason, why the stupid Default.html layout gets rendered and has to be overridden to get rid of those unwantend frame-divs and headers.

Question is: is this the behaviour, fluidcontent wants as default?

2. But a second question: I use the following TypoScript code, to tell TYPO3, that it shall look for a custom Default.html layout:

lib.contentElement {
    layoutRootPaths {
        20 = {$plugin.tx_myextension.view.layoutRootPaths.0}
    }
}

This code is only used, when I copy it directly to the TypoScript Template of my Root page. When I have it in the setup.txt of my provider extension, it is simply ignored (with use of the constant or the direct path). Other TypoScrip-code in this file works fine and is visible in the TypoScript Object Browser. I soled this with the following code, overriding my paths only for tt_content.fluidcontent_content, which works fine in my setup.txt and the better solution as it leaves the default content elements untouched:

tt_content.fluidcontent_content {
    templateRootPaths.20 = {$plugin.tx_myextention.view.templateRootPaths.0}
    partialRootPaths.20 = {$plugin.tx_myextention.view.partialRootPaths.0}
    layoutRootPaths.20 = {$plugin.tx_myextention.view.layoutRootPaths.0}
}

So at last, all is solved, but many questions raised, if the new default behaviour is the wanted behaviour for the fluidcontent extension? At least this should be documented anywhere. Took me one full workday to find out all this stuff.

[NamelessCoder]

@spackmat I hate to say this after you spend so much time investigating, but you have to report this issue to TYPO3, not to fluidcontent. Your problems come from changes in the fluid_styled_content extension from TYPO3 core, all we do is register a CType just like you would register one for an Extbase plugin - fluid_styled_content then wraps this according to TS (which was changed).

You'll have to adapt your TS and templates to this new reality.

[spackmat]

@NamelessCoder I think it would be nice to document this new behaviour at least in the quickstart documentation. Just as the FlexForms bug is documented for flux:field.inline.fal. This would help to not frustrate new users to hell. The way to get out of this hell is quite easy and can be performed within the provider extension, so IMHO this is also an issue for fluidcontent.

[blueamerican]

https://stackoverflow.com/questions/45477841/fluidcontent-how-to-hide-default-headline-in-typo3-8/45481199#45481199