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

[Michael Stucki]

Hi Martin,

I am absolutely with you that we need such an improvement, but I dislike
the way how it's realised. Please see Ernestos comments about collecting
the timeout-information while the content is generated and not try to
look it up after everything is done.

-1

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)

Hope you agree that this is a better approach.

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


-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/