Bug #69068

Workspace not opening page tree

Added by Rhodri Jones about 4 years ago. Updated 7 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Workspaces
Target version:
-
Start date:
2015-08-14
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
5.5
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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.


Related issues

Related to TYPO3 Core - Task #69439: Enhance SQL query reduction in page tree in workspaces Closed 2015-08-31

History

#1 Updated by Oliver Hader almost 4 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...

#2 Updated by Michael Voehringer almost 4 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`)
;

#3 Updated by Oliver Hader almost 4 years ago

Give the patch in #69439 a try...

#4 Updated by Benni Mack over 3 years ago

  • Status changed from Needs Feedback to Resolved

Fixed in master

#5 Updated by Tobias Gaertner about 1 year ago

Can anybody say in which versions of TYPO3 this is fixed? Have the problem still in 7.6.29.

#6 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

#7 Updated by Philipp Kitzberger 7 months 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

Also available in: Atom PDF