Breaking: #23736 - Page Language detection set earlier in Frontend Request Process

See Issue #23736

Description

TYPO3’s Frontend Request Process previously needed a parsed TypoScript before doing the language overlay of the currently visited page, as previous TYPO3 sites without Site Handling used TypoScript conditions like [globalVar = GP:L = 1] to switch between languages.

This made it impossible to use conditions for accessing the translated page record like [page["nav_title"] == "Bienvenue"], which was a long outstanding conceptual issue that was finally made possible through Site Handling.

For this reason, the translated page is now resolved directly after the actual page and rootline resolving.

Impact

The translated page record (based on the fallback handling in the Site Configuration) is now available in $TSFE->page at a much earlier stage of the Frontend process.

This means, TypoScript conditions based on the page record (see example above) might be different.

In addition, the two hooks $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_preProcess'] and $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['settingLanguage_postProcess'] are called now earlier when no TypoScript is available yet.

Affected Installations

TYPO3 installations with custom extensions using the hooks mentioned above or that have language-specific “page-based” conditions.

Migration

Review the hooks or use a PSR-15 middleware to use the same place to extend TYPO3’s Frontend Request process after TypoScript was initialized.

Also, be sure to review any of the TypoScript conditions (possible via the Web->Template module) if they are related to values only available in the default language, which seems to be a very case however.