Bug #77618
closedWorkspace PageTree can become super-slow
0%
Description
The PageTree in workspaces gets a different style for all pages, that contain changes. This is a helpful feature to quickly see, which pages have changes.
But with a larger TYPO3 installation this feature can become unusable and prevent the page tree from loading. This happens because for each page in the page tree and each table in the TCA a MySQL query is executed:
NumberOfPages * NumberOfTablesWithWorkspaceOverlay = NumberOfAdditionalQueries.
We have an installation with 22 Tables with workspace overlay: 10 Core-Tables, 1-Gridelements-Table, 5 Powermail-Tables, 6 Custom-Tables.
A problem might be, that we have ~30.000 content elements and the generated query tries to find which element is changed:
SELECT B.uid as live_uid, B.pid as live_pid, A.uid as offline_uid
FROM tt_content A,tt_content B
WHERE A.pid=-1 AND A.t3ver_wsid=1 AND (A.t3ver_oid=B.uid AND A.t3ver_state<>4 OR A.t3ver_oid=B.t3ver_move_id AND A.t3ver_state=4) AND A.deleted=0 AND B.deleted=0
Links to relevant code positions:
https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-10/typo3/sysext/backend/Classes/Tree/Pagetree/DataProvider.php#L175
https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-10/typo3/sysext/workspaces/Classes/ExtDirect/PagetreeCollectionsProcessor.php#L42
https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-10/typo3/sysext/workspaces/Classes/Service/WorkspaceService.php#L756
(Even though these links point to the classes for TYPO3 7 instead of 8, I believe the bug will also be present in TYPO3 8, because the queries stay the same)
Currently the page tree does not load at all. There is a timeout after 30 seconds and editors have to hope that the request finishes before. We just removed the workspace hook from
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/tree/pagetree/class.t3lib_tree_pagetree_dataprovider.php']['postProcessCollections']
Files