Bug #91902

Story #92091: PageTree related flaws TYPO3 v9.5.20/21-dev or v10.4.6/7-dev

Page tree not expanding deeper from initial view for editors

Added by Borisz Novak 11 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Pagetree
Target version:
-
Start date:
2020-07-30
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
pending-close
Complexity:
Is Regression:
Yes
Sprint Focus:

Description

Initial view for editors is loaded fast, but expending any deeper by clicking on triangle does nothing. Editor must click on refresh button in top right corner of page tree, only then are pages show.


Related issues

Related to TYPO3 Core - Epic #88474: Page tree performance in 9.5Closed2018-11-16

Actions
Related to TYPO3 Core - Bug #91878: Fatal error in pagetree 9.5.20Closed2020-07-28

Actions
#1

Updated by Oliver Hader 11 months ago

  • Related to Epic #88474: Page tree performance in 9.5 added
#2

Updated by Oliver Hader 11 months ago

  • Related to Bug #91878: Fatal error in pagetree 9.5.20 added
#3

Updated by Oliver Hader 11 months ago

  • Category changed from Backend User Interface to Pagetree
#4

Updated by Sybille Peters 11 months ago

I can't reproduce this. It is working fine on my site 9.5.20 with either admin user or other user (via switch to user).

When clicking on triangle, the subpages are shown.

Did you recently update? Did you clear browser cache?

#5

Updated by Danilo Caccialanza 11 months ago

It happened to me too. But I solved it go to "Maintenace -> Reset Backend user preferences".

#6

Updated by Borisz Novak 11 months ago

Danilo Caccialanza wrote:

It happened to me too. But I solved it go to "Maintenace -> Reset Backend user preferences".

Solved the issue for me too.

#7

Updated by Peter Kraume 11 months ago

I can confirm this issue! But we have this problem only in one of our many 9.5 installations (production and dev).

Resetting backend user preferences did not help me!

As far as I can tell from a first glance, the Ajax request to update the page tree is not issued.
In a working installation, when I hit the triangle icon, a request like typo3/index.php?route=/ajax/page/tree/fetchData&token=b86ca9c94af1c31540432bde249d8e58ec603823 is issued.
But the second Ajax request to update the usersettings is sent and working.
The console shows no JavaScript errors nevertheless.

#8

Updated by Sybille Peters 11 months ago

Peter

But we have this problem only in one of our many 9.5 installations (production and dev).

"One of our many" means the problem happens only in one installation and the others are fine? What about in 10?

Can you reproduce this in other browsers?

I tested the initial patch and release 9.5.20 and 10.4.6 on several test sites and in production as admin users and with other users (switch user). Not once did I get the error. Used Browser Chromium (mostly) and Firefox on client Linux.

As far as I can tell from a first glance, the Ajax request to update the page tree is not issued.
...
The console shows no JavaScript errors nevertheless.

That is very helpful. When I click on the error I can see 2 events sent in the JavaScript console:

  • /ajax/page/tree/fetchData ...
  • /ajax/usersettings/process ...

I assume, the problem lies somewhere in JavaScript, see (the 9.5 version): https://review.typo3.org/c/Packages/TYPO3.CMS/+/65027/3/typo3/sysext/backend/Resources/Public/JavaScript/PageTree/PageTree.js#305

Would be cool if someone could debug this further. You could do that by setting a breakpoint etc.
and either track down the error ...

Or track down how to reproduce the error or what is different with the sites (or sites and client combinations) where it occurs and the sites where it does not.


I think, for now, it would be very helpful to find the cause (rather than fix it on site, e.g. by resetting user preferences), I think. That way it can be "really" fixed in the core. So if you can fix it by resetting your user preferences, please make sure you save the current state first so you can reproduce and analyze later.


This seems too easy to be the solution, but just to leave nothing untried: When testing I did not get a JavaScript file reloaded, even after doing a relogin and CTRL-SHIFT-r after "Clear cache" in maintenance. The file was typo3/sysext/backend/Resources/Public/JavaScript/PageTree/PageTree.js

So, can you test with different browser with cache cleared, private browsing window or other and reproduce it or not?

#9

Updated by Peter Kraume 11 months ago

I've tested only with TYPO3 9.5.20.
The problem occurs in any browser, regardless of cache state.
I'll try to dig in further, but I'm not a JavaScript specialist.

#10

Updated by Oliver Hader 10 months ago

  • Parent task set to #92091
#11

Updated by Oliver Hader 10 months ago

  • Status changed from New to Needs Feedback
  • Is Regression set to Yes

Peter, is there a chance that you could please test that again with the current 9.5 branch from Git? Thx in advance!

#12

Updated by Peter Kraume 9 months ago

Sorry for the late test. I've just installed TYPO3 9.5.21 and the problem persists. Exactly the same behaviour as with TYPO3 9.5.20.

#13

Updated by Oliver Hader 9 months ago

Had a short screen sharing session with Peter (thx for providing insights).
Currently it does not seem to be related to the core, but to how JavaScript assets were exposed/published on the server...

#14

Updated by Peter Kraume 9 months ago

Big kudos to Oliver Hader for the support! It turned out that we messed up our installation which used helhum/typo3-secure-web. Most probably the instance was copied without preserving symlinks. With that, the core files existed twice in public and private. With a TYPO3 update, only private was updated and public still had the old assets.

#15

Updated by Oliver Hader 9 months ago

  • Tags set to pending-close
#16

Updated by Oliver Hader 9 months ago

  • Status changed from Needs Feedback to Closed

Received report, that previous issues are now fixed with TYPO3 v9.5.21.

Also available in: Atom PDF