[TYPO3-mvc] Caching problem?

[Franz Koch]

Hey,

>> Configuring piBase extensions like this will give you the same result ;)
>
> I know but as the same time we all know so many extensions where the
> plugin was set to USER_INT or the whole cache was invalidated because
> the developer did not understand the whole caching stuff and how to deal
> with it correctly.

Do we know how to deal with it correctly ;) We create correct URLs 
according to caching guidelines, but as you see this also has side 
effects. Maybe we should simply add a &no_cache=1 :P

>> I agree that this has to be fixed ASAP - but it's not that much of a
>> no-go then always appending a cHash for me.
>
> Well, with Extbase, the meaning of "actions" is really clear, much more
> than with pibase when someone did not have a clear separation of methods
> (which happened quite often to be honest). Having an official MVC
> framework forces the extension to be automatically at least "a bit
> cleaner". Having an index action (often listing some records) being
> cached is really common and wanted because generating it again and again
> because of some other action need is not "logical". Furthermore, perhaps
> your index action only provides additional edit action links if you are
> logged in...

> I agree that having cHash for uncached actions is a bit weird at first
> but it definitively makes sense to let the USER somehow become a
> USER_INT once it has been cached.

It of course makes sense to somehow tell TYPO3 to now switch to a page 
cache version where the plugin is of type USER_INT - but flooding the 
page cache table with thousands of copies of the EXACT SAME code of the 
page (document HTML with comment for USER_INT script) is no solution and 
bad practice either.

So we all agree that the current behavior is a no-go and the intended 
solution is also a no-go. And nobody knows how to fix this with current 
functionality. The conclusion for me is, that the bug relies in TYPO3s 
caching mechanism and should be addressed there. We need a way to tell 
TYPO3 to create a new cache entry for a page in order to render a 
USER_INT plugin without creating a new entry for each and every GETvar 
combination.
This could be achieved by some additional GETvar, beeing part of the 
cHash calculation of course to be able to validate the request URI. And 
if this flag is found, TYPO3 should NOT use the cHash_params to create 
the page-hash/identifier and fetch the page, but the identifier defined 
in the additional GETvar instead (see methods makeCacheHash and getHash 
of tslib_FE).

Example: 
...some-domain.tld/?tx_extkey_namespace[action]=edit&tx_extkey_namespace[entry]=4&intToken=tx_extkey_namespace&cHash=53234k3423


Using the full extension namespace as token would ensure that TYPO3 can 
differ between different plugins on the same page. This will of course 
also result in multiple cache entries, but only one for each plugin 
which makes sense I think.

What do you guys think? Should be quite easy to implement in both, TYPO3 
(seems that we only have to adjust the mentioned to methods from above) 
and Extbase.


-- 
kind regards,
Franz Koch