Project

General

Profile

Actions

Bug #103150

closed

After Update to 11.5.35 -> Call to a member function getStorage() on bool | Error thrown in file ...FileLinkHandler.php

Added by Peter Grave 10 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2024-02-19
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After the update from 11.5.34 to 11.5.35 we get the following error when trying to create a textlink to a file in the Text & Media element:
Core: Exception handler (WEB): Uncaught TYPO3 Exception:
Call to a member function getStorage() on bool | Error thrown in file /var/www/public/typo3/sysext/recordlist/Classes/LinkHandler/FileLinkHandler.php in line 126

The error occurs with backend editors, not with the admin account.


Files

error.jpg (39.4 KB) error.jpg Peter Grave, 2024-02-19 08:16

Related issues 1 (0 open1 closed)

Is duplicate of TYPO3 Core - Bug #103116: Oops, an error occurred! Call to a member function getStorage() on boolClosed2024-02-14

Actions
Actions #1

Updated by Benjamin Robinson 10 months ago

I can confirm the error. I have exactly the same problem with an 11.5.35. However, I have a second 11.5.35 TYPO3 where the problem does not occur. Unfortunately, I have not yet found the decisive difference between the two systems.

Actions #2

Updated by Andreas Kienast 10 months ago

  • Is duplicate of Bug #103116: Oops, an error occurred! Call to a member function getStorage() on bool added
Actions #3

Updated by Andreas Kienast 10 months ago

  • Status changed from New to Closed

Thank you for your report. This issue was reported previously with https://forge.typo3.org/issues/103116 and handled as such. Therefore, I'll close this ticket as a duplicate.

Kind regards
Andreas

Actions #4

Updated by Benjamin Franzke 10 months ago ยท Edited

@Benjamin Robinson

can you confirm that the installation where the issue exists does not have 1:/user_upload mounted for editors, while the installation where the error does not happen does provides access to 1:/user_upload for editors?

Actions #5

Updated by Benjamin Robinson 10 months ago

Benjamin Franzke wrote in #note-4:

@Benjamin Robinson

can you confirm that the installation where the issue exists does not have 1:/user_upload mounted for editors, while the installation where the error does not happen does provides access to 1:/user_upload for editors?

No, in both installations editors don't have access to user_upload. But the installation with the issue has a user-TSconfig
options.defaultUploadFolder = 1:media/
The problem could have been that the editors don't have access to this default folder. This is now solved with the patch https://forge.typo3.org/projects/typo3cms-core/repository/1749/revisions/de0f48a7099fb320c50fd4635e11c1e4015690d9

Actions #6

Updated by Benjamin Franzke 10 months ago

@Benjamin Robinson

Thanks for the verification.
One last question to fully understand your case: I assume the editors do not have access to the configured folder 1:/media, right?

In that case the InsufficientFolderAccessPermissionsException would be triggered but not catched in https://github.com/TYPO3/typo3/blob/11.5/typo3/sysext/core/Classes/Authentication/BackendUserAuthentication.php#L1684-L1690 and thus no upload folder would be found (the alternatives that are resolved when the folder is missing are skipped in that case).
That explains how getSelectedFolder ended up returning false.

(Note: The fix you already verified is fine and sufficient and will soon be released, I just think we got a secondary issue here regarding correct behaviour here: inhomogeneous handling where defaultUploadFolder does not exist vs no permission)

Actions #7

Updated by Benjamin Robinson 10 months ago

Benjamin Franzke wrote in #note-6:

One last question to fully understand your case: I assume the editors do not have access to the configured folder 1:/media, right?

Yes, that's exactly how it is, the editors do not have access to the configured folder 1:/media

I didn't want the editors to upload files to user_upload in an unsorted and careless manner, but to put a little more effort into the directory structure. I overlooked the fact that they do not have access to 1:/media, but only to their own individual subdirectory.

Actions

Also available in: Atom PDF