Bug #93578
opengetPagesOverlay in Page Repository ignores language specific fallback
0%
Description
getPagesOverlay calls the function to get the language fallback chain with null as argument.
This will than return the current fallback chain, and not the appropriate for that language.
https://github.com/TYPO3/TYPO3.CMS/blob/298c3d4c400702c893bbe58503635cd2d905e340/typo3/sysext/frontend/Classes/Page/PageRepository.php#L562
An example to test this behavior is creating a language menu, the resulting available status is different depending on the current language.
Language | Fallback | Page is translated | Expected status | From default | From de-ch |
---|---|---|---|---|---|
default | Y | Y | Y | Y | |
de | Y | Y | Y | Y | |
de-ch | de | X | Y | X | Y |
en | X | X | X | Y |
Getting the fallback chain from the site entity in the request for that language fixes the issue.
But it depends on the request being correct, so fetching a page from another page tree would result in a wrong configuration.
Updated by Hannes Lau about 1 year ago
I can confirm the issue and I would like to submit a patch. Instead of getting the fallback chain from the current page and current language, we need to get the fallback chain from the requested page and requested overlay language.
Something along the lines of:
// PageRepository::getPagesOverlay
// …
$overlays = [];
// If language UID is different from zero, do overlay:
if ($languageUid) {
$siteFinder = GeneralUtility::makeInstance(SiteFinder::class);
foreach ($pagesInput as $origPage) {
$pageUid = is_array($origPage) ? (int)($origPage['uid'] ?? 0) : (int)$origPage;
$site = $siteFinder->getSiteByPageId($pageUid);
$siteLanguage = $site->getLanguageById($languageUid);
$languageAspect = LanguageAspectFactory::createFromSiteLanguage($siteLanguage);
$languageUids = array_merge([$languageUid], $this->getLanguageFallbackChain($languageAspect));
$additionalOverlays = $this->getPageOverlaysForLanguageUids([$pageUid], $languageUids);
$overlays = array_merge($overlays, $additionalOverlays);
}
}
There are two issues with this approach:
- Unfortunately, the call to `$site->getLanguageById($languageUid)` leads to an endless loop via the RootlineUtility.
- There might be a negative performance impact, as the pages do not get overlaid as bulk, but page by page. It might be more efficient to group the overlay queries by site and target language.
Updated by Hannes Lau about 1 year ago
I just realized that this may already have been dealt with in https://forge.typo3.org/issues/98303.
Updated by Benni Mack about 1 year ago
- Related to Task #98303: Use PSR-14 Events in PageRepository for getLanguageOverlay functionality added
Updated by Benni Mack about 1 year ago
@hannes: Supercurious to see if you have a solution for this problem in v11 (or even 12).
Updated by Benni Mack 8 months ago
Adding this here for future investigation: https://extensions.typo3.org/extension/mst_contentfallback
Updated by Benni Mack 7 days ago
- Status changed from New to Needs Feedback
I added the multi-step fallback inside getLanguageOverlay() in PageRepository in v12. Can somebody verify if this problem is now solved for their use-cases?