Bug #92198

Localize method gets wrong PID from records generated during former free mode translations

Added by Jo Hasenau about 1 year ago. Updated 4 months ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Localization
Target version:
Start date:
2020-09-04
Due date:
% Done:

100%

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

Description

Marked for CMS 11 - but happens in any supported version as well.

If translations have been done in the so called "free mode" aka "copy mode", you can move around the translated elements after the actual localize actions.

If you move those elements to another page now, they still point to the record of the default language via the field configured as "translationSource".

Unfortunately this information will again be used for upcoming localize actions, since the destination PID will be either a real PID or a negative value pointing to a record after which to position the translation copy.

This will lead to problems in lines 7249 to 7255 of \TYPO3\CMS\Core\DataHandling\DataHandler

// If there is an element, find its localized record in specified localization language
if ($previousRow = $queryBuilder->execute()->fetch()) {
    $previousLocalizedRecord = BackendUtility::getRecordLocalization($table, $previousRow['uid'], $language);
    if (is_array($previousLocalizedRecord[0])) {
        $previousLocalizedRecordUid = $previousLocalizedRecord[0]['uid'];
    }
}

BackendUtility::getRecordLocalization will just use the UID of the record but not check the PID, so it might return a record from a different page based on the translationSource field.
Now this will lead to a wrong PID for each of the following records, since they will be copied "after" the first one with the wrong PID.

The result is a mixed up set of elements with different PID values which actually should be on the same page after the localize action.

Of course they could be moved around in free mode after that action, but for the actual localization only records from the same PID should be taken into account.

People noticed that behaviour when dealing with nested Gridelements structures, but even without any additional Gridelements methods activated the problem stayed the same.
Should be similar with any other localize action that involves translated elements which have been moved to another page before.


Related issues

Related to TYPO3 Core - Bug #92783: Record inserted on wrong pidClosedPhilipp Parzer2020-11-06

Actions
#1

Updated by Jo Hasenau about 1 year ago

  • Description updated (diff)
#2

Updated by Denis Mir 10 months ago

I don't know what to say but this problem is getting more and more serious. We got this error now on a lot of projects. Translation of pages (and their CEs) does lead to records being assigned random PIDs. Random PIDs means that they appear on completely different pages. This can't wait till 11 LTS!

#3

Updated by Oliver Hader 10 months ago

  • Status changed from New to Accepted

I did not not into the details, but it sounds reasonable.
Does this misbehavior only happen in the backend?
And if yes, for which actions and having which implication?

Thx for your feedback.

#4

Updated by Gerrit Code Review 10 months ago

  • Status changed from Accepted to Under Review

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/+/66552

#5

Updated by Philipp Parzer 10 months ago

  • Related to Bug #92783: Record inserted on wrong pid added
#6

Updated by Denis Mir 10 months ago

Thank you very much for looking into the problem.

I have debugged it with Jo Hasenau after incorrectly blaming gridelements to be the cause for content elements that went missing after a simple translation process (copy mode) in the backend by our editors.

It happens when you translate the page content in free mode (copy mode). Editors translate the page content of a page in the page module of the backend. They choose the free mode in the modal.

Now it appeared that some content records get copied correctly and other content records are missing in the translation. Selecting for the specific page id and sys language uid in "tt_content" made it clear that they somehow disappeared.

At first I thought that only the gridelements columns are incorrectly assigned but thats not true missing records are not assigned at all to this page id. In development I was able to find the missing records by selecting only for the specific "crdate" of the copying process. (the correct crdate could be found by looking at the correctly copied records) So when only selecting for the "crdate" I get all the correctly copied records + the missing records. Only difference is the different pid.

Jo and I did found out that the incorrect pid comes from the translationSource. (Jo describes it in the issue description I can't do better)

For the editor it does mean that the translated records are gone and can only be fixed (at the moment) by juggling directly with the database. But it does also mean that these missing records do appear now on a completely different pages. (and these other pages look broke now)

If you need any more information I will provide it for you.

#7

Updated by Oliver Hader 10 months ago

Thanks for your feedback. The next steps seem to be

  • create new functional tests to reproduce and demonstrate the scenario ("showing the database inconsistency")
  • find potential solutions for the behavior in particular
#8

Updated by Oliver Hader 10 months ago

  • TYPO3 Version changed from 11 to 10
#9

Updated by Gerrit Code Review 10 months 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/+/66552

#10

Updated by Denis Mir 8 months ago

Guys please do finally merge that patch. This is a huge bug and it bugs us on every single project now. Content elements appear after translation on a random page. This is a blocker for every professional project.

#11

Updated by Gerrit Code Review 8 months ago

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/+/66552

#12

Updated by Gerrit Code Review 8 months ago

Patch set 6 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/+/66552

#13

Updated by Sybille Peters 7 months ago

@Jo and @Denis

Apart from the bugfix / patch: If I understand this correctly, if you are already affected you will have to fix it in the database. The patch will only fix this happening in the future. I that correct?

Can you add more information:

  • How to reproduce the problem
  • How can you check if you may be affected by this? (e.g. check for translationSource on different pid?)
  • Is there a way to fix this in the database (e.g. set value for translationSource to 0 if pid of translation differs from pid of translationSource) for records already copied.
  • Are any log messages / error messages produced?

I have not exactly understood the nature of the error.

I unsuccessfully tried to reproduce it.

(Understanding and reproducing the problem might also make it easier to test and review the patch).

#14

Updated by Christian Kuhn 6 months ago

Seems we're suffering from that in a project, too. Will fix / finish the patch now.

#15

Updated by Gerrit Code Review 6 months ago

Patch set 7 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/+/66552

#16

Updated by Gerrit Code Review 6 months ago

Patch set 8 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/+/66552

#17

Updated by Gerrit Code Review 6 months ago

Patch set 9 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/+/66552

#18

Updated by Gerrit Code Review 6 months ago

Patch set 10 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/+/66552

#19

Updated by Gerrit Code Review 6 months ago

Patch set 11 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/+/66552

#20

Updated by Gerrit Code Review 6 months ago

Patch set 12 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/+/66552

#21

Updated by Gerrit Code Review 6 months ago

Patch set 13 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/+/66552

#22

Updated by Gerrit Code Review 6 months ago

Patch set 14 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/+/66552

#23

Updated by Gerrit Code Review 6 months ago

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

#24

Updated by Gerrit Code Review 6 months ago

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

#25

Updated by Philipp Parzer 6 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#26

Updated by Benni Mack 4 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF