nesting in flux/fluidcontent not possible when using backend layouts

[smichaelsen]

Using fluidcontent and flux with TYPO3's backend layouts doesn't work for me. Flux adds a new item to tt_content's colPos field

$TCA['tt_content']['columns']['colPos']['config']['items'][] = array(
    'LLL:EXT:flux/Resources/Private/Language/locallang.xlf:tt_content.tx_flux_container',
    \FluidTYPO3\Flux\Service\ContentService::COLPOS_FLUXCONTENT
);

But the TYPO3's BackendLayoutView class discards the colPos items and regenerates the list according to the configured backend layout, so the flux content item is missing and you can't nest content elements in flux elements anymore.

I've done a quick fix for myself by extending the BackendLayoutView class and re-add the item manually after the backend layout items were parsed.

https://gist.github.com/smichaelsen/d0677bb6f1bb0d38db8b

[smichaelsen]

This occurs in TYPO3 6.2.15.

[NamelessCoder]

Hi Sebastian,

This issue is a bit complicated - I'll explain our limitations here and hope maybe you get some idea I haven't come up with ;) it affects everything, not just FluidTYPO3. And it's likely to increase in restriction later, when the backend layout engine of TYPO3 is expanded.

Generic problem

An additional colPos value must be added dynamically or permanently but must appear regardless of layout configuration.

Possible implementations

1. An itemsProcFunc can be created
2. Items can be appended to TCA list
3. A DataProvider for backend layouts can be created
4. Page TS configuration can be created
5. Class replacements for a significant number of classes can be created (PageLayoutView, BackendLayout etc.)

Evaluation of implementations

1. Although itemsProcFunc is the former preferred solution, it was always limited in that only a single items processing function may be registered for any field. This means that if we add ours, we block others from doing the same. For a long time both Flux and Gridelements used this approach - but it was then replaced by the DataProvider pattern (see 3).
2. Items that are appended to this particular list in TCA are only visible if no backend layout is selected. And because Fluidpages and basically any user-selectable backend layout provisioning (except for raw pageTSconfig) require that a DataProvider is used (in order to dynamically provide the layout based on the template file) we cannot safely add to this list.
3. The DataProvider - now, this was invented to get around the limitations of item 1, the singular nature of itemsProcFunc. But sadly this pattern was invented in an almost equally singular way: now, only one DataProvider is allowed for any field, so the problem remains the same: values can only come from one source and if another DataProvider source is used, no other implementations can add these values. This is why we add the column position value from Fluidpages although logically it absolutely belongs in Flux. Essentially: the DataProvider pattern overrules all others and is not sufficiently flexible to be used for our purpose; in Flux that is.
4. PageTSconfig is an alternative but only applies if the site already uses pageTSconfig-based backend layouts. Selecting any backend layout makes the column disappear unless the column is also defined in the backend layout that is then selected. It might be possible to add enough conditions around the pageTSconfig that we might provide, that it only applies when the page doesn't define or inherit a backend layout... until now unverified. Not pursued because it only covers a minority of setups that are (sorry to say) considered legacy.
5. Due to the number, complexity and size of classes we would need to override, it is a priori not an option. We have had cases of being forced to create class replacements and it always, without exception, leads to conflicts in which versions of TYPO3 we can support; or the need to create one version of class replacement for every TYPO3 version. The main limiting factor is that no public API exists for manipulating the list of items for all of the outlets that can consume the list.

Additional problem: any method(s) used would have to scan the existing values in order to not add duplicates. There is no protection against this in TYPO3.

Conclusion (so far)

It's not a nice feeling but we are extremely confined by the situation and unfortunately it doesn't appear to be an easy fix in any way. We have had discussions internally in the team many times (more than a year ago) and the compromise of adding the value via Fluidpages was the result of those.

The best conclusion I've been able to come up with so far, as advise to anyone facing your situation, is to manually add 18181 to the list of column positions in whichever implementation you use. Due to the fact that we cannot provide all implementations without causing even more problems (like spammy duplicates of the column position value).

Do you know of any ways we might solve this puzzle?

[NamelessCoder]

Oh forgot to mention there is one thing I considered that I didn't mention above: submitting to the TYPO3 core a patch that changes the behavior of DataProviders in one very significant way:

Rather than only consult the DataProvider the user selects, we instead consult every DataProvider and include in the call which DataProvider is currently selected. This would then put the responsibility of deciding whether or not to actually provide any values completely on the DataProvider. But it's a major breaking change and since it definitely breaks and demands a change from Gridelements among others, it might face some resistance.

[NamelessCoder]

@mneuhaus Marc, you've got a nice big juicy brain - what does it say about this? :)

[mneuhaus]

So, i left my box at work and started to think a bit. i might have an idea which could work, but i didn't write any code/prototype so far so this might even be quite a stupid idea:

DataProvider itself seems to be the proper way to go, but can only handle a singular source. TYPO3 Core change would be the preferable way to go in the long run, but not doable retroactively to older TYPO3 Versions.

I think there is a way in which we could jam the basic approach claus mentioned in #940 (comment) without any TYPO3 Core change and maybe even with clean backwards compatability:

1. hijack $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['BackendLayoutDataProvider'] by replacing it with a custom MultiDataProviderBridgeArrayDingsy.
2. anything already set in that array gets appended to the ArrayObject.
3. Luckily, the DataProviderCollection that's populated in the BackendLayoutView accepts not only className but Objects as well
4. We always give back a ProxyDataProvider that handles the logic described in nesting in flux/fluidcontent not possible when using backend layouts #940 (comment)

This behavior could even be made into a switch in the extension configuration to only be turned on if needed

[NamelessCoder]

I'm afraid that since last update, Marc and I had a rather long ping-pong about this and tried to cover all the angles - unfortunately even the "proxy" approach won't save us here (even if it would work wonderfully in many other places, so we'll remember it for later). There really is no other way here than either living with this or attempting to drive a (breaking) change into TYPO3 itself.

...which I currently can't promise to do inside a reasonable time frame. If anyone else may be able to help with this then please assist. I can help out with knowledge and can press the +1 button once a fix is submitted to the core!

[NamelessCoder]

https://forge.typo3.org/issues/70560 is the best I can do at this time.