Bug #15769

NO/wrong language-merging for cType RECORDS - (so also not for Content in TemplaVoila)

Added by Franz Koch almost 14 years ago. Updated over 13 years ago.

Should have
Backend User Interface
Target version:
Start date:
Due date:
% Done:


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


I think I just found a bug with 'sys_language_mergeIfNotBlank' but I must say I'm a little confused currently of the way it is handled.

When fetching content with cType CONTENT, the query for selecting the content elements is built by a function 'tslib_content::getWhere' which (and only if $conf['languageField'] is expicit defined) switches the language-selection in the where-clause from the current sys_language to '0,-1' (default,all languages) which means that you get the content-element in the default language back and not the originaly asked one.

This element is later (in cType CONTENT) passed to another if-clause that merges the actual current sys_language over the given one, which HAS TO BE either 'default' or 'all languages' (therefore it had been switched before).

Isn't that double-reverse-thing a little unhandy?

Well, I think it is, as in this way it is impossible to get language-merged content-elements that are not passed through the CONTENT cType, which would be for example cType RECORDS. Because cType RECORDS can have direct references to translated content-elements which aren't fetched over the before mentioned function 'tslib_content::getWhere' which reverses the language.

So you will most likely not get language-merged content-elements over the function call 't3lib_page::getRecordOverlay' in cType RECORDS which leads to a big problem with all TemplaVoila sites, that fecht almost every content over cType RECORDS.

I stumbled over this as I coulnd't get 'sys_language_mergeIfNotBlank' work in TemplaVoila but it has worked with common rendering (page.30 < styles.content.get).

I'm no core developer, so I don't know what the actual idea was behind this double-language-conversion whatever thing, but I think it would be much wiser to remove this language conversion stuff and handle the overlay in one central function, which would be 't3lib_page::getRecordOverlay'.

The second thing is:
Currently the 'language conversion' in 'tslib_content::getWhere' is ONLY done when the given $conf-Array contains a field called 'languageField'. As I don't think that every developer is aware of this wouldn't it be better to simply check the TCA for the definition of that field (as it is done one line after: 6586, class.tslib_content.php) and optional check an override of the variable 'languageField'?

Here are my changes to my local system that made it work as it is supposed to be. I testet it with workspaces, versioning and language content-fallback. Everything seems to be ok, but it would be good if more people with different setups could test it before implementing in core.

----- class.tslib_content.php around line 6584 ------------
  1. from:
    if ($conf['languageField']) {
    if ($GLOBALS['TSFE']->sys_language_contentOL && $TCA[$table] && $TCA[$table]['ctrl']['languageField'] && $TCA[$table]['ctrl']['transOrigPointerField']) {
    // Sys language content is set to zero/-1 - and it is expected that whatever routine processes the output will OVERLAY the records with localized versions!
    $sys_language_content = '0,-1';
    } else {
    $sys_language_content = intval($GLOBALS['TSFE']->sys_language_content);
    $query.=' AND '.$conf['languageField'].' IN ('.$sys_language_content.')';
  1. to:
    if($TCA[$table] && ($TCA[$table]['ctrl']['languageField'] || $conf['languageField'])) {
    $lField = $conf['languageField']? $conf['languageField'] : $TCA[$table]['ctrl']['languageField'];
    $query.=' AND '.$lField.' IN ('.$GLOBALS['TSFE']->sys_language_content.')';
    maybe a additional check should be added if the defined 'languageField' in $conf really exists in $TCA[$table]['columns'].
----- class.t3lib_page.php line 324 -----------------------
  1. from: if ($row[$TCA[$table]['ctrl']['languageField']]<=0) {
  2. to: if ($row[$TCA[$table]['ctrl']['languageField']] > 0) {
----- class.t3lib_page.php around line 330-----------------
  1. from:
    ' AND '.$TCA[$table]['ctrl']['languageField'].'='.intval($sys_language_content).
    ' AND '.$TCA[$table]['ctrl']['transOrigPointerField'].'='.intval($row['uid']).
  1. to:
    ' AND '.$TCA[$table]['ctrl']['languageField'].' IN (0,-1)'.
    ' AND uid='.intval($row['l18n_parent']).
----- class.t3lib_page.php around line 345-----------------
  1. from:
    if ($fN!='uid' && $fN!='pid' && isset($olrow[$fN])) {
    if ($GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]!='exclude'
    && ($GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]!='mergeIfNotBlank' || strcmp(trim($olrow[$fN]),''))) {
    $row[$fN] = $olrow[$fN];
  1. to:
    if ($fN!='uid' && $fN!='pid' && isset($row[$fN])) {
    if (($GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]=='exclude' || $GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]=='mergeIfNotBlank') && !strcmp(trim($row[$fN]),'')) {
    $row[$fN] = $olrow[$fN];

I'll provide diff-files as soon as I know how to create them correct.
(issue imported from #M2773)

patch_class.t3lib_page.php.diff View (1.89 KB) Administrator Admin, 2006-03-14 09:13

patch_class.tslib_content.php.diff View (1.32 KB) Administrator Admin, 2006-03-14 09:13


#1 Updated by Franz Koch almost 14 years ago

I just added the promised patches. As they are my first diff-files I hope everything is correct with them. I used a fresh RC1-installation for generating the patch.

I also added a check if the given 'language_field' is set in the TCA in file 'class.tslib_content.php'. Therefore I had to load the TCA for the specified table. If you think that this might be slowing down rendering - just remove it.
Or if you think that the TCA-check is limiting the flexibility somehow, drop the 2 lines.

#2 Updated by Kasper Skaarhoj almost 14 years ago

I cannot allow these changes since they seem to be based on a misunderstanding of how localization works, sorry. If they are merely an improvement and doesn't fix a bug I see no reason for them.
I'm willing to look at the case which is a problem for you. Either we find that you misunderstood something or we find that the system has a bug and we can find a solution.

Generally, my finding has been that the localization features of TYPO3 work flawlessly. I made them originally and I was not sloopy. Localization in TYPO3 is very complex in the options and it is more likely that a misunderstanding has happened.

So, if you can describe a test-scenario or send a T3D file (or best: give login to a site) which fails, let me know one of these days.

#3 Updated by Kasper Skaarhoj almost 14 years ago

see notes

Also available in: Atom PDF