Feature #53885
closed
Epic #65815: Improve Indexed search indexer
sys_language_uid vs. sys_language_content
Added by Jonathan Krusy about 11 years ago.
Updated 2 months ago.
Description
Indexed Search only indexes pages when sys_language_uid and sys_language_content have the same value.
In some cases, indexed search won't index pages.
For example:
We have three different root-pages (root-A, root-B, root-C) with different sys_language_uids.
All of them have one page, displaying the content from another page-root (root-D) with a completly different sys_language_uid (in this case: default 0)
With sys_language_mode = content_fallback, the pages from A, B and C will display the content from D, but sys_language_content would be 0.
Therefore the pages from A, B and C won't be indexed due to the line
if (!strcmp($pObj->sys_language_uid, $pObj->sys_language_content)) {
in the Indexer Class.
Is there a possibility to add an extra configuration to skip this test?
I can't tell you why this condition is checked, but I can tell you that there's no option to skip it, sorry.
Maybe send an email to one of the mailing lists, to ask if somebody knows, why this check is in place.
- Target version set to 7.5
- Parent task set to #65815
- Target version changed from 7.5 to 8 LTS
- Target version changed from 8 LTS to 9.0
- Target version deleted (
9.0)
The code reported has been changed a couple of years ago with
/** @var LanguageAspect $languageAspect */
$languageAspect = GeneralUtility::makeInstance(Context::class)->getAspect('language');
if ($languageAspect->getId() === $languageAspect->getContentId()) {
But as far as I have understood this kind of check is still present (I could be wrong); this check seems to avoid the indexing of fallback content as localized content - when the check fails the code continues on:
$this->log_setTSlogMessage('Index page? No, languageId was different from contentId which indicates that the page contains fall-back content and that would be falsely indexed as localized content.');
(see EXT:indexed_search/Classes/Indexer.php)
- Status changed from New to Rejected
Hey,
I am closing this issue. For the following reasons:
- Since TYPO3 v9 we have Site Configuration, which streamlines this area of languageId and contentId much better.
- Since TYPO3 v12 the affected code is in an Event Listener of a PSR-14 event, which can be replaced by something else instead of FrontendGenerationPageIndexingTrigger
- The reason this check is there, is described in the log message directly below (because of complex fallback scenarios). Your scenario is very very custom.
The code in Core is thus correct, and I suggest you use the PSR-14 event to build your own custom replacement part.
I hope this is OK for you.
All the best,
Benni.
Also available in: Atom
PDF