Feature #39228
closed
Hook to disable writing page cache
Added by Francois Suter almost 12 years ago.
Updated over 6 years ago.
Category:
Content Rendering
Description
There are possibilities - like well-known extension nc_staticfilecache - to write the pages to special caches, like static HTML files. When using such a system, it does not make sense to write those same pages' cache to the selected cache backed. OTOH disabling the whole page cache (by writing it to the Null backend, for example) is not a solution as we still want to cache the pages that were not handled by the extra handling (typically pages with USER_INT objects).
I propose adding a hook in tslib_fe::realPageCacheContent() that performs a check whether the page cache should be set or not.
Files
- Status changed from Accepted to Under Review
How to test:
- click on a few pages in your site (some with USER_INT objects, some without): all get written to cache.
- apply the patch
- install the test extension attached to this issue
- visit the same pages as before: only the pages with USER_INT objects should be written to cache (the other pages are assumed to be fully static and handled with another cache mechanism in the "insertPageIncache" hook.
I would rather choose a cleaner approach:
Introduce a "DualCacheBackend" (or whatever name). This one would take configurations for two "real" cache backends and then decide which to use when. AFAIK Zend Framework has such a thing, but I can't remember the exact name.
Ideally we would not need nc_staticfilecache anymore and would provide a caching backend for the exact purpose of writing html files.
I agree with Ingo that this should be the way the go: Caching and Static File Caching should be inside the Caching Framework, not with hooks anymore.
Sure, yes, would be cool. But as I answered in the review, I don't have time for this. So either this hook request goes in - to be replaced by something better in a later TYPO3 version - or I'll keep patching my Core. Sorry, I can't do better at the time, I have no time for serious Core work.
Mmmh, for the cf, that can be used to spit out html: This is not really scope of the cf, it is constructed to cache file under 'some' name, that is not excpected to be included directly. For example it is not possible and not wantod to get the patch to a cached .js file from a fileBackend in order to include it in html head. We have similar issues for compiled js and css, and the cf is not the right place to put it. It is also possible to move for example the fileBackend cache file location out of the document root, which would clash with such a requirement directly.
I think we could talk with the flow3 guys about that and ask how they would expect it to be done, imho there needs to be at least another layer that might allow those things under some criteria.
For now, I'd say it is ok if we implement the propose hook to solve this is our application on our own. I'll now review and vote the hook.
Christian, thanks for your input.
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by