Looping the same changes: fixing pid, reversing pid

[jpmschuler]

I have an 11LTS which started in v3.6, so should be a good test case.

I did 3 instances of

• vendor/bin/typo3cms referenceindex:update
• vendor/bin/typo3cms dbdoctor:health --mode=execute

And after a lot of changes in the first run, each run now is green except for two steps:

Scan for sys_file_reference records with invalid pid
----------------------------------------------------

 [UPDATE] Records in "sys_file_reference" must have "pid" set to the same pid as the
          parent record: If for instance a tt_content record on pid 5 references a sys_file, the
          sys_file_reference record should be on pid 5, too. This check takes care of this.

 UPDATE `sys_file_reference` SET `pid` = 28067 WHERE `uid` = 29713;
 UPDATE `sys_file_reference` SET `pid` = 28068 WHERE `uid` = 29841;

and later

Scan for record translations on wrong pid
-----------------------------------------

 [UPDATE] Record translations use the TCA ctrl field "transOrigPointerField"
          (DB field name usually "l10n_parent" or "l18n_parent"). This field points to a
          default language record. This health check verifies translated records are on
          the same pid as the default language record. It will move affected records, or
          set them to deleted or remove them if there is another translation of that record
          on the correct pid.

 UPDATE `sys_file_reference` SET `pid` = 24618 WHERE `uid` = 29713;
 UPDATE `sys_file_reference` SET `pid` = 28067 WHERE `uid` = 29841;

I didn't quite get why this is the case, just started with dumping the relevant data, but couldn't grasp it yet. Will circle back as soon as times come up, because I'd like to run this command regularly as a health check.

sys_file_reference uid	pid	hidden	deleted	sys_language_uid	l10n_parent	tablenames	fieldname	uid_foreign
29713	24618	0	0	1	29731	tt_content	image	76537
29730	28067	0	0	0	0	tt_content	image	76552
29731	24618	0	0	0	0	tt_content	image	61362
29841	28067	0	0	1	29730	tt_content	image	76635

tt_content uid	pid	hidden	deleted	sys_language_uid	l10n_parent
61362	24618	1	0	0	0
76537	28067	0	0	1	0
76552	28067	0	0	0	0
76634	28068	0	0	0	0
76635	28068	1	0	1	76634

pages uid	pid	hidden	deleted	sys_language_uid	l10n_parent
24440	24431	0	0	0	0
24618	21180	0	0	0	0
27451	27443	1	0	0	0
28067	28069	1	0	0	0
28068	28069	1	0	0	0
33411	21180	0	0	1	24618
34353	28069	0	0	1	28067

[lolli42]

Ok, I don't get it by looking at it.

Thanks for the record lists already!

Could you maybe add the current state of sys_file_reference:29731 and sys_file_reference:29730 as well, and see if their 'pid' entries point to records that you list in the 'pages' table already, or eventually add them as well?

[jpmschuler]

add the current state of sys_file_reference:29731 and sys_file_reference:29730 as well

Could you specify more what is missing, or was it not just not clear enough?

I thought the first table would do that and the SQL statements would make clear that only the pid is changed. I made that existing data more clear by explicitly using two table variants.

[lolli42]

l10n_parent of sys_file_reference:29713 points to sys_file_reference:29731, and l10n_parent of sys_file_reference:29841 points to sys_file_reference:29730

I'm interested in the rows of sys_file_reference:29731 and sys_file_reference:29730

Or am I totally confused right now?

[jpmschuler]

Oh my bad, how obvious. Updated. Will pinpoint the problem after lunch.

[jpmschuler]

My current interpretation (also I am not 100% sure because wow is this complex).

The IMAGE-L1 (SFR record 29841 with sys_language_uid 1) has following details

• IMAGE-L1, IMAGE-L0 (its l10n parent) and the CONTENT element pointing to IMAGE-L0 are on page 28067
• sadly CONTENT element pointing to IMAGE-L0 is on page 28068

So the first check moves IMAGE-L1 to that page.

That is a bad idea in this special case because these two CONTENT elements are not related.

Expected connections between tt_content translations and sys_file_relation translations is as follows:

Content-L0 ---- IMAGE-L0
III               III
Content-L1 (--) IMAGE-L1

Current connection:

ContentA-L0 ---- IMAGE-L0      ContentB-L0
III               III             III
ContentA-L1      IMAGE-L1 ---- ContentB-L1

I can't even grasp why such a thing could happen.

So my question: Should I check what the BE/FE actually interprets here (e.g. What image is associated with ContentA-L1,ContentB-L0,ContentB-L1) and thus generate a rule of how to fix it to add to dbdoctor.

Or is this rather so broken that I fix that manually and pretend it never happened.

[lolli42]

Ok. I guess we should fix this by looking at l10n_parent of tt_content, maybe.

However, pid of sys_file_reference records is not that important in the system. To resolve this loop for now, I'll exclude sys_file_reference in TcaTablesTranslatedLanguageParentDifferentPid. This will fix your issue, but will not fix the underlying problem which needs more analysis. I'll thus merge this quick-fix, but will leave this issue open to have a closer look together with a proper fix on this later again.

[lolli42]

Mitigation released with 0.5.0