Bug #96309
closedflushCachesByTags doesn't clear correctly the page cache
0%
Description
Our Typo3 instance hosts thousands of websites, which is why we can not afford to clear the whole cache every time a website admin will change a value in the TS constants of its website, like the name of this website for example.
For this reason, we implemented a custom CacheManager that does more or less the same thing that the CacheService from extbase.
When asked to flush the cache of a website, our cache manager get the root uid of the website, then recursively list all of the website's pages, and build an array of the form:
['pageId_1', 'pageId_2', ...]
It finally call the TYPO3\CMS\Core\Cache\CacheManager like this:
$cacheManager->flushCachesByTags($tags);
But this command alone wasn't enough to force the page to rerender.
After hours of investigations, I found out adding these lines did the job, even if I'm unable to understand why:
$connectionPool = GeneralUtility::makeInstance(ConnectionPool::class);
$cnn = $connectionPool->getConnectionByName('Default');
$cnn->beginTransaction();
$sql = "update typo3.cache_hash h inner join typo3.cache_hash_tags t on h.id = t.id
set h.expires = 0
where t.tag = 'ident_TS_TEMPLATE';";
$stmt = $cnn->prepare($sql);
$stmt->executeQuery();
$cnn->commit();
We are using Typo3 10.4.21 with php 7.2
The pages are designed with fluid
We're using custom viewhelpers and VHS (6.0.5) viewhelpers on these pages
We're using flux (9.5.0)
Updated by Christian Kuhn about 2 years ago
- Status changed from New to Closed
Hey. Thanks for your report.
I fear there is not much the core can do here: Entries with "ident_TS_TEMPLATE" tags are created by TemplateService. This class has been deprecated in v12, we won't change cache handling in v11 anymore (except if a blocker issue pops up) and the entire TypoScript handling got a major overhaul.
I'm unsure if flux or vhs fiddle here, too.
This kinda looks like an istance specific issue. I hope it's ok to close here for now.