[TYPO3-dev] WARNING!?? tslib_patcher, pp_chashchecker
Elmar Hinz
elmar07 at googlemail.com
Mon Aug 27 10:40:51 CEST 2007
Dmitry Dulepov [typo3] wrote:
> Ingo Renner wrote:
>> I just had that problem again with a form...
>>
>> The form could be chached, but the results must not of course. I first
>> used a hook to detect a POST request for that extension to switch it to
>> USER_INT but as this didn't seem to work in the live environment I
>> removed it again and switched the whole plugin to USER_INT...
>
> I think I know how it can be done in the core but I afraid it will not
> pass through because it may break compatibility.
>
> Generally the idea is:
> - $TSFE->no_cache is saved before entering USER extension
> - $TSFE->set_no_cache() causes a flag set that tells typo3 that this
> extension does not want caching
> - $TSFE->no_cache is restored after exiting USER extension
> - if set_no_cache was called, extention's output will be discard and it
> will turned to USER_INT to be called later
>
> Additionally several new functions will appear in tslib to work with
> cache. All new extensions should use those. Something like
> disablePageCache(), setNoCache(). The first is obvious, the second sets
> the same flag as $TSFE->set_no_cache() when called from USER. Extension
> can exist right after setNoCache() without any futher content generation.
>
> This is the idea.
>
Hi Dmitry,
I think it could solve this end of the caching problem. We are all sure that
the no_cache flag has to be disabled or removed. That can't be done without
breaking compatibility somewhere. This solution would do this in a very
soft way. I think most existing extensions would keep working and most of
them would work in the way the author inted them to do.
It doesn't solve all problems, like that of forms sending the no_cache flag,
because of bad code generated by the kickstarter.
Fine concept. I long for to see it implented.
Regards
Elmar
More information about the TYPO3-dev
mailing list