TYPO3 Core

Two idéas :

If i remember well, the 4.5 -> 6.2 team already addressed a similar issue and worked on the pagetree performance. It's probably a regression.

Other thing, maybe we could remove the loading animation would immediatly solve the bug as the 7.X version is doing the action in the background and nobody complained ?

I have a large and deeply nested page tree. I want to install it in Typo9.5.

You could build the page tree asynchronously as in the previous Typo3 version. There, my page tree is quickly set up using the getNextTreeLevel method.

related question: https://stackoverflow.com/questions/56628254/how-can-the-typo3-backend-page-tree-be-constructed-asynchronously-in-typo3-v9-x

With #90104 and #90105 I managed to reduce the loading time for a full page tree (refresh tree button) with 11000 pages by 60%.

I can add some investigation on that issue I think.

Setup¶

• TYPO3 v9.5.13 and for testing switched to 9.5.14-dev, all results remain the same.
• About 23k entries in pages table.
• Normally there is "be_acl" loaded and used, for investigation deactivated the extension.
• There are granular permissions set normally, to find an error all pages got an owner (we call him "owner") and is assigned to group "editors" with the permission bits: user 31, group 1, all 1.
• All editors have the root page as mount point and additional mount points for pages where they have write access. Everything else is read-only... "Page show" for them.

Problem¶

• "owner": no page tree
• any "editors": no page tree

As administrator there is no problem, page tree loads immediately.

Ideas for solving - tried patches¶

https://review.typo3.org/c/Packages/TYPO3.CMS/+/62904 and https://review.typo3.org/c/Packages/TYPO3.CMS/+/62868 (same content?)
https://review.typo3.org/c/Packages/TYPO3.CMS/+/62867
https://review.typo3.org/c/Packages/TYPO3.CMS/+/62086

Some looks in the code behind¶

typo3/sysext/backend/Classes/Controller/Page/TreeController.php (approx line 671)

Changing

$entryPoint = $repository->getTree($entryPoint, function ($page) use ($backendUser) {
// check each page if the user has permission to access it
return $backendUser->doesUserHaveAccess($page, Permission::PAGE_SHOW);
});

$entryPoint = $repository->getTree($entryPoint, function ($page) use ($backendUser) {
// check each page if the user has permission to access it
return true;
});

Digged a bit deeper and found the point where it may ends, but as far as i Know that is already known.

typo3/sysext/core/Classes/Authetication/BackendUserAuthentication.php (approx line 671)

if ($id > 0) {
        $wM = $this->returnWebmounts();
        $rL = BackendUtility::BEgetRootLine($id, ' AND ' . $readPerms);
        foreach ($rL as $v) {
        if ($v['uid'] && in_array($v['uid'], $wM)) {
           return $v['uid'];
        }
    }
}

As far as i can see for all 23k pages the complete rootline is loaded. I figured out that one number can change everything. But at that point I am out, I have no idea to "fix" it.

typo3/sysext/backend/Classes/Utility/BackendUtitlity.php (approx line 383)

    $output = $beGetRootLineCache[$ident];
} else {
    $loopCheck = *100*;
    $theRowArray = [];
    while ($uid != 0 && $loopCheck) {

Changing following let me load an incomplete page tree in a normal time.

    $output = $beGetRootLineCache[$ident];
} else {
    $loopCheck = *3*;
    $theRowArray = [];
    while ($uid != 0 && $loopCheck) {

May this helps.

I'm currently upgrading an 8.7 instance to version 10.2 and I'm also experiencing the described performance issues with the page tree.
I have a page tree with ~11k pages with a max nesting level of 7 levels.

Even with the applied patch of https://review.typo3.org/c/Packages/TYPO3.CMS/+/62086 the page tries to validate the permissions of every page.

After debugging a bit I could find out that my setup obviously completely bypass the "load pages on demand solution".

/**
 * Returns JSON representing page tree
 *
 * @param ServerRequestInterface $request
 * @return ResponseInterface
 */
public function fetchDataAction(ServerRequestInterface $request): ResponseInterface
{
    $this->initializeConfiguration();

    $items = [];
    if (!empty($request->getQueryParams()['pid'])) {
        // Fetching a part of a page tree
        $entryPoints = $this->getAllEntryPointPageTrees((int)$request->getQueryParams()['pid']);
        $mountPid = (int)($request->getQueryParams()['mount'] ?? 0);
        $parentDepth = (int)($request->getQueryParams()['pidDepth'] ?? 0);
        $this->levelsToFetch = $parentDepth + 2;
        foreach ($entryPoints as $page) {
            $items = array_merge($items, $this->pagesToFlatArray($page, $mountPid, $parentDepth));
        }
    } else {
        $entryPoints = $this->getAllEntryPointPageTrees();
        foreach ($entryPoints as $page) {
            $items = array_merge($items, $this->pagesToFlatArray($page, (int)$page['uid']));
        }
    }

    return new JsonResponse($items);
}

In my setup the condition "!empty($request->getQueryParams()['pid'])" is always false, which leads to a loading of the entire pagetree. I don't know when the parameter "$request->getQueryParams()['pid']" is set.

I can provide some details to the setup which we are using:

• We have only ONE mount point for all users. They all start at a root page.
• To restrict access to certain subpages, we configure the visibility for certain pages via the access module only for a defined group
• User who should "see" a page, are member of one or more groups.

I don't know if the "one mount point for all" setup is exotic, but this worked for us for many years in a bunch of projects.

Please comment your findings about a certain patch directly on Gerrit to the code. Thanks.

"one mount point for all" is definitely not exotic.

@Uwe
Did you make sure your browser is not caching the JS files?
The JS prt was modified to pass the pid param.
Please ensure you see the changed js file in your browser.

Sorry, I was not at the office yesterday.
I just "moved" my comment to gerrit. Thanks for your responses so far.