b13/container

Move Item after Container failed

Ranunzel opened this issue · 11 comments

Its not possible to move a Content Element after a B13 Container

Latest version b13 Container
TYPO3: 12,4,7

The Issue happens in:
Classes/Hooks/Datahandler/CommandMapBeforeStartHook.html Line 145.
The Fix is:
(add after line 145)
if ((int)$value['update']['tx_container_parent'] > 0) {
$target = $this->containerService->getAfterContainerElementTarget($container);
} else {
continue;
}
garbast@cfdb180

Did you execute typo3 container:sorting --apply ?

Did you execute typo3 container:sorting --apply ?

Recently switched from gridlelements to containers v2.3.1 on a Typo3 10.4 installation and have users experiencing the same issue. How often does this command need to be run and where can I find documentation on what it does? Also, I have the container_migratesorting upgrade task. Does running the upgrade wizard fix this? Thanks.

Do you still have gridelements installed? Looks like this could cause conflicts #475 (comment)

Installed but deactivated. Do I need to fully uninstall it? I inherited a legacy site from many years ago and we use the Extension Manager.

As far as I understand it, you need to run typo3 container:sorting --apply only once when migrating to EXT:container 2.0

Except you have any other script or tool, that manipulates the tt_content.sorting field. If you can ensure, it's not EXT:gridelements which manipulates the field, I'm pretty sure there is any other script or extension in your project, that does it.

This issue looks like it got duplicated by #500.

We encounter the same issue.

I guess this bug got introduced via 149 with a1cc4de.
With the following explanation:

* element after a container
 * old: -uid of container is used (leeds to broken sorting)
 * new: -uid of last child in containers last column is used

I don't know why it should lead to broken sorting, right now it seems the other way around. And the proposed fix also seems to revert that change.
So this bug seems to be explicitly a fix for something else, but I can't get my head around it.

I will now test the suggestion to execute the command (multiple times as the instance has nested containers). That might solve the issue as the last element then might have a higher sorting value which would than be used for pasting.

Executing the command didn't solve the issue.

There is a functional test ensuring that moving properly works. So I guess the command is for some reason unable to properly fix the broken sorting in our instance.

@DanielSiepmann it would be helpful to provide a simple dump of the corresponding tt_content records, do reproduce the bug on a vanilla TYPO3 instance

A colleague of mine will further investigate.
We will try to come up with a proper cleaned dump if we can't figure it out.

I don't know if this fits the case exactly. I once analyzed this for a case in one of our projects. We were unable to move a certain content element before the previous content element in the project.
Unfortunately, the commands to clean up the sorting did not solve the problem, because in the case of nested containers, the $lastChild of the current container is not correctly retrieved.
I'll provide a PR soon.