Project

General

Profile

Actions
Copy link

Bug #82528

open

SYS_LASTCHANGED value not being correctly set if RESTORE_REGISTER is used

Added by Presedo Roberto about 7 years ago. Updated about 1 month ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
Frontend
Target version:
Candidate for patchlevel
Start date:
2017-09-21
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.1
Tags:
Complexity:
medium
Is Regression:
Sprint Focus:

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::setSysLastChanged

If 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

Download all files
RestoreRegisterContentObject.php (1.34 KB) RestoreRegisterContentObject.php Reindl Bernd, 2021-05-28 07:02
BUGFIX_core_bug__forge_typo3_org_issues_82528.patch (1.08 KB) BUGFIX_core_bug__forge_typo3_org_issues_82528.patch Oliver Pfaff, 2024-03-15 15:19
BUGFIX_core_bug__forge_typo3_org_issues_82528_v11_5_39.patch (1.03 KB) BUGFIX_core_bug__forge_typo3_org_issues_82528_v11_5_39.patch Florian Windisch, 2024-09-02 08:25

Related issues 1 (1 open — 0 closed)

Related to TYPO3 Core - Bug #90827: If you edit the page content element, the "Last Mod." does not change.Accepted2020-03-25

Actions
Actions
Copy link
 #1

Updated by Susanne Moog about 7 years ago

  • Category set to TypoScript
Actions
Copy link
 #2

Updated by Christian Forgács almost 6 years ago

This bug still exists in TYPO3 9

Actions
Copy link
 #3

Updated by Fabian Schöner over 5 years ago

This bug also exists in TYPO3 7.6.34.

Actions
Copy link
 #4

Updated by Guillaume Germain almost 5 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.

Actions
Copy link
 #5

Updated by Guillaume Germain almost 5 years ago

  • Category changed from TypoScript to Frontend

It concerns the TypoScriptFrontendController class.

Actions
Copy link
 #6

Updated by Petra Neumann about 4 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.

Actions
Copy link
 #7

Updated by Reindl Bernd over 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.

Actions
Copy link
 #8

Updated by Daniel Gohlke over 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.

Actions
Copy link
 #9

Updated by Simon Gilli over 3 years ago

  • Related to Bug #90827: If you edit the page content element, the "Last Mod." does not change. added
Actions
Copy link
 #10

Updated by Anonymous about 3 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

Actions
Copy link
 #11

Updated by Sebastian Schmal almost 3 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?

Actions
Copy link
 #12

Updated by Oliver Pfaff 8 months ago

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.

Actions
Copy link
 #13

Updated by Marc Hirdes 5 months ago

The patch works as it should. Is it possible to update the core?

Actions
Copy link
 #14

Updated by Florian Windisch 3 months ago

Oliver Pfaff wrote in #note-12:

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.

We just recently did a composer update on our v11 systems and the patch couldn't apply.
cms-frontend updated to v11.5.39 and in that version RestorRegisterContentObject.php got changed.
On line 33 they added a null coalesce operator for the array_pop.

public function render($conf = [])
{
    $frontendController = $this->getTypoScriptFrontendController();
    $frontendController->register = array_pop($frontendController->registerStack) ?? [];
    return '';
}

Attached is a new patch file that supports v11.5.39, from what i can tell this should also apply to v12.4.18 and above.

Actions
Copy link
 #15

Updated by Marya Hachimi about 2 months ago

Hello, this bug also occurs in TYPO3 versions 11.5.39 and 12.4.20. Has the patch been considered by the team? If not yet, is there a merge request addressing it? Do you plan to fix it soon?
Thank you!

Actions
Copy link
 #16

Updated by Simon Child about 1 month ago · Edited

  • TYPO3 Version changed from 11 to 12
  • PHP Version changed from 7.4 to 8.1

I'm experiencing this bug still present on an Introduction package / bootstrap_package / TYPO3 website

  • TYPO3 12.4.22
  • bootstrap_package 15.0.0

The xml sitemap does not update when page content is updated.

After applying the patch from https://forge.typo3.org/issues/82528#note-14 the sitemap does update

Actions
Copy link

Also available in: Atom PDF