TYPO3 Core

So we got the following problem. We tried to recursive copy a translated page with 1 level of sub pages. We saw that in the page modules language comparison view we got for the copied page translation all content elements marked as "unused elements".

This is the same behavior like here.

https://forge.typo3.org/issues/91752

A fix for the symptom is developed here -> https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

The reason for this behavior is the "l10n_source" for the copied translated page record is still set to the UID of the original default page record.

After some debugging I can say that the cause of this issue is in the DataHandler class in the method "\TYPO3\CMS\Core\DataHandling\DataHandler::int_pageTreeInfo".

The method tries to hand back a sorted list of page uids for a root pid.

Sorting is done with the "sorting" field. BUT the problem is that default page records and connected translated page records share the same "sorting" value. This leads to database engines picking the order depending on DB implementation internals.

This leads to the sorting that you can see in the added screenshot.

From the screenshot I can already tell you that "8809" and "8805" will get copied incorrectly with their copied translation page records getting the incorrect "l10n_source" set.

This is due to "$CPtable = $this->int_pageTreeInfo([], $uid, (int)$this->copyTree, $theNewRootID);" getting the incorrect order in "\TYPO3\CMS\Core\DataHandling\DataHandler::copyPages" and "\TYPO3\CMS\Core\DataHandling\DataHandler::copySpecificPage" getting now called in the wrong order. So the original translated page record gets copied before the original default record which finally leads to the incorrect "l10n_source".

In the end "\TYPO3\CMS\Core\DataHandling\DataHandler::int_pageTreeInfo" should in this case just take the "sys_language = 0" records into account which would solve the issue.