[TYPO3-core] RFC #9284: Feature: tt_content.starttime/endtime have now effect on caching
Ernesto Baschny [cron IT]
ernst at cron-it.de
Thu Sep 18 23:52:42 CEST 2008
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
More information about the TYPO3-team-core
mailing list