Bug #91561

Lifetime of cache is not properly computed for "Insert Records" CE

Added by Xavier Perseguers 8 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2020-06-03
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Use case

  • A content element (text/image/...) is prepared and corresponding start/end times are specified
  • This content element is to be used at multiple places on the website and is thus referenced (paste as reference when using EXT:gridelements or simply using "Insert Records" TYPO3-native CE

Expected

  • When the content element on the "master" page finally shows up (or disappears), every page having a reference to that content element should be automatically updated, that is the cache should be invalidated.

Actual behaviour

  • Only the cache of the "master" page is automatically flushed
  • Other page's caches are not invalidated and a manual flush is required (or a force-reload while being logged-in into the Backend).

Reason

Method \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::getFirstTimeValueForRecord() is supposed to compute the cache lifetime of CEs on a given page. But it only takes into account the start/end fields of the corresponding records.

For "Insert Records" (= shortcut) content element, only the start/end times of the shortcut are taken into account but not the ones of the referenced records.

Expected behaviour: both start/end times of the shortcut CE and all the associated records should be taken into account in that particular context.

In addition, and this could be a real improvement for extension authors, it would be useful to allow extensions to "hook" (PSR-14 if speaking from TYPO3 v10 or master branch, signals/whatever before) so that plugins may benefit from the same possibility than this very shortcut CE to post-process the lifetime in the context, e.g., of a plugin doing some temporary caching of external data and where one way (only "good" one?) to properly handle such case is to add tags to the corresponding page cache and to flushByTags() asynchronously when fetching remote data (or force the whole page to be cached for a shorter period of time).


Related issues

Related to TYPO3 Core - Bug #92535: Extbase controller / Plugins can't modify page cache lifetimeNew2020-10-11

Actions
#1

Updated by Sybille Peters 6 months ago

  • Related to Bug #90406: Caching of pages is not adjusted for content with "Publish Date" / "Expiration Date" (starttime, endtime) added
#2

Updated by Sybille Peters 6 months ago

  • Related to deleted (Bug #90406: Caching of pages is not adjusted for content with "Publish Date" / "Expiration Date" (starttime, endtime))
#3

Updated by Christoph Lehmann 3 months ago

  • Related to Bug #92535: Extbase controller / Plugins can't modify page cache lifetime added

Also available in: Atom PDF