Bug #91407

Pagetree not shown due to error in TYPO3\CMS\Backend\Controller\Page\TreeController

Added by Jessica Schlierenkamp 5 months ago. Updated 3 months ago.

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

0%

TYPO3 Version:
10
PHP Version:
7.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After updating to 9.5.17 the pagetree is no longer shown due to the following error:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: Cannot use object of type __PHP_Incomplete_Class as array | Error thrown in file typo3/sysext/backend/Classes/Controller/Page/TreeController.php in line 189

I could track the error down to the following:

$this->expandedState is an object but $this->expandedState->stateHash is not. Thus the condition in Line 186 results in false, leading to the assumption that $this->expandedState is an array. Which it is not and trying to retrieve stateHash via $this->expandedState['stateHash'] results in the mentioned error.

For my two systems removing is_object($this->expandedState->stateHash) from the condition worked but I have no idea whether this is a valid solution for everyone.

I'm guessing not, as the second part to the condition was added in https://github.com/TYPO3/TYPO3.CMS/commit/2a42940d6b21f9e134879c33b99a315953aa6742

Also, I have no idea why this issue didn't occur in versions between 9.5.1 and 9.5.17.

user-settings-tab.png View (36 KB) Oliver Hader, 2020-05-14 17:54

Error.png View - After switch to none-amidn-user (61.3 KB) Dirk Heyka, 2020-06-03 11:32


Related issues

Related to TYPO3 Core - Bug #89269: $GLOBALS['BE_USER']->uc sometimes wrongly written, gets a stdClass where an array would be expected Closed 2019-09-25
Related to TYPO3 Core - Task #91417: Add missing documentation for BackendUserConfigurationUpdate Closed 2020-05-16
Related to TYPO3 Core - Bug #91570: Pagetree not shown due to error in TYPO3\CMS\Backend\Controller\Page\TreeController New 2020-06-03

History

#1 Updated by Oliver Hader 5 months ago

Thanks for the report. At least __PHP_Incomplete_Class is a signal that previously that was a (insecure?!) deserialization.

In case an object cannot be deserialized (due to policy), the result would similar to this:

class __PHP_Incomplete_Class#2 (1) {
  public $__PHP_Incomplete_Class_Name =>
  string(8) "stdClass" 
}

Can you please mention the class name that is shown in your scenario (it's stdClass in the example above)? Thx in advance for your feedback!


I guess that those objects are left-overs from older TYPO3 versions which can be "purged" by resetting user-settings in corresponding module in edit and advanced functions tab. At the very end of that form there's the reset user settings to default state button.

#2 Updated by Oliver Hader 5 months ago

  • Status changed from New to Needs Feedback

#3 Updated by Michael Hitzler 5 months ago

Can confirm. Having currently 2 affected client systems 9.5.17 (all with a multi site setup) with described behaviour and some, but not all backend user (admin and regular editors) can't load page tree.

It's for sure related the user settings and resetting BE user settings solved the general issue as a quick fix.

So far I can say there is an issue in
$GLOBAL['BE_USER']['uc']['BackendComponents']['States']
all sub items (Pagetree, typo3-module-menu, typo3-navigationContainer) do have as a very first child an item of
"__PHP_Incomplete_Class_Name" = "stdClass"

As the values of $GLOBAL['BE_USER']['uc']['BackendComponents']['States'] get later mapped onto $this->expandedState['stateHash'] it causes the issue.

So quite sure it is a specific / maybe outdated user setting which causes the issue on deserialization.

OK, it seems to be already within the serialized back_users uc value in the database. Here you can see the relevant part of BackendComponents:
a:1:{s:6:"States";a:1:{s:8:"Pagetree";O:8:"stdClass":1:{s:9:"stateHash";O:8:"stdClass":3:{s:1:"0";i:1;s:4:"root";i:1;s:16:"lastSelectedNode";s:2:"p0";}}}}

This value is the uc part of an affected backend user untouched (not logged in after update, not simulated by an admin).

Hope this helps!

#4 Updated by Hartmut Steglich 5 months ago

Having the same problem

clearing be user preferences multiple times with relogin did help

updated TYPO3 9.5.13 -> 9.5.17

we have multiple sites (pages with is_siteroot in folders below root page)

maybe related to https://forge.typo3.org/issues/91221 ?

#5 Updated by Michael Hitzler 5 months ago

As far as I can see there is already a solution within the install tool in class BackendUserConfigurationUpdate.
This seems to address exactly the issue.

Not quite sure in which version the additional migration task has been added, but it helps you solving the issue system wide.

Just got to module Admin Tools -> Update and select Update Wizard.
There you should see a new, not yet executed migragtion task:
Update backend user configuration array
The backend user "uc" array, which is persisted in the db, now only allows for arrays inside its structure instead of stdClass objects. Update the uc structure for all backend users.

Execute this migration task and your BE users will be updated and have a sane uc configuration in the end.

Problem solved and page tree can be loaeded again.

PS: An offical public note somewhere to this migration task would be highly recommended.

#6 Updated by Gerrit Code Review 5 months ago

  • Status changed from Needs Feedback to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64496

#7 Updated by Oliver Hader 5 months ago

  • Related to Bug #89269: $GLOBALS['BE_USER']->uc sometimes wrongly written, gets a stdClass where an array would be expected added

#8 Updated by Oliver Hader 5 months ago

  • Status changed from Under Review to Needs Feedback

Dropping the provided patch in favour of the existing upgrade wizard in TYPO3 v9 and v10 as mentioned by Michael in https://forge.typo3.org/issues/91407#note-5

Please report back if the mentioned approach via that upgrade wizard solves the issue - if it does not, please provide additional details, what's still missing.

#9 Updated by Oliver Hader 5 months ago

  • Related to Task #91417: Add missing documentation for BackendUserConfigurationUpdate added

#10 Updated by Oliver Hader 5 months ago

Added missing documentation for mentioned upgrade wizard in issue #91417

#11 Updated by Jessica Schlierenkamp 5 months ago

Oliver Hader wrote:

Dropping the provided patch in favour of the existing upgrade wizard in TYPO3 v9 and v10 as mentioned by Michael in https://forge.typo3.org/issues/91407#note-5

Please report back if the mentioned approach via that upgrade wizard solves the issue - if it does not, please provide additional details, what's still missing.

Worked for me. Thanks a lot!

#12 Updated by Oliver Hader 5 months ago

Perfect & thanks for reporting back to us!

#13 Updated by Oliver Hader 5 months ago

  • Status changed from Needs Feedback to Closed

Closing this ticket for the time being. Feel free to reopen in case there are additions. Thx

#14 Updated by Dirk Heyka 5 months ago

  • File Error.png View added
  • Target version deleted (9.5.18 & 10.4.3)
  • TYPO3 Version changed from 9 to 10
  • PHP Version changed from 7.2 to 7.3

#15 Updated by Simon Gilli 5 months ago

  • Status changed from Closed to New

#16 Updated by Simon Gilli 5 months ago

  • Related to Bug #91570: Pagetree not shown due to error in TYPO3\CMS\Backend\Controller\Page\TreeController added

#17 Updated by Simon Gilli 5 months ago

  • Status changed from New to Closed

#18 Updated by Sebastian Lechenbauer 3 months ago

  • Duplicated by Bug #91878: Fatal error in pagetree 9.5.20 added

#19 Updated by Sebastian Lechenbauer 3 months ago

  • Duplicated by deleted (Bug #91878: Fatal error in pagetree 9.5.20)

#20 Updated by Sebastian Lechenbauer 3 months ago

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

#21 Updated by Oliver Hader 3 months ago

In order to reproduce this issue (in case it still exists), please provide more details from logs or for error notifications shown in the backend, please check the browser console, navigate to XHR requests in the network tab and check/paste their responses.

#22 Updated by Oliver Hader 3 months ago

  • Related to deleted (Bug #91878: Fatal error in pagetree 9.5.20)

Also available in: Atom PDF