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

[Martin Holtz]

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
but TemplaVoila is an Extension - IMHO TemplaVoila should manage that (and
it will be possible with that patch)

> b) tt_content from a totally different page is being displayed (either
> by typoscript or by "show contents from page" setting
You are right, i think about content-slide etc. :(

> c) other kinds of "records" are being displayed on a PAGE.
tt_news for example - there should be a solution for that in tt_news i
think? i wrote an extension for that too (which is only a very simple
implementation)

> d) etc...
As Martin Kutschker said, another SELECT Query is not that nice...
but there is no information about records which are not be selected, because
they have an start time in future (stop-time should be possible somehow)
 
> In my eyes, you implemented that hook and the code in the wrong place.
You are right, that is not an perfect solution. But i think it fits in 90%
and it is very efficient. On an typical (NON-TemplaVoila) page we have much
more CONTENT-Objects.

> I would love to have a generic way the rendering process could gather
> caching expiration information at run-time while it is being generated.
me too:)

> In general this is a very very complex area and probably a generic and
> "works-for-all" solution isn't possible at all.
that is what i think - or, an "works-for-all" solution will have too much
overhead. The additional select-Query is only used, if we write the page to
cache. 

> 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).
That would have a chance for an "works-for-all" solution, but i think it
will lead into much more SELECT-Statments - because you have to check
twice - or have to check it via php

> 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.
hm... i see that is all more complicated as i thought:)
If the page should not be cached, the cacheExpires should be set to 0 - but
if we use that from an extension we send an wrong cache-header? 
Ok, i will check that...
 
> So I would suggest to go for a cacheExpires alternative, remove the hook
> and also the tt_content specific stuff from the setPageCacheContent()
> function.
yep, i think now, you and Martin are right with that. 
 
> 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?
i will give it a chance:)

As first steps, i will remove the hook and the tt_content select query and
check the behavior of the cache-headers.

i will be back ... one day;)

gruss,
martin


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