Bug #69068
closed
Workspace not opening page tree
0%
Description
Hi everyone,
We're currently upgrading our Typo3 site from 4.6.18 to 6.2.14, the upgrade has been successful. We've upgraded extensions and managed to get the site working and up and running. However, when changing Workspaces to our draft workspace of the site, the page tree fails to load.
Our issue is identical to the problem in the following ticket, (https://forge.typo3.org/issues/66231), and we've attempted the patch fixes suggested, but this only caused major PHP errors which broke the entire site. I'll reproduce the PHP errors and add them to the ticket.
We're running this on a 64 bit RHEL6 Virtual Machine, with version 5.5.27 of PHP.
Anyone have any more ideas of what we could try?
Thanks all in advance.
Updated by Oliver Hader over 8 years ago
- Status changed from New to Needs Feedback
Can you please provide the PHP errors that occur on your side?
Concerning performance there's a follow-up in https://review.typo3.org/#/q/I119a79d8fad82b0dc5891861af45ecfdbc681820,n,z - the change-set that got merged in July 2015 unfortunately has been lying around for two years then...
Updated by Michael Voehringer over 8 years ago
Hi Rhodri,
we have the same error after updating from 4.2 to 6.2. Looks like an SQL query takes very very long.
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=2 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 GROUP BY live_pid
We have fixed it by adding some extra indexes to the tt_content table:
ALTER TABLE `tt_content` ADD INDEX `pid` (`pid`), ADD INDEX `t3ver_wsid` (`t3ver_wsid`), ADD INDEX `t3ver_state` (`t3ver_state`), ADD INDEX `t3ver_move_id` (`t3ver_move_id`) ;
Updated by Benni Mack about 8 years ago
- Status changed from Needs Feedback to Resolved
Fixed in master
Updated by Anonymous over 5 years ago
Can anybody say in which versions of TYPO3 this is fixed? Have the problem still in 7.6.29.
Updated by Philipp Kitzberger about 5 years ago
Thanks for the hint with the SQL indicies. Didn't make any difference though. So I've tried it with a combined index which boosted performance of said query (with TYPO3 8.7) by factor 20.000 or so. Instead of 45s it's only 0,00025s now ;-)
I've wrapped it into a tiny extension: https://packagist.org/packages/kitzberger/workspaces-boost
Maybe someone stumbles over this issue here and needs a quick solution for this.
Cheers, Philipp