[TYPO3-dev] set_no_cache is bad. What's next?

[Elmar HInz]

Am Thu, 29 Mar 2007 16:04:02 +0300 schrieb Dmitry Dulepov:

> Hi!
> 
>  From time to time I see that people try to use $TSFE->set_no_cache() in 
> extensions. You know what happens next: no caching for pages, 
> performance is terrible, web server is not responding, etc. At the same 
> time, sometimes, in really rare cases caching must be disabled. But 
> definitely not this way from extensions.
> 
> Should we change this function in some way? Should it explain people 
> that using it is no-good?
> 
> Personally I would vote for radical methods like (1) keeping it but 
> emptying or (2) writing commented phrase inside generated FE page that 
> set_no_cache was used, so do not expect good performance.
> 
> Any other ideas/opinions?

Hi Dmitry,

it's good, if the core team starts thinking about this now. Extensions
with bad caching behaviour is one a mayor reason of performance loss of
TYPO3 installations. The usage of this function results of the chaotic
architecture of tslib_pibase and the example code that is/was generated by
the kickstarter. 

In the past I even found set_no_cache() in code generated by the
kickstarter. Does anybody know it that problem is removed meanwhile from
kickstarter? Most extension developers take the kickstarter output as
authority of best practice recommendations when they start.

Monthes ago, when I pointed out in this list, that cleaning and
simplyfication for caching are possible, you still didn't want to
slaughter holy cows. We need better caching behaviour and better extension
code.

A) I vote for (1) as long as I have the possibility to pass the no_cache
paramter by URL for debugging. (2) is also fine. Generate a frontend
warning "This is for development and debugging only ...". Something like
that. 

B) Many extensions will break by this. But there is a very simple
solution for pages with this extensions: Set "no cache" in the page title
of the BE form. That fixes the problem immediately with a few clicks.
People need to be informed early enough of this migration path. But it's
really worth to get rid of this dangerous function. 

Regards

Elmar