Workspace very slow loading page tree
I wish that i'm posting in the right place for this issue that i have, with my team we have just upgraded from 4.6 to 6.2 Since then editors have major performance issues in the typo3 backend.
They get a lot of timeouts when trying to open pages in the backend ("Connection Problem Sorry, but an error occurred while connecting to the server. Please check your network connection.")
It takes sometimes up to 5 minutes until the page tree is opened.
We saw the the request to typo3/ajax.php?ajaxID=ExtDirect::route&namespace=TYPO3.Components.
PageTree really takes a long long time, get´s timeouts or even responds with 500.
Basically the backend becomes impossible to work in.
i think the problem is realated to the TYPO3\CMS\Workspaces\ExtDirect\AbstractHandler.
File : AbstractHandler.php
92 : $versions = $this->getWorkspaceService()->selectVersionsInWorkspace($this->getCurrentWorkspace(), 0,
99, -1, 0, 'tables_select', $this>validateLanguageParameter($parameters));
Any body can help me on this ?
Thanks in advance.
Updated by TSniper no-lastname-given over 6 years ago
Here the message from firebug console :
Updated by Martin Tepper over 6 years ago
Maybe this fix will solve it.
Could you check it please?
Related to https://forge.typo3.org/issues/61184
Updated by Grigori Prokhorov over 6 years ago
Martin Trepper's patch from comment #66231-2 does in fact resolve the issue.
The only issue I have with the patch is that it drops the second part of the workspace record check, i.e. the WHERE-clause includes
'A.pid=-1' . ' AND A.t3ver_wsid=' . $workspaceId . ' AND A.t3ver_oid=B.uid' . BackendUtility::deleteClause($tableName, 'A') . BackendUtility::deleteClause($tableName, 'B')
what for tt_content translates to
SELECT B.uid as live_uid, B.pid as live_pid, A.uid as offline_uid FROM tt_content as A, tt_content as B WHERE A.pid = -1 AND A.t3ver_wsid = ###WORKSPACE_ID### AND A.t3ver_oid = B.uid AND A.deleted = 0 AND B.deleted = 0
but drops the part
A.t3ver_oid = B.uid AND A.t3ver_state<>4 OR A.t3ver_oid=B.t3ver_move_id AND A.t3ver_state=4
This means that the versioning state is not regarded at all, although it's not quite clear to me why it should have been regarded in the first place since an editor can not select the versioning state when looking at the page tree anyway.
I am therefore "+1"-ing the solution proposed in #66231 to be included into the core as a proper fix for this issue.
Updated by Sara no-lastname-given about 6 years ago
We've tried this fix but it just breaks the website.
Need to go live at the end of this week so if anyone has any ideas on fixing this problem I'd be very grateful!
A new ticket has been opened detailing the problems we're having https://forge.typo3.org/issues/69068