Actions
Bug #91432
closedPageRepository PageRepository_hidDelWhere cache should consider more attributes
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 modifyPageRepository_hidDelWhere
cache identifier)- not affected, since excluded with
$ignore_array
ininit
method
- not affected, since excluded with
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.
Updated by Oliver Hader about 4 years ago
- Related to Bug #91208: Performance issue in PageRepository for Mega Menus added
Actions