Project

General

Profile

Actions

Bug #91714

closed

Cached where clauses in PageRepository

Added by Simon Praetorius over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Caching
Start date:
2020-06-26
Due date:
% Done:

100%

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

Description

There seems to be a problem with a runtime cache that was introduced with TYPO3 9.5.17 (and due to a bug became active in TYPO3 9.5.18).

In our client project, we hook into "enableFields" to add another constraint for "pages" and "tt_content" records. In 9.5.18 this stopped working for "pages" because the runtime cache doesn't account for varying values returned by this hook. The "where_hid_del" variable is only calculated once and then stored in the runtime cache.

We register the hook like this in ext_localconf.php:

call_user_func(function () {
    $hookClassName = \SMS\SitegeistNotingroup\Hooks\EnableColumns::class;
    $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_page.php']['addEnableColumns'][] =
        $hookClassName . '->addEnableColumns';
});

In the actual hook function, we use the frontend user aspect to check for the login state of the current user. Since PageRepository is probably used quite early, this aspect isn't fully initiated the first time the hook is called. In TYPO3 9.5.17 and below this worked out fine because the hook is evaluated every time, now it doesn't.

Feel free to contact me via Slack if you want to look into this. We have an extension with functional tests which could be used to debug this. Unfortunately I wasn't able to find a good solution yet.

Actions

Also available in: Atom PDF