[TYPO3-core] RFC #9284: Feature: tt_content.starttime/endtime have now effect on caching

[Ernesto Baschny [cron IT]]

Hi,

idea is good. Solves some very common use-case (tt_content from a page 
being displayed on that page). But one might wonder why it doesn't work if:

a) PAGE rendering is not dependent on a CONTENT cObject rendering of 
tt_content at all, e.g. TemplaVoila
b) tt_content from a totally different page is being displayed (either 
by typoscript or by "show contents from page" setting
c) other kinds of "records" are being displayed on a PAGE.
d) etc...

In my eyes, you implemented that hook and the code in the wrong place.

I would love to have a generic way the rendering process could gather 
caching expiration information at run-time while it is being generated. 
In general this is a very very complex area and probably a generic and 
"works-for-all" solution isn't possible at all.

The idea of having a hook sounds nice at first. But I would rather use 
the cObject rendering process to gather that information on "what 
happened while rendering" and have that being used for cache expiration 
instead of having a hook do that afterwards (when it is probably too 
late to even know what happened).

Your later addition to use "$GLOBALS['TSFE']->cacheExpires" looks like 
the right direction to me. cacheExpires currently is only used for 
cache-headers send to the browsers, as far as I can see. So (mis)using 
it also for TYPO3 cache expiration might not be intended by this setting.

So I would suggest to go for a cacheExpires alternative, remove the hook 
and also the tt_content specific stuff from the setPageCacheContent() 
function.

Then you move the code to manipulate the cacheExpires variable in 
cObject and its functions (CONTENT, RECORDS, etc), which is where the 
"content" to be displayed is *really* selected. Introduce the new 
"cacheExpires" member variable into cObject (instead of TSFE). Document 
that new member variable in such a way that even USER objects are able 
to manipulate it (they have access to the current cObj via $this->cObj!).

Sounds like it could work?

Cheers,
Ernesto



Martin Holtz wrote: on 03.09.2008 22:53:
> This is an SVN patch request.
> 
> Type: Feature (or Bug, i am not sure)
> 
> Bugtracker references:
> http://bugs.typo3.org/view.php?id=9284
> 
> Branches:
> TYPO3_4_TRUNK
> 
> Problem:
> Page Cache is generated today at 10.00,
> without other configuration page cache is valid until tomorrow 10.00
> if an content element on that page has starttime today 11.00, it will shown
> up on that page tomorrow at 10.00
> 
> When TYPO3 looks up if there is a cache entry, it makes a join with pages
> and cache_pages. So starttime and endtime etc of pages has an effect. But
> tt_content or other elements not. I thought the best way is not to change
> that query, but to change expire timestamp of the cache entry.
> 
> Solution:
> before writing page cache with expire timestamp, we look up on that page, if
> there is a content element which has an starttime or an endtime withing
> today 10.00 and tomorrow 10.00. If there is one, the page expire timestamp
> will set to that timestamp.
> I added an hook too, so someone could check it for tt_news elements too...
> 
> Notes:
> i wrote an extension as proof on concept, it is available in ter and on
> forge: cacheexpire, there i wrote an simple test, how it could work for
> tt_news
> 
> thanks for reading:)
> martin