TYPO3 Core

Manfred Egger wrote:

I would expect that as soon as a page is cached it's cached content is served to all clients. But if you have a multi language site and any client changes to a different language, the cached version isn't served anymore.

I've tested this with TYPO3 10.4 and it is working as expected: even if I switch between languages, the cached content is served. So it seems it's a problem introduced with TYPO3 11.

We observed the exact same behavior. The cache on a large multi-language site with 30 languages is constantly cleared because every request one language deletes the cache for all other languages.

Our test case, with curl and time to track the time the request takes (everthing larger than 200ms is not cached):

# first request, all caches are cleared. cache is being built.

time curl -I https://example.de 

HTTP/2 200 
content-language: de
expires: Tue, 13 Sep 2022 22:00:00 GMT
cache-control: max-age=23784
pragma: public
x-typo3-parsetime: 0ms
etag: "f8b6bfb4b4e88b138b72eea81bfb3a99" 
x-content-type-options: nosniff
x-ua-compatible: IE=edge
content-type: text/html; charset=utf-8
date: Tue, 13 Sep 2022 15:23:36 GMT
server: Apache

0,00s user 0,00s system 0% cpu 2,312 total

# second request, same language, cached result is used.

time curl -I https://example.de 

HTTP/2 200 
content-language: de
x-typo3-debug-cache: Cached page generated 13-09-22 17:26. Expires 14-09-22 00:00
expires: Tue, 13 Sep 2022 22:00:00 GMT
cache-control: max-age=23630
pragma: public
x-typo3-parsetime: 0ms
etag: "f8b6bfb4b4e88b138b72eea81bfb3a99" 
x-content-type-options: nosniff
x-ua-compatible: IE=edge
content-type: text/html; charset=utf-8
date: Tue, 13 Sep 2022 15:26:10 GMT
server: Apache

0,00s user 0,00s system 0% cpu 0,125 total

# third request, DIFFERENT language, cache is built.

time curl -I https://example.com

HTTP/2 200 
content-language: hr
expires: Tue, 13 Sep 2022 22:00:00 GMT
cache-control: max-age=23550
pragma: public
x-typo3-parsetime: 0ms
etag: "ceefa8cb5dc836b370c8e9212e580573" 
x-content-type-options: nosniff
x-ua-compatible: IE=edge
content-type: text/html; charset=utf-8
date: Tue, 13 Sep 2022 15:27:30 GMT
server: Apache

0,00s user 0,00s system 0% cpu 1,242 total

# fourth request, back to first language, cache is NOT used.

time curl -I https://example.de

HTTP/2 200 
content-language: de
expires: Tue, 13 Sep 2022 22:00:00 GMT
cache-control: max-age=23119
pragma: public
x-typo3-parsetime: 0ms
etag: "f8b6bfb4b4e88b138b72eea81bfb3a99" 
x-content-type-options: nosniff
x-ua-compatible: IE=edge
content-type: text/html; charset=utf-8
date: Tue, 13 Sep 2022 15:34:41 GMT
server: Apache

0,00s user 0,00s system 0% cpu 1,132 total

This is reproducible on two independent Typo3 11.5 instances.

This StackOverflow seems to have has the same problem:
https://stackoverflow.com/questions/72444255/typo3-11-5-clears-cache-after-user-navigates-to-other-language

One observation:

Using `TypoScriptFrontendController->createHashBase()` with a forced argument of true (`createHashBase(true)`) will NOT add the "all" parameters to the hash function (hash parameters) and fixes the caching issue.

We are not sure of this has any side effects, but for the time being we could not observe any.

We recently updated a customer project to TYPO3 V11 and also ran across the issue. This is a major problem and real performance killer for multi language installations.
We tested different configurations, language versions with different domains vs. one domain and language prefix, but to no avail.

Following Reiner Kempkes example, we used the "createHashBase" hook, but instead of unsetting the whole $_params['hashParameters']['all'], assigning an empty array to the sub entry "rootline" also does the trick ($params['hashParameters']['all']['rootLine'] = []). Stefan Bürks observation seems to be correct, there is something weird going on with the rootlines.

For now we will use this "quickfix" to keep the project working, but hopefully there will be a real fix coming soon.

Still no solution, but after additionally couple of hours of debuging,
comparing and reviewing git history ... it seems that this is tightly
related to a bugfix, which moved loading the language based rootline
before TypoScript parsing to allow language based matchings. Thus the
already detected jumping behaviour with the rootlines in the pagesection
cache now can verified.

I reverted that change locally, and it worked like in 10. Will try to
find a solution than in the next days.

Related issue #23736
Related patch: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65044

Patch set 11 for branch 11.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/76302

Maybe some of the people which having that issue can verify/test the bugfix (as composer patch or similiar). Would be nice to have some verifications here.

Hi Stefan,

I also encountered a caching issue, however this was in V10. What happened in my situation was te following.

In constants.typoscript i had the following:

1. Tracking is disabled by default (constants)

forms.microsoftDynamics.tracking =

2. For a specific language i enable the tracking (constants)

[siteLanguage("languageId") == 1]
forms.microsoftDynamics.tracking = 1
[global]

3. I load in tracking scripts with the following (typoscript)

[{$forms.microsoftDynamics.scriptsEnabled} == '1']
 page.headerData.850187 { 
 ... scripts ...
}
[global]

• In TypoScriptFrontendController.php the `$this->getHash()` is called twice.
• However when called in the function generatePage_preProcessing() the $hashParameters['all'] do not seem to have the constants loaded from languageUid 1
• This causes a different MD5 hash compared to the `$this->getHash()` called in function `getFromCache()`
• Which then causes the regeneration of cache on all other languages when the page is called.

Your script helped me alot with debugging.

I'm not sure how related these issues are.

• TYPO3 V11 - with your fix
• TYPO3 V11 - without your fix
• TYPO3 V12

This however might also be another specific bug in V10/V11

@Joey Bouten @Joey Bouten

I would say, you describe another thing. I would say, that that's more related to the issue which has been fixed in v11, and is the source of the problem in this issue.

In v10 the language loading has been processed later. Rootline in PageSection cache is there always the default language rootline. Condition are matched later. Thus see related issue #23736 Condition with globalVar TSFE does not care about page language overlay.

We may can have a talk/call if you contact me on slack ...

Stefan Bürk wrote in #note-15:

Maybe some of the people which having that issue can verify/test the bugfix (as composer patch or similiar). Would be nice to have some verifications here.

Tested, the patch works for us.

@Meelis Karulin May it be possible that you can vote at least plus 1 verified on the patch itself ? -> https://review.typo3.org/c/Packages/TYPO3.CMS/+/76302