Recursive Copy: Translation is created before Original Page
After copying a page with subpages (all translated), some pages showed an error in the page-view:
Argument 2 passed to TYPO3\CMS\Core\Imaging\IconFactory::getIconForRecord() must be of the type array, boolean given, called in /var/www/.../private/typo3/sysext/backend/Classes/View/PageLayoutView.php on line 1317
Not all pages where affected though. Some work in column and language mode, some only in column mode if the original/default language is selected.
With the list view activated the error was obvious as the translated pages had lower PIDs than the original.
If only one page is copied, the issue did not occur.
Updated by Henrik Elsner about 1 year ago
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.
Updated by Frank Berger 10 months ago
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:
$tcaCtrl['translationSource'] ?? $tcaCtrl['transOrigPointerField'],
which is checked against the uid of the l10n_parent.
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;
Updated by Peter Murray 8 months ago
- TYPO3 Version changed from 9 to 10
We are still experiencing this problem in TYPO3 10.4.12, PHP 7.4.3
We also had page records with l10n_source = 0 and l10n_source!=l10n_parent which also caused the error in the page-view.
The SQL update statement helped, but preventing the pages records from getting the wrong l10n_source in the first place would be a better solution.
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
You see, if the creation order of the pages is not translated, translated, origin, the l10n_source for the translations generated after the original page are correct.