TYPO3 Core

Important: the records don't get lost in the backend, only in the frontend view. The strange thing is, it seems to be quite random... sometimes all the records are gone. Sometimes there is still one of 10 left. Sometimes it simply works. One time it helped to edit and save the parent record after moving...

Could this be some strange Ajax-Timing thing or so? The only alternative explanation would be, that I'm hallucinating or my computer or something/somebody else wants to drive me mad.

And one more strange thing:
After moving around the parent record with a bunch of children, I get a lot of paging links [1]²³⁴... in the workspace module. If I chose one, there is nothing to see.. Even the setting behaviour.disableMovingChildrenWithParent = true doesn't change anything.

And.. there it was again. I'm not mad. Moving the parent record in draft workspace makes the children disappear in the frontend! What helps is to edit the parent record and save it. The children are back again. WTF? Workspace magic?

Another info: when the child loss happens, the backend UI seems to lag somehow, it takes longer for the "move". When the move happens quickly on click, the children don't get lost. So I really guess some Ajax stuff. When I open the parent record in the backend, I can see all children. However, only after I save the record, the children are back. Not after I open it in the backend (and can see all the children).

Now I have the systematics behind the child-loss:
I happens the FIRST time I move the parent record in the draft workspace (I just change the sorting position). At this point, it takes a long time (2-3 seconds) for the UI to get back, I guess it's because all the overlay records are created. This happens also with the option 'disableMovingChildrenWithParent' => true.
After that, the child records are gone in the FE. When I open and save the parent record (just that), the children come back in the FE.
When I move around the parent record AFTER that, it works. No child loss. And the move happens quick. I guess because the whole bunch of child record overlays are already created.

The thing is, all the children of my parent record have quite a bunch of fileReferences a children themselfs, so this whole bunch is processed somehow. No matter if I just want to change the sorting of the parent.

Is this a bug, or is there something that I can do about that? Just to be clear, it's not thousands of child records, maybe 100 and some of them have some images (file-references).

I checked all the logs the if something throws an error, memory limit or something. But no, I can't see anything.

Still waiting for some kind of feedback or confirmation from other users / devs.

This Mächler wrote:

Same thing happens in TYPO3 10.4
Please fix this!

Generally: fix workspaces (backend / frontend), or drop the feature. It's very annoying

Hey,

thanks for the report.

• Did you create the parent in a workspace or is this an existing record which was created in live?
• Is there a difference between doing this as admin or an editor?

Thanks in advance.
Benni.

Benni Mack wrote:

This Mächler wrote:

Same thing happens in TYPO3 10.4
Please fix this!

Generally: fix workspaces (backend / frontend), or drop the feature. It's very annoying

Hey,

thanks for the report.

a few questions for me to reproduce:

• Did you create the parent in a workspace or is this an existing record which was created in live?

I guess the parent record was originally created in live workspace. At least it was live at the time I tried to move it in draft.

• Is there a difference between doing this as admin or an editor?

No, it seems not.

Thanks in advance.
Benni.

While reproducing this, the parent record suddenly got duplicated... same UID, same children. In the FE and in the BE. Different bug, I reported it also some time ago. And it's not possible to rollback / discard, because the Workspace-Module does not work after moving records (generally, no matter if they have children). Also reported some time ago. Big mess.

Thanks for looking at this
Thĩs