Project

General

Profile

Actions

Bug #91752

open

Recursive Copy: Translation is created before Original Page

Added by Peter Piechota over 3 years ago. Updated 11 months ago.

Status:
Under Review
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 1 (0 open1 closed)

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

Actions
Actions #1

Updated by Henrik Elsner over 3 years 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.

Actions #2

Updated by Frank Berger over 3 years 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;

Actions #3

Updated by Gerrit Hübbers over 3 years 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.

Actions #4

Updated by Peter Murray about 3 years 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.

Actions #5

Updated by Benni Mack almost 3 years ago

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

Updated by Mordamir over 2 years 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.

Actions #7

Updated by Heinrich Pegelow over 2 years ago

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) {
Actions #8

Updated by Gerrit Code Review over 2 years ago

  • Status changed from New to Under Review

Patch set 1 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

Actions #9

Updated by Gerrit Code Review over 2 years ago

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

Actions #10

Updated by Gerrit Code Review over 2 years ago

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

Actions #11

Updated by Gerrit Code Review over 2 years ago

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

Actions #12

Updated by Anja Leichsenring over 2 years ago

  • Status changed from Under Review to Needs Feedback

I could use a scenario description how to create the situation in the first place.

So question is not how the failure materializes itself or how to fix it, but I need rather a step by step tutorial how I end up with a sub tree where a translated page would have a l10n_source different from l10n_parent.

Actions #13

Updated by Gerrit Code Review over 2 years ago

  • Status changed from Needs Feedback to Under Review

Patch set 5 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

Actions #14

Updated by Gerrit Code Review over 2 years ago

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

Actions #15

Updated by Dominik Dörr almost 2 years ago

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?

Actions #16

Updated by Jens Zscheile almost 2 years ago

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.

Actions #17

Updated by Gerrit Code Review over 1 year ago

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

Actions #18

Updated by Gerrit Code Review 11 months ago

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

Actions

Also available in: Atom PDF