[TYPO3-ect] RFC: Caching, USER/USER_INT switching

[Ernesto Baschny [cron IT]]

Hi Elmar,

that was a nice summary and is a very good idea. I think this is
something that can be discussed in Dietikom in the T3DD. Will you be
there? Maybe we can have a "session" on Plugin-Caching?

I will only comment fragments of the proposition for a start:

Elmar Hinz wrote: on 04.04.2007 13:13:

> 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.

Very daring. I am not sure what is the effect of this on a productive
environment. At least it will give people more to think of when they
upgrade (or even make them avoid upgrading). There might be uses of the
&no_cache=1 parameter that we cannot predict.

Searching in Google for "no_cache=1" gives me 1.650.000 hits.

> 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.

This checkbox currently also translates into adding a &no_cache=1 to all
typolinks generated to that page. There are still other uses of
set_no_cache() inside core which cannot be removed easily (but might be
renamed to something else):

- frontend preview with be_user logged in
- page with field no_cache set to 1: so this should also work even
without a &no_cache=1 in $_GET
- miscalculation of a cHash (in which case we should simply
ignore/remove the bogus cHash parameter)
- config.no_cache=1 in TypoScript

I think this will be a major task that will require much testing by the
community so that we get it stable. But I also think we should start
sometime with that.

> b) The same checkbox can be used during development where developers else
> would make use the no_cache parameter.

Maybe there are other uses of &no_cache=1 out there in the "wild"? We
will not really be able to support all bug reports about caching
problems that will arise with such a change.

A less risky variant would be to have a "compatibility" switch in the
install tool. It could generate an ugly yellow warning in the backend,
but still allow someone to upgrade even with considered risk of not
using the cache correctly.

> B) If there is a cHash always check & cache

If the cHash is there but INCORRECT, either:

- don't cache the page if pageNotFoundOnCHashError=0
- error message if pageNotFoundOnCHashError=1 (which should then be the
default)

> Currently the prerequest is to cache a page is that the URL is signed with
> a valid cHash and the the checkCHash parameter has been set from at least
> one extension in the page. Because it can be triggert by different plugins
> in the this setting is not reliable to controll the caching of a plugin.
> This flag is a misconception.

I tend to agree!

> 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 can only be controlled by signing a link with a valid cHash or
> not doing it.
> 
> This system is easy to understand and less error-prone, but it forces the
> programmer to cleanly think about each link he generates.
> 
> 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. Now we need
> also to keep gard of the links inside and to the plugin. 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 inside an
> extension that need a cHash (that to detail views). 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).


Cheers,
Ernesto