Bug #88083: ContentObjectRenderer::getTreeList isn't aware of Workspace/NonCacheRequests and expires not respected / mishandled - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #88083

closed

ContentObjectRenderer::getTreeList isn't aware of Workspace/NonCacheRequests and expires not respected / mishandled

Added by Alexander Opitz over 5 years ago. Updated 9 days ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Frontend

Target version:

Start date:

2019-04-04

Due date:

% Done:

Estimated time:

TYPO3 Version:

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

This issue seams very old, didn't found a report yet.

Multiple issues in the tree implementation:

If the tree between LIVE and a WS differs (maybe you hide a page in the tree line)
- First page request on LIVE => tree is wrong for WS (You may show to much)
- First page request is BE user in WS => tree is wrong for LIVE (maybe you hide an element in WS it gets invisible in LIVE)

If no cache entry exists, all data from a FE request is saved as "Expires never" but what is with pages which have a start-/endtime? This isn't respected while generating the treelist.
If a cache entry exists, and a page gets in BE changed endtime (not for starttime) then setCacheExpiration in TreelistCacheUpdateHooks should be called (works as expected) but the expire time is also set regardless if already a lower expire time exists.
If a cache entry exists, and a page gets in BE changed starttime cache is cleared for this pid.

Set to TYPO3 Version 8, as analyzed on this, but the issues may be older.

BTW: The functionality isn't splited in caching and treelist generating

Hard to read/understand
Not useable without caching

Related issues 2 (0 open — 2 closed)

Actions

Copy link

Updated by Alexander Opitz over 5 years ago

Description updated (diff)

Actions

Copy link

Updated by Susanne Moog over 5 years ago

Category changed from Frontend to Workspaces

Actions

Copy link

Updated by Susanne Moog over 5 years ago

Category changed from Workspaces to Frontend
Status changed from New to Needs Feedback

Category is hard to say ;) Maybe `Workspaces`, too. Did you by chance analyze whether this still happens in v9 with the newly introduced context?

Actions

Copy link

Updated by Alexander Opitz about 5 years ago

@Susanne Yes, I checked this also with v9LTS and master, the hash is calculated with following array

$parameters = [
    $id,
    $depth,
    $begin,
    $dontCheckEnableFields,
    $addSelectFields,
    $moreWhereClauses,
    $prevId_array,
    GeneralUtility::makeInstance(Context::class)->getPropertyFromAspect('frontend.user', 'groupIds', [0, -1])
];

Actions

Copy link

Updated by Alexander Opitz about 5 years ago

Status changed from Needs Feedback to New

Actions

Copy link

Updated by Benni Mack over 4 years ago

Related to Task #70903: Refactor "getTreeList" functions / add utility function added

Actions

Copy link

Updated by Gerrit Code Review over 4 years ago

Status changed from New to Under Review

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/63916

Actions

Copy link