better cHash calculation (avoid cache flooding of USER_INT)
TYPO3 Caching and the cHash
What is the goal:
1) Content that can be cached should be cached
2) Content that is dynamic should not be cached, but the rest of the page
3) Not more cache entries then required
Problem description short:
Currently TYPO3 takes all parameters to calculate the cHash and have a seperate cache entry for that parameter combination. But for parameters that are evaluated in USER_INT (like uncacheable actions in extbase for example) this don't makes sense and results in two problems a) uncached page because of wrong cHash or b) too much unneccessary page cache variants.
Problem in Detail: (you may want to skip reading this part and check solution below)
Introduction with two Use-Cases:
- You have a single view that displays some data based on a "tx_news_pi1[uid]" parameter.
=> If you have a valid cHash for that parameter TYPO3 caches a separate variant of this page (e.g. id=12&tx_plugin_pi1[uid]&cHash=correct2343243 )
Use-Case 2: using _INT Typoscript Objects for Use-Case:
- You have a search that searches for things based on a query:
=> You are not allowed to have a cHash Parameter then. Your URLs need to look like this:
=> TYPO3 will then have only one Cache entry for that page. But your plugin will be a USER_INT and therefore can evaluate this parameter each time.
1) It is not possible to have this behaviour mixed on one page: If you have elements on your page that should be cached based on some parameters but you still want to have elements that needs to be uncached. And there are many use-cases for this!
So to come back to the two examples:
will not work since the cHash is not valid anymore
Will not work since with a missing cHash TYPO3 might deliver the wrong cached content for the news extension
Will work but pollute the Cachetable with new entries for every tx_search_pi1 parameter.
(And the additional problem that the cHash may not be possible to calculate)
2) The current extbase uncached actions solution is another example for the same problem. Since extbase replaces USER to USER_INT on the fly if an uncached action is called it needs to have the cHash Parameter set. Which results in a new Cache entry for every Parametercombination of the uncached action. Which makes it pretty useless in most cases.
3) A third aspect of that example is, that parameters like "L" or other Parameters that might be part of some conditions are used for cHash calculation also. That can cause tricky bugs and uncached pages also.
The cHash should (and have to) be only calculated and evaluated for parameters that are used in cachable plugins (or actions).
For the above example that means:
should both result in a cache hit.
=> should trigger an cHash error since its a wrong cHash
=> should throw an cHash error too, since the cHash is missing but required for tx_plugin_pi1[uid]
The patch set introduced a new class for the cHash calculation because of:
1) it could be xclassed if there are very special requirements to cHash calculation
2) the class could be unit-testes
3) it makes sense to move features from t3lib_div for maintenance reasons
Updated by Philipp Gampe over 12 years ago
Your page includes global Install Tool configuration options.
Now think about a multidomain site with 4 languages and a multitree concept. You can not certainly say which parameter you need on all site or you will choose to much.
I know this can not really go into TS template, because this would turn the cache useless. Maybe you could allow to override those Install Tool settings inside the domain record? I guess those are loaded on each pagehit anyway.
Or one would need to introduce ugly localconf.php conditions which makes troubles, because the install tool does not support those.
Could someone with more knowledge of the TYPO3 bootstrap say what could be a possible solution.