Bug #91752

Recursive Copy: Translation is created before Original Page

Added by Peter Piechota about 1 year ago. Updated 2 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Pagetree
Target version:
-
Start date:
2020-07-06
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

TYPO3 v9.5.18/19

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.


Related issues

Related to TYPO3 Core - Bug #93026: PageLayoutView.php with array vs bool Error in Pagetree copy actionNew2020-12-08

Actions
#1

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.

#2

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:
Line 338

$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;

#3

Updated by Gerrit Hübbers 9 months ago

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.

#4

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.

#5

Updated by Benni Mack 4 months ago

  • Related to Bug #93026: PageLayoutView.php with array vs bool Error in Pagetree copy action added
#6

Updated by Mordamir 2 months ago

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.

Also available in: Atom PDF