Bug #91432

PageRepository PageRepository_hidDelWhere cache should consider more attributes

Added by Oliver Hader 12 months ago. Updated 12 months 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

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

Actions
#1

Updated by Oliver Hader 12 months ago

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

Updated by Oliver Hader 12 months ago

  • Description updated (diff)
#3

Updated by Benni Mack 12 months ago

  • Status changed from New to Rejected

won't fix.

Also available in: Atom PDF