Project

General

Profile

Actions

Bug #91432

closed

PageRepository PageRepository_hidDelWhere cache should consider more attributes

Added by Oliver Hader almost 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2020-05-18
Due date:
% Done:

0%

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

Description

Looking into PageRepository::enableFields reveals that the cache-identifier probably should have more information, e.g. some "state-hash" of the currently applied Context.

Currently considered

  • show-hidden - context:visibility/includeHiddenPages
  • workspace ID - context.workspace.id

Probably not considered

  • starttime/endtime - context:date/accessTime
  • fe_group - context:frontend.user/groupIds (has it's own cache - but does not modify PageRepository_hidDelWhere cache identifier)
    • not affected, since excluded with $ignore_array in init method

Expected impact

Using PageRepository without taking these two additional aspects into account, it might happen that invoking PageRepository multiple times with different contexts (having different aspects for date and frontend.user) leads to unexpected results - basically, the first PageRepository invocation defined the where clause.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #91208: Performance issue in PageRepository for Mega MenusClosedStefan Froemken2020-04-27

Actions
Actions #1

Updated by Oliver Hader almost 4 years ago

  • Related to Bug #91208: Performance issue in PageRepository for Mega Menus added
Actions #2

Updated by Oliver Hader almost 4 years ago

  • Description updated (diff)
Actions #3

Updated by Benni Mack almost 4 years ago

  • Status changed from New to Rejected

won't fix.

Actions

Also available in: Atom PDF