Error in content element rendering

[pegle]

I have definied a Flux content named "Grid". It's a content wrapper with two columns. The backend rendering in the page module works without any problems. The frontend get an error:

I have solved the issue with a hook in my ext_localconf: $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['includeStaticTypoScriptSources'][] = \FluidTYPO3\Flux\Backend\TableConfigurationPostProcessor::class . '->processData';

The processData function calls the \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin function. This function write the typoscript content for each content template in $GLOBALS['TYPO3_CONF_VARS']['FE']['defaultTypoScript_setup.']['defaultContentRendering']. The function \TYPO3\CMS\Core\TypoScript\TemplateService::includeStaticTypoScriptSources read the content from $GLOBALS['TYPO3_CONF_VARS']['FE']['defaultTypoScript_setup.']['defaultContentRendering'] befor the hook $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['includeStaticTypoScriptSourcesAtEnd'] is called. So the typoscript from flux contents will never added to the global typoscript.

My environment:

• Typo3 8.7.3
• fluid_styled_content 8.7.3
• Flux 8.2.1
• PHP 7.0 on Ubuntu 16.4

[Stuffy]

I have the same problem, except that I do not use a grid, but a normal form with input fields, sections and objects in it. The backend display when creating or editing the ce is broken, no fields are displayed, only the select box to select another ce type is there. On the Frontend, I get the same "no rendering definition" error.

My Env:

• Typo3 8.7.4
• Flux 8.2.1
• fluid_styled_content 8.7.4
• PHP 7.1.6

[Josta]

I can confirm the same two issues that Stuffy found: the tt_content rendering typoscript for Flux elements is messed up and the flux fields don't show when editing a Flux Content element. My Setup is the exact same as well.

The generated Typoscript rendering definition for an element "YoutubeVideo" is like below and looks rather like a defunct mix of css_styled_content and fluid_styled_content syntax.

flux_youtubevideo =< lib.contentElement
flux_youtubevideo {
  templateName = Generic
  20 = USER
  20 {
    userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
    extensionName = Flux
    pluginName = YoutubeVideo
    vendorName = FluidTYPO3
  }
}

I would rather expect something along the lines of

flux_youtubevideo =< lib.contentElement
flux_youtubevideo {
  templateName = Generic
  variables.content = USER
  variables.content {
    userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
    extensionName = Flux
    pluginName = YoutubeVideo
    vendorName = FluidTYPO3
  }
}

[NamelessCoder]

@Josta Thanks for pointing me in the right direction. I have now determined with certainty that TYPO3 itself generates invalid TypoScript that does not match what fluid_styled_content expects. The offending block of code:

            case self::PLUGIN_TYPE_CONTENT_ELEMENT:
                $pluginContent = trim('
tt_content.' . $pluginSignature . ' =< lib.contentElement
tt_content.' . $pluginSignature . ' {
    templateName = Generic
    20 = USER
    20 {
        userFunc = TYPO3\\CMS\\Extbase\\Core\\Bootstrap->run
        extensionName = ' . $extensionName . '
        pluginName = ' . $pluginName . (null !== $vendorName ? ("\n\t\t" . 'vendorName = ' . $vendorName) : '') . '
    }
}');

As you can see, this code intentionally generates the TypoScript by referencing lib.contentElement which is now no longer a COA but has - I don't know when or why - been changed to a FLUIDTEMPLATE directly.

Subsequently, every single last Extbase plugin registered as CType is now broken when using fluid_styled_content.

EDIT: It even looks like someone attempted to partially fix this but ended up creating a chimera with some parts thinking the parent object is a FLUIDTEMPLATE and the lines right after that, thinking it's a COA. D'oh.

[NamelessCoder]

The one that broke this: https://github.com/TYPO3/TYPO3.CMS/commit/a1b592f61f3d2bb3a2164cf363c3d815e9b7f8b3

[benjaminkott]

@NamelessCoder is was adjusted to match the rendering of csc, and makes also use of the Layouts provided by fsc (that was not the case before). CSC or FSC will fill the gabs here with the additional stuff they need for the rendering.

[NamelessCoder]

@benjaminkott Is it really intentional that tt_content.xyz = FLUIDTEMPLATE and tt_content.xyz.20 = USER? To my knowledge, FLUIDTEMPLATE won't render those objects and in my final TypoScript when I inspect it, there doesn't seem to be any sort of TS object copying going on.

[benjaminkott]

yeah, sadly that is intended for now (8.7) and was needed to work with csc and fsc. but for sure this can now be adjusted since csc is gone. Also it was already implemented like this before. https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6/typo3/sysext/fluid_styled_content/Resources/Private/Templates/List.html

It should work since the cobject is called from the template. But yeah ... a nice solution would propably look different. That one atleast worked for now without breaking everything.

[NamelessCoder]

FYI, @pegle, @Stuffy and @Josta - the solution @pegle suggested was implemented a while ago, but is part of the "Drop 7.6 LTS support" change. If I remember this right, using the "at end" variant of the hook was the only way to make 7.6 understand the TCA registrations with various issues about load order arising if not done with that hook. Since 8.7 is the minimum now and it does it correctly with the earlier hook, switching to that seems to have solved the issue. So I am closing it and referring to https://github.com/FluidTYPO3/flux/commit/9a75549fae88946de6bf9efaa28a471aa55996ac#diff-650ba9004d55b4534a27f8ad3463dc21R45.

@benjaminkott That link does indeed explain how that happens with the list_type style registered plugins - but this is a CType registered "plugin". Same difference, or?

[benjaminkott]

@NamelessCoder they actually use different templates Generic and List

The generic template is used for rendering plugins that are registered as content element or that for what ever reason want to fill their content with with a fluid variable. https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/fluid_styled_content/Resources/Private/Templates/Generic.html

The list template is only for plugins that are rendering ctype list_type. https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/fluid_styled_content/Resources/Private/Templates/List.html

[NamelessCoder]

@benjaminkott Ah, I see - thanks for linking those. Looks like it should work although it's a bit confusing due to the backwards compat.

@Josta This means both the actual TS and your suggestion are equally valid alternatives, but if both are specified then the variables.content takes priority over the .20 object (and the rendering happens slightly differently; content gets pre-rendered and passed as string).

[Josta]

@NamelessCoder Thanks for the quick response. Unfortunately the .20 syntax is not valid in the sense that it simply won't render anything on my server but the error message Content Element with uid "195" and type "flux_youtubevideo" has no rendering definition!, whereas for me, overriding the generated TS with my suggestion above worked flawlessly.

As for the other issue at hand, i.e. the missing flexform fields in the BE, I managed to find the problem: Unlike what is written here, the call to \FluidTYPO3\Flux\Core::registerProviderExtensionKey(...) has to happen in my extension's ext_localconf.php, and not in ext_tables.php (or any of the TCA Override files). The reason is that said method appends to a queue array which is read by two methods later on:

• spoolQueuedContentTypeRegistrations(): called per includeStaticTypoScriptSourcesAtEnd hook
• spoolQueuedContentTypeTableConfigurations(): called per TCA Override tt_content.php

Now if I write my call into ext_tables.php, the following happens: Since my ext_tables.php is executed after Flux tt_content.php, the second method will get an empty queue and no table configuration will be written.

I know that the link above encourages to write the call to ext_localconf.php anyway. But maybe it would be better to make that the only allowed way. I for my part simply put it into ext_tables.php without thinking much on it and then had to wonder why flux worked, but only partially.

[NamelessCoder]

whereas for me, overriding the generated TS with my suggestion above worked flawlessly.

I think this is because you did not test with dev-development where this problem is fixed, and therefore, when you configure that TS, you manually add everything that was missing.

The reason you see it in the TS object browser and template analyzer is the different hook methods used in FE and BE respectively, where only the FE one failed.

FYI, ext_tables.php is discouraged in favor of convention-named TCA override files. There's a nice article about this and how to do this the modern way: https://usetypo3.com/good-practices-in-extensions.html (TL;DR - don't use ext_tables.php and if an API method manipulates TCA, place it in an override file for the table whose TCA it changes). The FluidTYPO3 documentation / blog post is a bit outdated on this subject.

[Josta]

where only the FE one failed

That would make sense. I already wondered why it didn't work even though the fluid_styled_content Generic.html file indeed did call the .20 subtree. I guess that means I will be looking forward to the next TER update.

ext_tables.php is discouraged in favor of convention-named TCA override files

Thanks, I'm aware of that. But would the call to registerProviderExtensionKey() go in any of these files? It doesn't modify the TCA (and definitely not a single table). And since it didn't work correctly in ext_tables.php I can't imagine it working in Overrides. In fact in tt_content.php, I tested this and it didn't work.

[NamelessCoder]

But would the call to registerProviderExtensionKey() go in any of these files?

No, it would not. In the future that only ever goes in ext_localconf.php, nowhere else. Flux then uses hooks to generate the necessary configuration on-the-fly before it is needed.

[meronimo]

just to get things right. there is no bugfix so far, except adding the lines of code from @pegle to my ext_localconf.php??

TYPO3 8.7.8 PHP 7.0.25 MySQL: 5.5.57 Flux: 8.2.1