[BUGFIX] Missing rendered children in preview workspace

[JanStorm]

As described in Issue #2158 children are not rendered when previewing changes made in the preview workspace:
I have encountered the same problem.
The Problem is that when rendering the content records of a workspace element, that they are identified by their colPos, which are based on the uid of the LIVE-element.

As example, we have these Elements:

• a LIVE-version of a content element with the uid 42
• a PREVIEW-Version of the same content element with the uid 43
• The Live-Version contains 2 child column elements assigned with colPos 4201 and 4202 by the ColumnNumberUtility::calculateColumnNumberForParentAndColumn function.
• A Element in Preview Workspace that results in a third column child with colPos 4203.

With this set, we render the preview element:
We see that the "placeholder" (the preview element) is used instead the original:

// Classes/ViewHelpers/Content/GetViewHelper.php
if ($workspaceId) {
    $placeholder = BackendUtility::getWorkspaceVersionOfRecord($workspaceId, 'tt_content', $record['uid'] ?? 0);
    if ($placeholder) {
        // Use the move placeholder if one exists, ensuring that "pid" and "tx_flux_parent" values are taken
        // from the workspace-only placeholder.
        /** @var array $record */
        $record = $placeholder;
    }
}

Rendering the preview results in the child elements being searched by colPos 4301, 4302, 4303, ... (Again, because of ColumnNumberUtility::calculateColumnNumberForParentAndColumn).
The Problem here is that we want to render also the live elements, which have the colPos 4201, 4201, ...
So no children are rendered.

So as a solution, i kept that information about the original record and used it then to also check for rows in this live record.

[NamelessCoder]

Thanks for the patch @JanStorm.

Just restating for my own understanding: the underlying cause here is that there are no workspace versions of the parent record's children but the parent has a WS version, which causes FE to render the WS version of the parent and use that version's UID to calculate colPos, which in turn causes FE to only show children which were created or moved in the workspace (if it shows any children at all).

About the proposed patch:

Usually it's not the right approach to mix things together like this (also, that causes unexpected things with sorting order and such). The right solution might instead be to create workspace versions of the parent's child records when when a parent record is modified in workspace. It may also be necessary to create a WS version of the parent and WS versions of all children when a child is changed in WS. This should give the right result:

• If a parent isn't touched in workspace, there's no WS placeholder and the UID is the live record's UID -> orginal colPos is good.
• If the parent is in any way touched (sorted, edited, unhidden, etc.) a WS placeholder is created and UID is the WS placeholder's UID -> colPos is no longer the colPos of the original.

By making WS versions of all child records, and ensuring those child records have the colPos calculated from the WS version of the parent, the puzzle should fit - without needing to change things in FE context. We would have two complete sets of parent+children.

And this probably needs to be full recursive.

By the way:

What happens when you actually publish those workspace versions? Is the colPos changed to the one belong to the live version of the parent - or does it stay the one belonging to the workspace version of the parent?

[JanStorm]

Thanks for the quick response!

Yes you're right! I wasn't really happy with the solution either, but have no deep understanding of the workspace functionality. It would be much more consistent to have two complete sets of parent+childrens.

To achieve this, i have a small technical question you may are able to answer:
There is no event for when a WS version of a dataset is created, is there? Do I have to guess that from the corresponding function in the DataHandlerHook itself? The few PSR-14 events used by the WS-extension do not seem to help in this case..

Then, i need to correct something. In my previous example, the third column children actually would result in having a colPos of 4203. So all children, whether they are create from WS or not, always have the colPos calculated with the uid of the live element. Thats what i tested today, see this excerpt from tt_address: This shows the result of modifying the live-element (4003) in the WS, by adding a new pane. This produced the WS-copy (4066) and i added a Child 4 to the new pane, also inside the WS.
I will update the example in my first comment asap to avoid confusion.

That also answers your last question: because all children already have the colPos of the live-parent, not a single colPos is changed when the workspace version is published and all children are shown as expected.

Unfortunately I have no capacity in the near future to develop the cleaner solution, but i assume you can close this PR for now and i will open a new one as soon as i have a solution ready (in case no one else was faster).

[NamelessCoder]

All of this logic would be in the DataHandlerSubscriber - which tends to be pretty complex. But the good news is that I think this will just be a matter of propagating a version action to all children, and there's already a method dedicated to this kind of propagation (for things like the remove action to recursively remove all children of a deleted parent).

And it sounds like we don't even need to further post-process after propagating the action. That is, assuming the colPos values are indeed all correct even for new created content in WS. I'm not 100% sure but we might need to also change the FE rendering to ensure the colPos it uses for selecting content, is based on the live record even when parent is a WS version.