The thread “tx_base – tslib_pibase modernized” in typo3.teams.extension-coordination shows that the current system of caching is to complicated and that the conception is not really clean.
The questions are:
1.) How would a modernized system look like?
2.) How can it be implemented into TYPO3 4.x without breaking existing installations and extensions?
I summerize my current thesis about this and ask for your comments:
A) Disabling set_no_cache() function AND no_cache parameter
As Dmitri pointed out in t.dev the set_no_cache() function is one of the
most abused ones. It’s the same with the no_cache parameter.
A.1) How a modernized system would look like?
I suggest to disable the function of the set_no_cache() function AND the
no_cache parameter in the core, to force extension developers to work
without it.
A.2) How it can be done without breaking existing installations and extensions?
a) To keep plugins working that make use of the no cache parameter, the
“no cache” checkbox in the BE page form can be used. This BE functionality should be preserved for this purpose.
b) The same checkbox can be used during development where developers else would make use the no_cache parameter.
B) If there is a cHash always check & cache
Currently the prerequest to cache a page is that the URL is signed with a valid cHash and that the checkCHash flag has been set from at least one extension in the page. Because it can be triggert by different plugins in the page, the latter setting is not reliable way to controll the caching of a plugin. So this flag is likely a misconception.
B.1) How a modernized system would look like?
In a modernized version a page would always be cached if a valid cHash has been send. The triggering with checkCHash is not necassary any more. The caching is simply controlled by signing a link with a valid cHash or not doing it.
This system is easy to understand and less error-prone, because it forces a clear decision for each link that is coded.
B.2) How it can be done without breaking existing installations and extensions?
In fact there shouldn’t be many extensions that create cHashed links without wanting the target page to be cached. So this is a very limited problem.
This extensions are already dangerous today. They result in flodding the cache tables as soon as they are installed into a page where another plugin sets checkCHash. This insane extensions will break if cHashed pages are always cached. They need to be fixed immidately. And that is good.
Some remarks on details
pageNotFoundOnCHashError
Currently we get an error for the configuration pageNotFoundOnCHashError = 1 if we send a non cHashed URL to a page where checkCHash has been triggert. Here the problem is that the cHash is checked although no cHash has been send at all. So this is a special case of B). A cHash should only be checked if a cHash has been send.
How to switch a plugin between USER and USER_INT
One idea of the checkCHash flag has been to enable a simple possiblity to switch a plugin quickly between USER and USER_INT. Now we need to give a different answer to this task.
a) Typically we need this kind of switch during development. We need to pay attention to the links inside the plugin and to links pointing to it from other plugins. During development we would set the cHash to false for this links. On deploying we set them to true. Typically there are only a few links to watch (that to detail views and fix lists). Specially in case we have many links we can automate the switching by defining a class variable and feeding them as $cache parameter to the link functions.
b) In some cases we really want a switch between USER and USER_INT for a deployed extension. In this case the solution would be similar to a).
