don't know if its really a bug or just a miss configuration.
In table "cf_cache_pagesection" every expires timestamp is set to + 1 hour after
page generation. My config.cache_period = 86400 is ignored. So After one hour
the page cache is flushed.
In class t3lib_TStemplate function start near line 337
i changed if from:
$pageSectionCache->set( intval($GLOBALS['TSFE']->id) . '_' . $mpvarHash, $cc, array( 'pageId_' . intval($GLOBALS['TSFE']->id), 'mpvarHash_' . $mpvarHash )
$pageSectionCache->set( intval($GLOBALS['TSFE']->id) . '_' . $mpvarHash, $cc, array( 'pageId_' . intval($GLOBALS['TSFE']->id), 'mpvarHash_' . $mpvarHash ), //set timout else default 3600 is used $GLOBALS['TSFE']->get_cache_timeout()
then the expires date is correct.
[BUGFIX] Very short lifetime for cache_pagesection
The default lifetime for the cache_pagesection is not set, so the
overall default of 3600 is used. This leads to the information in there
being repeatedly generated, though it does seldom change (it only
consists of information in the rootline, TypoScript configuration,
conditions etc.). Therefore, the lifetime is increased by this patch
again to 30 days. The cache is cleared nonetheless when clearing "all
The default lifetime for this cache was unlimited prior to the
introduction of the caching framework.
Releases: 6.2, 6.1
Reviewed-by: Ingo Schmitt
Tested-by: Ingo Schmitt
Reviewed-by: Stefan Froemken
Tested-by: Stefan Froemken
Reviewed-by: Oliver Klee
Reviewed-by: Andreas Wolf
Tested-by: Andreas Wolf
#1 Updated by Arjen Hoekema about 8 years ago
Looks like the "cache_period" is only taken into account when setting the page cache. The "cache_pagesection" uses the defaultLifetime from the caching backend which is set to "3600".
For template cache stored in "cache_pagesection" I think the default lifetime should be set to "0" (unlimited) and not to the value of "cache_period". Caches are probably/mostly cleared using "Clear all cache" when modifications to the TS template are made by a backend user.
#2 Updated by Sven Tappert over 7 years ago
I created an extension that should fix the issue as you proposed it:
Since the issue still exists in 6.1.1 and probably above (#50231), the patch applies to all current branches from 4.5
If anyone has any suggestion or notices that the extension doesn't work properly, please let me know.
#3 Updated by Ernesto Baschny almost 7 years ago
- Status changed from New to Accepted
- Target version changed from 4.6.11 to 6.2.0
- Is Regression set to No
Good catch. It is true that config.cache_period only affects the page cache. This indeed makes sense, because this cache defines when a page rendering is repeated. The page cache is affected by "Cache Lifetime" in each page settings, then config.cache_period and config.cache_clearAtMidnight. Since 4.6 the page content is taken into account when calculating when the page cache expires (i.e. if you have a "starttime" element and it starts before the cache would expire, this lifetime is adapted accordingly). Great stuff (#20473).
This is all working well also in 6.x.
Now comes the "cache_pagesection". This contains the "configuration" of the pages (rootline, typoscript, conditions, etc). This is content-independant and usually should not expire so fast. In fact, in 4.5 it did not even expire at all (only when you hit "clear all caches").
Arjen interpreted it right:
This was not adapted when we introduced the caching framework for this (which was turned into the default in 4.6).
My suggestion would indeed be to rise this caching lifetime to something much higher than "1 hour" as it is today. Even "1 day" is too little in my understanding. The relevant caches are invalidated when something changes anyway. So we could cache this for a much higher lifetime (1 week or more) in my opinion and set this a new default.
I would not go for "unlimited" as this has caused some huge cache_pagesection-tables in the past. A decent default should suffice.