TYPO3 Core

The basic challenge with the extension I received can be expressed as a "It's your turn" dilemma, when nested entities additionally point to each other with misleading semantic.

Written in an abstract way, we have the following TCA:

parent
  columns
    children
      l10n_mode=exclude
      config
        type=inline
        foreign_table=child
        foreign_field=parentid
child
  columns
    parentid
      l10n_mode=exclude
      config
        type=select
        foreign_table=parent

Since the following behavior has been integrated into TYPO3 8.6, l10n_mode "exclude" and "mergeIfNotBlank" are handled differently and the values of the ancestor language source (e.g. "default language") are copied(!) to according translations. Find further details of that change here: https://docs.typo3.org/typo3cms/extensions/core/8-dev/Changelog/8.6/Feature-51291-SynchronizedFieldValuesInLocalizedRecords.html

Lets assume we have the following entities and record ids:

• parent:1 - default language
  • child:11 - default language
    • child:11.parentid is 1
  • child:12 - default language
    • child:12.parentid is 1
• parent:2 - translation of parent:1

Now, let's have a look on what happens, when the default language version of the parent entity is modified:

• all children of parent:1 are copied/synchronized to parent:2 by creating localizations if they don't exist yet
  • localized parent:11 to parent:21
  • localized parent:12 to parent:22
• the field values of child.parentid of the default language are copied to the their dependent translation records
  • child:11.parentId is copied to child:21.parentid, value is 1
  • child:12.parentId is copied to child:22.parentid, value is 1
  • now both translated children point back to the parent record of the default language - that's the mentioned misbehavior

How to solve this:

• reconsider all l10n_mode=exclude and l10n_mode=mergeIfNotBlank (later will be migrated automatically to allowLanguageSynchronization=true
• replace l10n_mode=exclude settings from child references, used in back-selectors to ancestor by displayCond - these are the child.parentid fields from the example above

child
  columns
    parentid
      displayCond=FIELD:sys_language_uid:<=:0
      config
        type=select
        foreign_table=parent

There was a similiar issue in powermail when upgrading to TYPO3 CMS 8, see the commit and initial pull-request for details:

• https://github.com/einpraegsam/powermail/commit/01b2fd4884b1dd9cefd1b7ae1dc501d338b46dd5
• https://github.com/einpraegsam/powermail/pull/56

The only thing the Core could do here would be:

• walk down the path of possible nested child references
• determine back-pointers that would be overridden
• throw an exception with more explanation
• this mechanism would have to consider all possible relations of the whole system