Bug #35684

Cache duration wrongly calculated with associated records

Added by Francois Suter about 9 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Must have
Category:
Caching
Target version:
Start date:
2012-04-04
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.6
PHP Version:
5.3
Tags:
Complexity:
medium
Is Regression:
Sprint Focus:

Description

In TYPO3 4.6, property config.cache was added to enable other records to influence the duration of a page's cache. The calculation happens in tslib_fe::getFirstTimeValueForRecord() but is broken.

The above-mentioned method searches for a minimum starttime and endtime (if both are defined for the given table) among records from a given table in a given pid. One condition exists to select records which have timestamps larger than the current timestamp, but it uses a OR on starttime and endtime. Example query:

SELECT MIN(starttime) AS starttime, MIN(endtime) AS endtime FROM tt_news WHERE pid=2070 AND (starttime>1333539180 OR endtime>1333539180) AND tt_news.deleted=0 AND tt_news.t3ver_state<=0 AND tt_news.pid<>-1 AND tt_news.hidden=0 AND (tt_news.fe_group='' OR tt_news.fe_group IS NULL OR tt_news.fe_group='0' OR FIND_IN_SET('0',tt_news.fe_group) OR FIND_IN_SET('-1',tt_news.fe_group))

This works fine as long as you have only records with a starttime, or only records with an endtime, or only records with both. But if you have records with a starttime but not endtime (or vice-versa), values of 0 will crop up in the results and the minimum will thus be 0.

A minimum of 0 actually kills this feature, because TYPO3 reverts to the page's default cache duration.

The solution is seek the minimum separately for each time field.


Related issues

Has duplicate TYPO3 Core - Bug #38838: False PageCacheTimeout / getFirstTimeValueForRecord calculation with start-/stoptimes on multiple content elements.ClosedAlexander Opitz2012-07-10

Actions

Also available in: Atom PDF