Feature #19283
closedpage cache is not influenced by tt_content.starttime/endtime
0%
Description
The actual caching meachanism works like that:
- page is generated
- expiredate is calculated (by clearAtMidNight or page caching config,
usually set to generating time + one day)
- if a page is requested, TYPO3 checks wether the cache is expired or the
page starttime/endtime should take effect.
So an content element has no influence on caching time.
If a page is cached at 2pm (with 24hours cache-expire) and there is a
content element with an starttime at 3pm on that day, that content element
will be visible first at 2pm the next day (when the page cache expires).
As an proof of concept i wrote an extension:
http://forge.typo3.org/projects/show/extension-cacheexpire
With that extension the expire-timestamp of the pagecache will be calculated based on starttime/endtime of all content elements on that page. Deleted, hidden, starttime, endtime and group-permissions are respected.
For different tables then tt_content it is possible to use an hook. With that extension i provide an very simple class which hooks in and takes care of tt_news elements (if there is a plugin on that page).
I made an patch of that extension for integrating into the core.
(issue imported from #M9284)
Files
Updated by Martin Holtz about 16 years ago
The new 9284.diff is from Ingo Renner in the core mailinglist
Updated by Martin Holtz about 16 years ago
another try:
i removed the hook and the sql-query and reduced this patch that it only reacts on
$GLOBALS['TSFE']->cacheExpires
Updated by Martin Holtz about 16 years ago
i uploaded another patch
this time with an additional function to set cacheExpires Timestamp
Updated by Francois Suter almost 16 years ago
Attaching a corrected patch, as submitted in the core list
Updated by Francois Suter almost 16 years ago
I have tested this patch with a quickly put together extension, which I am attaching here. The extension is called "xnews". It's a FE plugin that just gets the 10 latest records from the tt_news table (so you need tt_news installed too). There's no configuration at all. Just insert an instance of xnews on some page and display the page. You should a list of 10 news items plus an indication of when the next update should take place, i.e. when the cache will expire.
To test properly you obviously need to have at least 1 tt_news with a starttime in the future.
You can check if that matches the information stored in the cache_pages table.
The xnews extension actually relies on an (as yet) unpublished extension called "overlays" (and this is even a modified version just for testing this patch). So you need to install "overlays" too. "overlays" is used to simplify querying the DB in particular in a multilingual setup. In this case I added a method for simply getting all records in the future and calculating a precise expiry time for the cache.
Updated by Dmitry Dulepov over 15 years ago
Please, see also #20473. It provides an automatic solution to this problem.
Updated by Martin Holtz over 15 years ago
hi dmitry,
in my eyes
#20473
is an better approach.
Updated by Xavier Perseguers over 13 years ago
- Target version changed from 4.6.0 to 4.6.0-beta1
Updated by Stefan Neufeind over 13 years ago
The functionality described in this issue-description is what #20473 (already commited now) offers. So I'd say we should close this one.
Updated by Ernesto Baschny over 11 years ago
- Target version deleted (
4.6.0-beta1)