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

[Michael Stucki]

Hi Martin,

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

Yes, exactly.

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

There is a chance:
- We don't know the logic of an existing plugin, but what we do know is
  that currently, a plugin is either non-cached or expires after 1 day
  (because the default of config.cache_period is 1 day)
- New plugins can use the more powerful method which I mentioned earlier
  in this thread. Fallback (if they wouldn't use it) is still 1 day.

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

Don't even think about autodetection of a plugin functionality - we
simply cannot know without instruction by that plugin.

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

This sounds nice but still seems too complicated to me. But I think the
solution is really simple: Just think of some content as it is was a
plugin. The content can set the same instructions like mentioned above
right during parsetime in tslib_content. No need to collect timestamps
and do some weird calculations with it. When you parse all objects, you
will know at the end when their lowest timeout will be.

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

*_INT objects should skip the instruction because in the cached record
they are represented by a (static) placeholder.

> Are there more "content elements" i have to care of?
> 
> And i do not see, why i should need an additional flag "timeout".

I think you try to solve the problem from a different direction than I
would propose. You are trying to fix the problem for all static elements
but will fail as soon as it comes to dynamic content.

However if you try to solve the situation for dynamic content first, the
static content can be updated very easily.

This new flag is not needed for now, just forget about it.

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

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