Bug #93578
closed
getPagesOverlay in Page Repository ignores language specific fallback
Added by David Hedden over 3 years ago.
Updated 11 months ago.
Category:
Site Handling, Site Sets & Routing
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.
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.
- Sprint Focus set to On Location Sprint
- Related to Task #98303: Use PSR-14 Events in PageRepository for getLanguageOverlay functionality added
@hannes: Supercurious to see if you have a solution for this problem in v11 (or even 12).
- Sprint Focus deleted (
On Location Sprint)
- 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?
Benni Mack wrote in #note-8:
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?
The example i stated in the issue is solved, verified it in 12.4.10-dev.
- Status changed from Needs Feedback to Closed
Thanks for the info, I will close this ticket then!
Also available in: Atom
PDF