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

[Elmar Hinz]

Am Fri, 06 Apr 2007 12:38:01 +0200 schrieb 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?

Hi Ernesto,

no I am not at T3DD. I put down my thoughts upon this field to my blog, so
you will have them available as a discussion help. They are written from
the point of view of the extension developer, don't asking directly what
is possible inside the core.

Summary

RFC article:

http://t3flyers.wordpress.com/2007/04/04/rfc-caching-useruser_int-switching/

Proper caching Episode 1 - 3:

http://t3flyers.wordpress.com/2006/09/11/a-quick-guide-to-correct-caching-with-pi_base/
http://t3flyers.wordpress.com/2007/04/06/a-quick-guide-to-proper-caching-with-tslib_pibase-episode-2/

The 3. Episode is planned cover the USER/USER_INT switch invented by
JoH.

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

1.650.000 page views with worst performance. If we assume an average of
50 different views per page and 50% of the pages already set to no_cache
in the backend we have come to 16.000 plugins for which to set no_cache in
the backend until the plugins are fixed.

So 16.000 clicks for the customers to no_cache upon update, would be the
price to pay not to get 10.000.000 millions Google hits for "no_cache=1"
in the near future. So I come to the conclusion that it can be more daring
not to act. At least if we wan't to avoid the reputation the TYPO3 is slow
for the advancing standards of "web 2.0".

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

The identical name is a hint to this. However it should be possible to
split this behaviour and to turn off the relevant branches. I.e. frontend
preview could work in a different way. I would think of a different
parameter, so that the consuming check for be_user login can be triggert
by this.

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

We have both options to start NOW or not to do it at all and wait for V5.
As V5 is still very far away IMHO the caching problems of V4 is worth a
major task. It's one of the important factors if TYPO3 can close the
technological gap until V5.

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

That can be an option, but should be promoted as ultima ratio. The danger
is that is quickly becomes a kind of a easygoing default. On the other
hand it can be an advantage, because there aren't different points to turn
off no_cache check in pages if plugins improve.


Regards

Elmar