Actions

Copy link

Bug #98079

open

No localized records will be rendered in custom record link handlers

Added by Marcel Marty over 2 years ago. Updated 8 months ago.

Status:

New

Priority:

Should have

Assignee:

Category:

Site Handling, Site Sets & Routing

Target version:

next-patchlevel

Start date:

2022-08-05

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Since TYPO3 11.5.5, no localized records in custom record link handlers are displayed.

Steps to reproduce:¶

Create a TYPO3 installation with 2 languages (in my case default is DE and the other language is FR)
Create a basic extension which is creating records
Create a record and localize this record to FR.
Create a custom link handler as described in the official documentation at https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/LinkBrowser/Linkhandler/Index.html
Create a content element in the default language with an RTE field and some text
Localize the content element from 2)
Link to a specified record by the previously generated custom record link handler in the default language
Link to the localized version of a specified record in the localized content element from 3)

Conclusion:¶

The link in the default language will appear in the frontent, the link in the localized content element will not.

Suggestion:¶

The problem will be caused because of an incomplete condition in typo3/sysext/frontend/Classes/Typolink/DatabaseRecordLinkBuilder.php file (line 66-68, change for #87260).

In my opinion the condition should be:

if (empty($overlay['_LOCALIZED_UID']) && empty($overlay['l10n_parent'])) {
   $record = 0;
}

instead of

if (empty($overlay['_LOCALIZED_UID'])) {
   $record = 0;
}

because the property _LOCALIZED_UID is not available in Extbase records (I have just l10n_parent there).

Related issues 3 (1 open — 2 closed)

Actions

Copy link

Updated by Marcel Marty over 2 years ago

Blocked by Bug #87260: Untranslated records should not be linked added

Actions

Copy link

Updated by Marcel Marty over 2 years ago

Target version set to next-patchlevel

Actions

Copy link

Updated by Frank Gerards over 2 years ago

as stated in the other bugticket https://forge.typo3.org/issues/87260:

Situation: Language EN-US falls back to EN-GB, Default Language 0 is DE-DE.
Page exists in DE-DE and EN-GB (free mode), but not in EN-US:

Now you call the page in EN-US, which completely falls back to EN-GB:

If you have "Jump" Contentelements, which link to other content-elements (not page links, which work fine) on the same or other pages, then NO links (as $record = 0 is returned) will be created. This breaks the fallback chain and language handling of bigger sites totally. No content fallback to languages other than default can be done.

Your fix doesnt solve the problem. I am talking about a frontend request to a site language, which has a fallback language OTHER than language 0 (default). In this situation, the LinkHandler returns $row = 0.

The tt_content record which is running through the handler is the one of the fallback language (!), which ofc has no l10n_parent and no _LOCALIZED_UID as it is the fallback record. This mis-understanding of language fallback kicked in with the introduction of the Site module and its placemnet in the core-logic. In former TYPO3 versions, multi-stage language fallbacks could be done with the CORE or additionally with TemplaVoila and with a slight patch even in extbase.

The site module and new routing is pretty broken, if you move out of basic language handling. It also can't handle mixed mode of page translations for extbase plugins accordingly.

I would suggest to abandon the "fix" in https://forge.typo3.org/issues/87260 completely.

Actions

Copy link

Updated by Frank Gerards over 2 years ago

My proposal für a fix would be:

    if (
        empty($overlay['_LOCALIZED_UID'])
        && empty($overlay['l10n_parent'])
        && !in_array($record['sys_language_uid'],$languageAspect->getFallbackChain())
       ) {
            $record = 0;
      }