Skip to content

Cut/paste of a container leaves children on the source page when a later column has the lowest sorting - #784

Open
mtness wants to merge 1 commit into
b13:masterfrom
mtness:bugfix/move-container-reversed-child-sorting
Open

mtness wants to merge 1 commit into
b13:masterfrom
mtness:bugfix/move-container-reversed-child-sorting

Conversation

@mtness

@mtness mtness commented Nov 3, 2026

Copy link
Copy Markdown

TYPO3 14.3.10, container 4.1.1, also on master 3a44aaf.

Steps

  1. container_3cols on page A, one child in each of colPos 101, 102, 103.
  2. Give the child in the last column the lowest sorting of all children (mine, from an import: 101 → 192, 102 → 384, 103 → 96, container 256). container:sorting reports this as inconsistent, but nothing prevents it from arising through imports, copies or moves ([BUG] Copy container to another page (same language) breaks sorting — new elements land at top of column #726, [BUG] Drop-at-top of a container child column places element at bottom when container.sorting > min(child.sorting) #738).
  3. Cut the container, paste it on page B.

Actual: the container and the colPos 101 child move to B. The colPos 102 and 103 children stay on A; sys_log shows "Moved record … on page A" for them.

Cause: children are fetched ORDER BY sorting, so getChildrenColPos() returns 103, 102, 101. copyOrMoveChildren() walks the columns in that order and rewrites each child's target to -uid of the last child of the previous column — a child still on page A. This is the residual case of #291, whose fix iterates getChildrenColPos(), and the same target anchoring as in #738.

Fix: process the columns in getAllAvailableColumnsColPos() order. Functional test moveContainerOtherPageOnTopWithChildSortingBeforePreviousColumn reproduces it (red before, green after). PR: .

Fixes: #291
Related: #738

The children of a moved or copied container are handled column by column,
and the target of a column is the last child of the previous column (see
ContainerService::getNewContentElementAtTopTargetInColumn()). The column
order was taken from the children records, which are fetched ORDER BY
sorting: if the child with the lowest sorting is not in the first column,
the target of another column is a child that has not been moved yet. That
target resolves to the pid of the source page, so the child stays behind
on it.

Use the configured column order of the container CType instead, the same
order the target is resolved with. Children with a colPos that is not
configured for the container are still moved, after the others.

Fixes: b13#291
Related: b13#738
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cutting-pasting a multi-column container to another page will only move children from first column with elements

1 participant