If you use Extbase with sys_language_mode=strict
it automatically creates a query similar to this:
SELECT * FROM tx_news_domain_model_news
WHERE tx_news_domain_model_news.title LIKE '%house%'
AND (
-- language set to all languages
tx_news_domain_model_news.sys_language_uid = -1
-- all translated records but without a language parent
OR (
tx_news_domain_model_news.sys_language_uid = 1 AND tx_news_domain_model_news.l10n_parent = 0
-- records in the default language that have translations
) OR (
tx_news_domain_model_news.sys_language_uid = 0 AND tx_news_domain_model_news.uid IN(
SELECT tx_news_domain_model_news.l10n_parent
FROM tx_news_domain_model_news
WHERE tx_news_domain_model_news.l10n_parent > 0 AND tx_news_domain_model_news.sys_language_uid = 1 AND tx_news_domain_model_news.deleted = 0
)
)
)
That makes it impossible to search e.g. for a title of a properly translated news record because you either search records that have
their language set to all, that have no language parent or are in the default language. It is quite difficult to support all the options
that come with l10n_mode
that is why this issue is still not resolved. For further information see https://forge.typo3.org/issues/77298
and Typo3DbQueryParser::getSysLanguageStatement
.
The following fix extends the class Typo3DbQueryParser
, takes the initial where clause (tx_news_domain_model_news.title LIKE '%house%'
in the example) and
moves it into a subquery where it looks for the conditions in a translated record and returns the uids of the records in the default language.
That allows for a proper language overlay to take place afterwards.
It does not solve all your problems that come with Extbase and localization. This fix only works in sys_language_mode=strict
when you want to search fields that
are explicitly set on the translated record. It does not work when you search fields that rely on l10n_mode
settings, e.g. if you only set a category relation in the default language.
I have also not tested it with multiple tables, e.g. in join queries, that is why the fix is not applied in such cases.
You should activate this fix only for classes of which you know that these preconditions are met.
- Copy the code from the files to the corresponding files in your template or extension
- Adjust the namespaces to match your needs
- Add the class names that should use this fix to the array
$queryTypesToFix