TYPO3 Core

This text was a response to #60045 / #60046 in the first place.

Scenario: An instance under load with lots of TS records that are changed on live directly. While this is often an unwanted scenario, it still may happen for "microsites" instances - lots of sites with small page trees. The clearCacheCmd('all') fired by the TypoScript module is then disadvantegous, since it kills way too many cache entries where only entries of the page with the TS record and all its children should be cleared.

The solution to just disable the page clear however is not sufficient, since caches of subpages are not cleared, so the proposed solution is only useful if pages with a changed TS record have no sub pages.

More general approach: Tag a fe cache entry with its rootline. So if a cache entry belongs to page 42 which is a child of page 23 and that is a child of page 5, then page 42 cache entry would be tagged with "isChildOf_23" and "isChildOf_5" (or similar). The change the TS module to not fire clearCacheCmd('all'), but clearCacheCmd('cacheTag:isChildOf_5') if TS record of page 5 is changed. clearCacheCmd can do that already. Cache entry for page 23 and 42 would be cleared then. Also flush by tag "PageId_5". If done, exactly the correct cache entries would be killed and nothing more.
It may only happen that if you "flushByTag" a page that alredy has lots of sub pages takes quite some time, so in this case it may be quicker to just "flush whole cache" - this does a truncate on Typo3DbBackend cache and an rm -r on file caches and is much quicker than a lengthy "delete nearly everything". So, we'd probably need PageTS that controls the flush behaviour (with default to flushByTag).

Tagging caches in the frontend with its "rootline" could be beneficial for other things as well, maybe for the list/page module for example: Eg. storing a record on a storage page X then triggers a "clear caches of page Y and Z and all their sub pages, which is currently also not possible.

Todo:
Find out if the above solution is sane and do-able.
Add functionality to add "rootline" tags to cache_pages in the frontend.
Find out usage of pagesection and see if this one can be tagged as well or if the cache entries are re-used on different pages again - which may torpedo the above idea.
Find a sane pageTS syntax to feed clearCacheCmd with options like 'kill everthing below "me"' and implement it.
I'm not 100% sure if the above will survive all checks, but it sounds like a good idea to me. Better tagging in the frontend is long overdue anyway and it may help us at other places as well. I've raised some attention towards this issue to some active contributors already (eg. Markus Klein and Helmut Hummel), we think that this issue could probably be solved this way, but at the moment no one is really digging deep into that and actually working on it - this is one reason why an answer took longer, I'm really sorry for that.

Alexander, what do you think, is this a good idea and are you feeling you could dive into this overall topic and search for progress here? I would happily help with providing more information, ideas and technical insights that I have on my radar - eg. I know the caching framework pretty well, but I don't know the FE details on my own without digging myself.

I know that the proposed solution is much more complex than just disabling the clear cache action, but I really think this would go into the right direction. My gut feeling is this would be do-able and won't end in "complexity hell", cache_pages should be fine, my only doubts are regarding sub cache layers like pagesection, those should get an eye first.