Bug #91432

PageRepository PageRepository_hidDelWhere cache should consider more attributes

Added by Oliver Hader about 2 months ago. Updated about 2 months ago.

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

0%

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 Menus Closed 2020-04-27

History

#1 Updated by Oliver Hader about 2 months ago

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

#2 Updated by Oliver Hader about 2 months ago

  • Description updated (diff)

#3 Updated by Benni Mack about 2 months ago

  • Status changed from New to Rejected

won't fix.

Also available in: Atom PDF