TYPO3 Core

I can confirm this issue for v9.
This happens when copying pages "recursive" in either way - via drag and drop + copy and via right click and paste after.

The issue occurs for the same pages each time, meaning if you copy the same page + subpages e.g. 5 times, the error page(s) is always the same in each copied version.

We had the same problem today, larger tree copied with several languages, some pages worked in the Page module, some did not, in the Columns view, as in two languages side by side.

But the Problem is not the order of the created copies, and not the uid of the pages.

The Problem is, that if this happens, l10n_source and l10n_parent are pointing to different pages.

On the surface this is the correct behaviour, as l10n_source should hold the historical source where it is copied from - which arguably could be done with t3orig_uid - and l10n_parent holds the logical language parent.

The problem lies in BackendUtility::getRecordLocalization, called in PageLayoutView::getTable_tt_content for table 'pages'.

here l10n_source is preferred over l10n_parent:
Line 338

$tcaCtrl['translationSource'] ?? $tcaCtrl['transOrigPointerField'],

now, if in l10n_source is the historical uid, it will not find the translated page-record, and the subsequent logic in PageLayoutView::getTable_tt_content will fail with mentioned error.

A possible solution could be that in case of 'pages' BackendUtility::getRecordLocalization always uses $tcaCtrl['transOrigPointerField'] / l10n_parent, but I don't know what other problems this might raise.

Otherwise the copy of pages should forego referencing the original translation in l10n_source in general.

For affected pages / setups this query will be a quick fix:

update pages set l10n_source=l10n_parent where sys_language_uid > 0 and l10n_source > 0 and l10n_source!=l10n_parent;

Thank you Frank, your SQL update statement helped fix this problem for our site.

Our installation was getting this exception more and more often. 251 pages in our 5000+ page installation were affected.

This Problem still exists in 10.4.17.

Thanks for the sql statement, it still fixes the issue for now.

I think there is a partly fix for the problem in place. For one record the order of records for the pages was:

uid   sys_language_uid   l10n_parent   l10n_source
100          2               101           90
101          0                 0            0
102          1               101          101

One of our clients is affected by this bug as well. The SQL statement works, but doesn't prevent the error from occuring again in the future. Is there any way to resolve this once and for all?

A "temporary" fix could look like this:

\typo3\sysext\backend\Classes\View\PageLayoutView.php on line 757

-- if (is_array($pageLocalizationRecord)) {
++ if (is_array($pageLocalizationRecord) && count($pageLocalizationRecord) > 0) {

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

Patch set 6 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

This is how I can reproduce the issue consistently with 10.4.28:

• Set "Recursive Copy" for the current user.
• Create a page (A) and a subpage (B).
• Translate B into any language (translations of A do not seem to matter).
• Hide B for the default language, but show the translated record.
• Copy A anywhere else in the page tree.

This results in the translation of B(copy) retaining B as l10n_source while having B(copy) as l10n_parent. The translation of B(copy) will have a lower uid than the default language of B(copy), which is odd as well.

Any other constellation for B did work correctly for me (both default language and translation either shown or hidden, default language enabled and translation hidden). Copying B directly works fine as well.

Can you reproduce the error this way?

I can as well reproduce the issue on 10.4.28. After the recursive copy the l10n_parent is set to the UID of the newly created page record, but the l10n_source is set to the origin page. Issue only occurs if you try to open the page in the Web > Page module with mode Languages instead of Columns.

In my case no page was hidden. I have copied 2 pages with sub pages, one with 5 and the other with 4 subpages. In the newly created tree parts, for the 3rd of the 5 subpages l10n_source wasn't correct and no page out of the 4 subpages have the right value for l10n_source after copy.

The issue will be raised in web/typo3/sysext/backend/Classes/View/PageLayoutView.php->generateLanguageView#765 because of the function BackendUtility::getRecordLocalization try to find a language overlay for the page using the column l10n_source which is not set to the newly created page record UID. So the result of BackendUtility::getRecordLocalization is an empty array and the reset of the array return false if the array is empty.

web/typo3/sysext/backend/Classes/View/PageLayoutView.php->generateLanguageView#759

                $pageLocalizationRecord = BackendUtility::getRecordLocalization('pages', $this->id, $languageId);
                if (is_array($pageLocalizationRecord)) {
                    $pageLocalizationRecord = reset($pageLocalizationRecord);
                }

How ever, the function BackendUtility::getRecordLocalization can also return false if a record is not translate able and $this->iconFactory->getIconForRecord requires an array as second parameter.

Patch set 7 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

Patch set 8 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372

I can still reproduce this in TYPO3 11.5.37. Patch set 8 seems to be working for 11 too.

This is still reproducible on 13.3.0-dev (latest main) with the test at comment 15

Patch set 9 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/71372