Bug #82528
open
SYS_LASTCHANGED value not being correctly set if RESTORE_REGISTER is used
0%
Description
Each time TYPO3 renders a content element, it stores its timestamp value in SYS_LASTCHANGED in the REGISTER, keeping it warm until the end of the page rendering process
-> in \TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer::lastChanged
and then saving then value in the DB.
-> in \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::setSysLastChangedIf you use RESTORE_REGISTER cObject in your TS, it will reset the Register, setting it back to the previous values
-> in \TYPO3\CMS\Frontend\ContentObject\RestoreRegisterContentObject::render
So if RESTORE_REGISTER is used in a TYPOSCRIPT, the registered SYS_LASTCHANGED value is reset before being stored in the DB, so SYS_LASTCHANGED updates are may never be saved in DB.
SYS_LASTCHANGED temp value should not be set in Register in order to avoid it being reset.
Files
Updated by 
Updated by
Updated by Fabian Schöner about 5 years ago
This bug also exists in TYPO3 7.6.34.
Updated by Guillaume Germain about 4 years ago
- Target version set to Candidate for patchlevel
This bug also exists in TYPO3 9.5.13.
There is a problem with the Introduction Package because the "bootstrap_package" extension uses "RESTORE_REGISTER" in lib.dynamicContent.
Updated by Guillaume Germain about 4 years ago
- Category changed from TypoScript to Frontend
It concerns the TypoScriptFrontendController class.
Updated by Petra Neumann over 3 years ago
The problem still exists in TYPO3 v10.
If any RESTORE_REGISTER is called, the temp value for SYS_LASTCHANGED is gone. Since ext:fluid_styled_content suggests using RESTORE_REGISTER for inserting content in the page template based on FLUIDTEMPLATE (see lib.dynamicContent), a lot of site-package extensions make use of it (like the bootstrap package). So in many TYPO3 installations SYS_LASTCHANGED is only updated for changes of the page properties but not the page content. This might be a problem, since the ContentObjectRenderer.php reads "The SYS_LASTCHANGED timestamp can be used by various caching/indexing applications to determine if the page has new content." - which will not work as intended then. Also, some sites use SYS_LASTCHANGED to show a "Last Updated on ...", even though it is not intended for that originally - this also fails with the value not being written correctly.
Updated by Reindl Bernd almost 3 years ago
If 'SYS_LASTCHANGED' is stored outside the $register variable, it's no longer available via 'data = register:SYS_LASTCHANGED' in TypoScript.
Quick solution:
@
public function render($conf = [])
{
$SYS_LASTCHANGED = isset($GLOBALS['TSFE']->register['SYS_LASTCHANGED']) ? $GLOBALS['TSFE']->register['SYS_LASTCHANGED'] : false;
$GLOBALS['TSFE']->register = array_pop($GLOBALS['TSFE']->registerStack);
if($SYS_LASTCHANGED !== false)
$GLOBALS['TSFE']->register['SYS_LASTCHANGED'] = $SYS_LASTCHANGED;
return '';
}
@
So 'SYS_LASTCHANGED' is still available in register but is not restored when RESTORE_REGISTER is called.
Updated by Daniel Lorenz almost 3 years ago
- TYPO3 Version changed from 8 to 10
We have been able to successfully test this change in a current TYPO3 v10.4.
Updated by Simon Gilli over 2 years ago
- Related to Bug #90827: If you edit the page content element, the "Last Mod." does not change. added
Updated by Anonymous over 2 years ago
Daniel Lorenz wrote in #note-8:
We have been able to successfully test this change in a current TYPO3 v10.4.
We have the same problem. Especially with indexed_search which does not recognize changes to the page content.
Quickfix successfully tested under 10.4
Updated by Sebastian Schmal about 2 years ago
- TYPO3 Version changed from 10 to 11
- PHP Version changed from 7.0 to 7.4
same problem with the ext:seo (TYPO3 11.x)
typo3\sysext\seo\Classes\XmlSitemap\PagesXmlSitemapDataProvider.php
'lastMod' => (int)($page['SYS_LASTCHANGED'] ?: $page['tstamp']),
but the field "SYS_LASTCHANGED" have a old timestamp in the DB.
the field "tstamp" is right, but the ext:seo take the SYS_LASTCHANGED
Yes, it update the page, like this https://forge.typo3.org/issues/90827#note-1 (only updated in the frontend), but why?
Updated by Oliver Pfaff about 1 month ago
- File BUGFIX_core_bug__forge_typo3_org_issues_82528.patch BUGFIX_core_bug__forge_typo3_org_issues_82528.patch added
This seems still a thing. Here a new Patchfile for TYPO3 11, it uses the same solution from Reindl Bernd but avoids the usage of the $GLOBALS like the implementation in V11
Probably the bug is still inside v12 as well, i didn't test this. RestoreRegisterContentObject in v12 is the same as in v11 but maybe a different or better solution was found.