TYPO3 Core

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.

UPDATE:

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

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)

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

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.