Bug #91407
closedPagetree not shown due to error in TYPO3\CMS\Backend\Controller\Page\TreeController
Added by Jessica Schlierenkamp over 4 years ago. Updated almost 3 years ago.
0%
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.
Files
user-settings-tab.png (36 KB) user-settings-tab.png | Oliver Hader, 2020-05-14 17:54 | ||
Error.png (61.3 KB) Error.png | After switch to none-amidn-user | Dirk Heyka, 2020-06-03 11:32 | |
no-pt.png (748 KB) no-pt.png | Dmitry Dulepov, 2022-01-27 11:14 |
Updated by Oliver Hader over 4 years ago
- File user-settings-tab.png user-settings-tab.png added
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.
Updated by Oliver Hader over 4 years ago
- Status changed from New to Needs Feedback
Updated by Michael Hitzler over 4 years 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!
Updated by Hartmut Steglich over 4 years 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 ?
Updated by Michael Hitzler over 4 years 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.
Updated by Gerrit Code Review over 4 years 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
Updated by Oliver Hader over 4 years ago
- Related to Bug #89269: $GLOBALS['BE_USER']->uc sometimes wrongly written, gets a stdClass where an array would be expected added
Updated by Oliver Hader over 4 years 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.
Updated by Oliver Hader over 4 years ago
- Related to Task #91417: Add missing documentation for BackendUserConfigurationUpdate added
Updated by Oliver Hader over 4 years ago
Added missing documentation for mentioned upgrade wizard in issue #91417
Updated by Jessica Schlierenkamp over 4 years 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!
Updated by Oliver Hader over 4 years ago
Perfect & thanks for reporting back to us!
Updated by Oliver Hader over 4 years 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
Updated by Dirk Heyka over 4 years ago
Updated by Simon Gilli over 4 years ago
- Related to Bug #91570: Pagetree not shown due to error in TYPO3\CMS\Backend\Controller\Page\TreeController added
Updated by Sebastian Lechenbauer over 4 years ago
- Has duplicate Bug #91878: Fatal error in pagetree 9.5.20 added
Updated by Sebastian Lechenbauer over 4 years ago
- Has duplicate deleted (Bug #91878: Fatal error in pagetree 9.5.20)
Updated by Sebastian Lechenbauer over 4 years ago
- Related to Bug #91878: Fatal error in pagetree 9.5.20 added
Updated by Oliver Hader over 4 years 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.
Updated by Oliver Hader over 4 years ago
- Related to deleted (Bug #91878: Fatal error in pagetree 9.5.20)
Updated by Martin Kutschker almost 4 years ago
Haha, happened just for me in a 10.4.13.
Cleared the user settings to get rid of the problem.
Updated by Franz Holzinger almost 3 years ago
- Priority changed from Should have to Must have
- PHP Version changed from 7.3 to 7.4
TYPO3 10.4.21
PHP 7.4.26
What must I do to get the page tree back?
Javascript Console:
Client.js?bust=1639669362:13 Uncaught (in promise) DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 't3-icon_registry_cache_identifier' exceeded the quota.
at set (http://neu.website.com/typo3/sysext/backend/Resources/Public/JavaScript/Storage/Client.js?bust=1639669362:13:216)
at http://neu.website.com/typo3/sysext/backend/Resources/Public/JavaScript/Icons.js?bust=1639669362:13:697
Updated by Dmitry Dulepov almost 3 years ago
It happens to me too in latest Safari (macOS Big Sur) in TYPO3 11.5. Sometimes I can get it back by reseting user settings. Sometimes I have to reset Safari. I could not find the exact way when it happens or how to fix it (different ways at different times). Last time it was after adding yubico MFA. Before it was after I worked with direct_mail. I remember it also happened after looking to BE users module. So no stable reason really.
I have the following error in JS console:
[Error] TypeError: null is not an object (evaluating 'this.container.querySelectorAll') show (NavigationContainer.js:13:1602) showComponent (NavigationContainer.js:13:526) t (ModuleMenu.js:13:6674) dispatchEvent (anonymous function) (Router.js:13:2193) dispatchEvent dispatch (Iframe.js:23:2287) _loaded (Iframe.js:23:2059) handleEvent (lit-html.js:6:7093) https://***.ddev.site/typo3/sysext/backend/Resources/Public/JavaScript/Viewport/NavigationContainer.js?bust=1643278740