Bug #104376
open
Unable to create folder in multi-site Typo3 installation
Added by Albert van der Veen 4 months ago.
Updated 4 months ago.
Tags:
filelist, create folder
Description
In a Typo3 installation containing 17 sites, it's only possible to create folders via the filelist module if I'm logged in via one particular domain. Any other domain I use to login to Typo3, will give the error 'Element browser with identifier is not registered.' when clicking on 'Create folder'.
This error is triggered because $this->mode is empty in typo3/cms-backend/Classes/Controller/ElementBrowserController.php on line 67.
Debugging $request->getQueryParams() in function mainAction in the same class, shows that this array only has the element 'token' in it when causing the error. When not causing an error it also has the elements 'expandFolder' (which has as value the folder under which a new one will be created) and 'mode' (which has the value 'create_folder').
I can't confirm this behavior. Tested in multi-domain setup with 5 sites/domains. TYPO3 12.4.17
I logged in to the backend with all 5 domains, and can create folders in the filelist. In my setup there are 6 file storages and i can create folders in each storage with each logged in domain.
- Status changed from New to Needs Feedback
are you using latest 12 version?
Also; what's the difference between the domains? Some kind of redirect? CSP config? Some PHP session locking or so? What does the browser network panel say, do the requests get blocked/redirected?
Am using latest Typo3 12 version, 12.4.17.
The domains all have a similar configuration, no session locking, redirect and no CSP used. No requests get blocked, as internal Typo3 logic doesn't fill the required array elements, as stated in my original post, so a Typo3 error is generated by /cms-backend/Classes/Controller/ElementBrowserController.php, when trying to create a folder.
I think we need to pinpoint here why it works for you on one domain and not the others. The Backend is domain agnostic and should work on any host that is connected to the same documentyroot.
If its really not hosting setup related, I can only think of some condition in the page TSConfig that is loaded, maybe some request() condition mapped to a single domain only... but that shouldn't affect the queryParms object.
How can we reproduce this?
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by