[TYPO3-core] RFC #9284: Feature: tt_content.starttime/endtime have now effect on caching (with patchfile now, sry)

[Martin Holtz]

Hi Michael,

> Proposal for a better solution:
> - Introduce a new flag for every content element ("timeout" or whatever)
> - Add a method that is called in tslib_content for every content element
> - This method will always calculate the lowest timeout-value and set it
>   accordingly when the page is stored into the cache.
> - Of course this requires modification to all plugins. The reasonable
>   default should be a timeout of 1 day (just like now).
> - Additionally, some config options could then be removed (like
>   config.cache_period and config.cache_clearAtMidnight)
so your strategy would be: find the next record which would change the
content of that page?

Because we do not know the logic of the plugins, we cannot take care of the
plugins. If they use CONTENT or RECORDS it would be possible, but if they
make SQL-Statements we have no chance. So wee need the cache dependend
config-options.

My approach would now be:

I can get the stoptime: - i could check every record which is loaded from
the database.

I could remove the starttime-check from enableFields and then check in
RECORDS and CONTENT (afaik, they both use the same select) the starttime
for each record via php.

A little bit more complicated will it be, if we have CONTENT with limit
(perhaps the first Records has starttime in future...). But that could be
managed too, somehow.

If someone use IF-Statements which checks the time to render "good morning"
or "good evening" he should use COA_INT for that, i do not think that we
should take care of such things - right?

Are there more "content elements" i have to care of?

And i do not see, why i should need an additional flag "timeout".

But as an first step, i will patch my patched patch to get the possibility
into the core.

After that i could start writing an extension for testing the steps which
are discussed here.

gruss,
martin

> 
> - michael
> 
> Martin Holtz wrote:
>> Hi Ingo,
>> 
>> thanks for your feedback.
>> 
>> So, i try again:)
>> 
>>> * the diff is not against the root of TYPO3 (not a big problem though,
>>> just keep that in mind)
>> i hope it is correct now?
>> 
>>> * line 10: until there's a final decision about the indentation of
>>> inline comments and until this decision is released, inline comments are
>>> indented with one tab (also applies to all other inlne comments in your
>>> patch)
>> should be correct now?
>> 
>>> * line 14: you either check whether this method exists or go with (the
>>> better way of) requiring the object to implement an interface (check
>>> t3lib/interfaces/ f.e.)
>> i did, but i didnt now how the timestamp for the exception is generated -
>> timestamp at coding time? Is there an doc where i have to put it into?
>> 
>>> * line 18: $sys_page -> $pageSelect
>> renamed
>> 
>>> * line 23: split the parameter of exec_SELECTquery onto one line each
>> hope it is correct now?
>> 
>>> * lines 46, 50: no need for a log here (IMO)
>> deleted
>> 
>>> In general you can't use the default cache period for calculations,
>>> there's a separate field for the cache period in table pages, use this
>>> field's value.
>> that is done in realPageCacheContent()  the parameter $tstamp in
>> setPageCacheContent() is the calculated timestamp which depends on
>> page-setting, clearCacheAtMidnight etc. But that is done before
>> setPageCacheContent
>> 
>> I did two additional changes:
>> 1) there is $GLOBALS['TSFE']->cacheExpires available for extensions
>> (tslib_fe->cacheExpires). If a tt_news plugin is inserted via TypoScript,
>> it would be extrem difficult to solve that via an Hook. But it is simple
>> to change via $GLOBALS['TSFE']->cacheExpires. That value is 0 while
>> content is generated. If an plugin is used, it can check if the
>> cache-expire-timestamp should be altered, set that value and it will be
>> checked. (so, i am not sure, if the hook is usefull anymore....)
>> 
>> 2) The page with the message "Page is generated" is cached too - but only
>> for 30 seconds. I think it would not be usefull to use the hook in such
>> an case.
>> 
>> thanks,
>> martin
>> 
> 
>