Project

General

Profile

Actions

Bug #87475

closed

Filelist error - RootllineUtility tries to fetch deleted page by sys_file_storage UID

Added by Reinhard Schneidewind over 5 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2019-01-18
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When accessing the filelist an error is thrown:

#1343589451 TYPO3\CMS\Core\Exception\Page\PageNotFoundException
Could not fetch page data for uid 2.

typo3_src-9.5.3/typo3/sysext/core/Classes/Utility/RootlineUtility.php line 262

As far as I can see the RootlineUtility tries to fetch the page data by the sys_file_storage uid.
In my case the uid is 2. Furthermore a page with uid 2 exists, but is deleted. This causes the error to be thrown.

The problem is caused by the GET parameter id:
example.com/typo3/index.php?route=%2Ffile%2FFilelistList%2F&token=TOKEN&id=2%3A%2Fapplikationen%2F

The RootlineUtility seems to interpret the id always as pid, even it's the sys_file_storage in that case.


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #93395: module shows PageNotFoundException in BEClosed2021-02-01

Actions
Actions #1

Updated by David Backes over 5 years ago

Reinhard Schneidewind wrote:

When accessing the filelist an error is thrown:

[...]

As far as I can see the RootlineUtility tries to fetch the page data by the sys_file_storage uid.
In my case the uid is 2. Furthermore a page with uid 2 exists, but is deleted. This causes the error to be thrown.

The problem is caused by the GET parameter id:
example.com/typo3/index.php?route=%2Ffile%2FFilelistList%2F&token=TOKEN&id=2%3A%2Fapplikationen%2F

The RootlineUtility seems to interpret the id always as pid, even it's the sys_file_storage in that case.

Same Issue here, couldn't open any directory in Filelist, same Errormessage as shown above.

Backround: During an update from older Typo3 to the new 9 Version I did copy the whole Pagetree and deleted the old one and cleard the database. So the page with Uid 1 was completly gone.

Workaround: I created a new page, and set the UID manually via database to 1, now everythings works fine, even when I set the Page with uid to deleted=1, and why ever, even after I deleted the page from database again.

It also works after I removed the t3boostrap-Extension, because the Error Trace shows a Problem in an User Condition used in the t3bootstrap part of Typoscript Rendering. This User Condition uses the function from RootlineUtility from core and this produce the error as Reinhard Schneidewind wrote above.

I am not sure if the error is from t3boostrap, or core or if ther just was some strange cache behaviour tricks me.

I cannot reproduce the error, t3boostrap is active like before and the page with Uid 1 doesn't exists. I know it sounds weird, but if the error returns I will post the trace here.

Actions #2

Updated by David Backes over 5 years ago

UPDATE:

We need a page with the same Uid as the Filestorage, otherwise the error occures again after a couple of hours.

Actions #3

Updated by Riccardo De Contardi almost 5 years ago

  • Status changed from New to Needs Feedback

Can the issue be reproduced with just TYPO3 Core or do I need to install t3bootstrap? Or another extension can trigger the issue?

I tried to reproduce it with the following steps:

- TYPO3 9.5.7
- I deleted my page with UID=2 (I even deleted it from the database)
- I created a FILEADMIN-2 File Storage that has UID=2 and points to a ./fileadmin-2/ folder
- I created inside it an Images folder
- I created a new filemoint to ./fileadmin-2/Images

So far, I was not able to experience the issue using

- the filelist module
- using text/w images content element
- using filelinks content element

Actions #4

Updated by Ronald Wopereis over 4 years ago

I had the same problem.
My solution was to update the uid in table sys_file_storage to the value of rootPageId (click on Sites in the backend menu to view the rootPageId)

Actions #5

Updated by Susanne Moog about 4 years ago

If this error still occurs: Can somebody please attach a stack trace of the error?

Actions #6

Updated by Susanne Moog about 4 years ago

  • Category set to File Abstraction Layer (FAL)
Actions #7

Updated by Riccardo De Contardi almost 4 years ago

  • Status changed from Needs Feedback to Closed

No feedback since the last 90 days => closing this issue.

If you think that this is the wrong decision or experience the issue again and have more information about how to reproduce your problem, please reopen it or open a new issue with a reference to this one.

Thank you and best regards

Actions #8

Updated by David Menzel over 3 years ago

  • Related to Bug #93395: module shows PageNotFoundException in BE added
Actions #9

Updated by Christian Reiter 4 months ago

Currently encountering this in TYPO3 12.4.10

In the TYPO3 site, page ID=1 does not exist, rootpage is page uid = 320. fileadmin default storage is sys_file_storage uid = 1

while trying to install an extension that has a backend module associated to File > list this issue appears.

The error is thrown before the controller of the extension is ever even called. So its not a problem inside the ext.

If the File module is called with querystring ?id=320:/user_upload/, (a nonexistent storage id, that however exists as a page)
then the extension is correctly called,
and the controller of the extension reports that this is not a valid storage (correct and expected behavior)

If the File module is called with ?id=1:/user_upload/,
the controller is never reached,
because beforehand the core looks for a TypoScript setup for page id = 1 and to do that it tries to follow a rootline.

This happens starting from TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager::getExtbaseConfiguration > getTypoScriptSetup > getCurrentPageId > getCurrentPageIdFromRequest and that's where $request->getQueryParams()['id'] is returned, which gets used as a rootline origin, and not a storage id.

This however only happens if the condition if ($module instanceof ExtbaseModule) { ...} is fulfilled in TYPO3\CMS\Extbase\Mvc\Web\RequestBuilder::build

Since the TYPO3\CMS\Filelist\Controller\FileListController isn't an ExtbaseModule it doesn't happen there?

But it seems for any ExtbaseModule to work with the file tree, it is a requirement to have a storage uid that also exists as a page uid?

Everything works if either I just insert a page with ID=1, or alter the ID of the default fileadmin storage to that of an existing page (such as, 320).
Then the call to fetch a Typoscript setup doesn't cause the exception and the request is passed on to the controller of the ExtbaseModule.

Actions #10

Updated by Christian Reiter 4 months ago

  • TYPO3 Version changed from 9 to 12
  • PHP Version changed from 7.2 to 8.1
Actions

Also available in: Atom PDF