Bug #70948


repository doesn't handle l10n_mode "exclude" in some case

Added by Florian Bachmann over 8 years ago. Updated almost 8 years ago.

Must have
Database API (Doctrine DBAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


I have a custom recordtype (reference) which needs to be linked to a couple of pages. That link should not be changed in a translation overlay. So l10n_mode is exclude.
So I created the following TCA-Definition for that field "pages_list"

»···'pages_list' => array(
»···»···'exclude' => 1,
»···»···'label' => 'List of associated pages',
»···»···'config' => array(
»···»···»···'type' => 'select',
»···»···»···'foreign_table' => 'pages',
»···»···»···'size' => '8',
»···»···»···'maxitems' => 100,
»···»···»···'autoSizeMax' => 10,
»···»···»···'renderMode' => 'tree',
»···»···»···'treeConfig' => array(
»···»···»···»···'parentField' => 'pid',
»···»···»···»···'appearance' => array(
»···»···»···»···»···'expandAll' => TRUE,
»···»···»···»···»···'showHeader' => TRUE,
»···»···»···»···»···'maxLevels' => 99,
»···»···'l10n_mode' => 'exclude',
»···»···'l10n_display' => 'defaultAsReadOnly',

In The ReferenceRepository I need to select all References assigned to a page.

»···public function findByPage($pageId) {
»···»···$references = NULL;
»···»···$query = $this->createQuery();

»···»···$constraint = $query->contains('pagesList', $pageId);
»···»···$references = $query->execute();
»···»···return $references;


The resulting sql-query doesn't seem to respect the l10n_mode, since it requires the translated record (sys_language_uid > 0) to be assigned to that page (in this case 44), which would make sense, if that field would be translatable.

SELECT  tx_vender_domain_model_reference.* FROM tx_vender_domain_model_reference··
»···WHERE FIND_IN_SET('44', tx_vender_domain_model_reference.pages_list)·
»···»···AND (
»···»···»···tx_vender_domain_model_reference.sys_language_uid IN (2,-1)·
»···»···»···OR (
»···»···»···»···AND tx_vender_domain_model_reference.uid NOT IN (
»···»···»···»···»···SELECT tx_vender_domain_model_reference.l10n_parent FROM tx_vender_domain_model_reference·
»···»···»···»···»···WHERE tx_vender_domain_model_reference.l10n_parent>0
»···»···»···»···»···AND tx_vender_domain_model_reference.sys_language_uid=2·
»···»···»···»···»···AND tx_vender_domain_model_reference.deleted=0

So this query returns all non-translated records which are assigned to that page (no translation overlay existing), and translated record-overlay rows which are assigned to that page (44) - which is not possible, and will always result in an empty set

For better readability I removed the usual hidden=0, deleted=0.
If anyone asks - TCE-Forms do work perfect.

Related issues 1 (0 open1 closed)

Is duplicate of TYPO3 Core - Bug #62921: l10n_mode with relations does not work in ExtbaseClosed2014-11-13

Actions #1

Updated by Christian Kuhn over 8 years ago

  • Description updated (diff)
Actions #2

Updated by Martin R. Krause over 8 years ago


This is old but still the case in TYPO3 7.6 LTS!

The scenario and the bugs

  • You have a filed with l10n_mode == exclude
  • You create a record and set a value to that field
  • You localize this record to language_uid 1. The field is copied but not shown in the BE form because of "exclude"
  • You edit the default record and change the field, the field in the translated record is not updated by that (first bug!)
  • An extbase query with content_language = 1 does query for the field from the translated record (secong bug!)
  • RecordOverlay on the on the other hand does handle the overlay in the correct way. (Inconsistency, third bug!)

In the end, these field cannot be edited once a translation has been created.

Possible workaround

  • Do not use l10n_mode exclude, have all field editable in all languages (lame)
  • Do not use Extbase

Possibile solution

There is no simple solution. I would recommend to utilize SQL much more language overlays. It is possible to compose SQL statements that handle record selection and field overlay in one query. This way it would be faster and consistent.

Actions #3

Updated by Markus Klein almost 8 years ago

  • Status changed from New to Closed

Closing as duplicate of #62921


Also available in: Atom PDF