Bug #91453
openPersistedAliasMapper not finding record, if non-translated
0%
Description
- Have a page-setup with two languages.
- Setup News-Extension for e.g. List view and Detail view on different pages.
- Those pages are all translated.
- Pages are language-strict, no language-fallbacks for page content is needed. Content is copied or re-created in the translated language.
- News-Records usually only exist in the root language (UID 0), they are never or only rarely translated. However, News of the root-language should still all be displayed on the translated pages as fallbacks as well. Therefore the NewsRepository is hooked and adjusted, so that languageFallbacks are applied. Query is adjusted in the NewsRepositoryHook:
$query->getQuerySettings()->setLanguageOverlayMode(true); $query->getQuerySettings()->setLanguageMode('content_fallback');
This worked perfectly until TYPO3 v9.5.15. v9.5.14 still worked. Problem is a change in the PersistedAliasMapper and its findByRouteFieldValue-method.
PersistedAliasMapper @ v9.5.14:
$queryBuilder = $this->createQueryBuilder(); $result = $queryBuilder ->select(...$this->persistenceFieldNames) ->where($queryBuilder->expr()->eq( $this->routeFieldName, $queryBuilder->createNamedParameter($value, \PDO::PARAM_STR) )) ->execute() ->fetch(); return $result !== false ? $result : null;
PersistedAliasMapper @ v9.5.15:
$languageAware = $this->languageFieldName !== null && $this->languageParentFieldName !== null; $queryBuilder = $this->createQueryBuilder(); $constraints = [ $queryBuilder->expr()->eq( $this->routeFieldName, $queryBuilder->createNamedParameter($value, \PDO::PARAM_STR) ), ]; $languageIds = null; if ($languageAware) { $languageIds = $this->resolveAllRelevantLanguageIds(); $constraints[] = $queryBuilder->expr()->in( $this->languageFieldName, $queryBuilder->createNamedParameter($languageIds, Connection::PARAM_INT_ARRAY) ); } $results = $queryBuilder ->select(...$this->persistenceFieldNames) ->where(...$constraints) ->execute() ->fetchAll(); // return first result record in case table is not language aware if (!$languageAware) { return $results[0] ?? null; } // post-process language fallbacks return $this->resolveLanguageFallback($results, $this->languageFieldName, $languageIds);
The problem is easily found: In the new method, an extra constraint for sys_language_uid for the current FE-language is applied, although the News of the resolved News-Slug is not translated. This leads to the News not being found by the RouteEnhancer.
A simple check if l10n_parent and sys_language_uid are present in the record's TCA are not enough. Complete language configuration including fallbacks need to be kept in mind here.
Updated by Ralph Brugger over 4 years ago
Same problem here. Records won't be found resulting in an error 404.
Rolled back to the old findByRouteFieldValue method.
Updated by Oliver Hader over 4 years ago
- Related to Bug #89153: Wrong Extbase record is shown for slug added