Project

General

Profile

Actions

Bug #96376

open

Link Browser (RTE and inputLink) and DefaultFactory creates user_upload folder even if uploads are diabled (and it creates it in a random storage)

Added by Stefan P over 2 years ago. Updated 11 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2021-12-17
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
Stabilization Sprint

Description

Steps to reproduce:
  • setup.default.edit_docModuleUpload = 0
  • setup.override.edit_docModuleUpload = 0
  • clear cache
  • clear UC cache

Expected: Link panel of an RTE does not show upload fields, only the file tree.

Actually happens: Link panel of an RTE does show upload fields, alongside the file tree.

Actions #1

Updated by Stefan P over 2 years ago

  • Subject changed from userTSconfig edit_docModuleUpload = 0 is not respected in RTE link panel to RTE link to file wizard creates user_upload folder even if uploads are diabled (and it creates it in a random storage)

Additonal information:

  • also set options.folderTree.uploadFieldsInLinkBrowser = 0

RTE link wizard does not allow uploads then - fine. But it still creates the user_upload folder! This seems to be caused by the fact that the upload renderer that renders this file selector already gets a FolderObject passed:
https://github.com/TYPO3/typo3/blob/f43979e74409500b731a98b39f978379669ed2e9/typo3/sysext/recordlist/Classes/View/FolderUtilityRenderer.php#L109

(which in turn invokes LocalDriver->getDefaultFolder() where user_upload is hardcoded)

What we try to achieve in the very end is to prevent the user_upload folder everyhwere. Because in our workflow the editors are forced to upload via file list module into normal folders and just reference files from there. Direct file uploads from sys_file_reference fields or RTE are disallowed everyhwere.

The next problem here is that the user_upload folder is created in the first Storage that the user has in his file list. Which does not make any sense at all. We have users with multiple storages with uid > 1 (so even none of them is "fileadmin"! These user don't see storage.uid=1 "fileadmin"). And just by opening the link wizard in an RTE creates the user_upload folder in the first displayed file storage! This does not make sense at all (even if uploads would be enabled -> maybe the user wants to upload to a different storage).

The user_upload folder should only ever be created if an actual upload happens!

Actions #2

Updated by Stefan P over 2 years ago

  • Category changed from RTE (rtehtmlarea + ckeditor) to File Abstraction Layer (FAL)
Actions #3

Updated by Stefan P over 2 years ago

  • Subject changed from RTE link to file wizard creates user_upload folder even if uploads are diabled (and it creates it in a random storage) to Link Browser (RTE and inputLink) creates user_upload folder even if uploads are diabled (and it creates it in a random storage)
Actions #4

Updated by Stefan P over 2 years ago

Also true for inputLink TCA fields, this is a common LinkBrowser problem.

Actions #5

Updated by Stefan P over 2 years ago

The Link Browser controller and Fluid Templates are totally fine without receiving a pre-selected folder.

But the BackendUserAuthentication accesses the FAL API (LocalDriver in the end), which has the creation of the user_upload folder hardcoded.

The only way to currently circumvent this would be to set options.defaultUploadFolder = x:/ - however x must be a uid of a storage. This is not possible if you have hundreds of BE users each having access to different sets of storage uids.

I see four approaches here:
  • Either make it valid to have no upload directory in the FAL API / LocalDriver (as said: for Link Browser this is already valid).
  • Provide a special key for the combined identifier to always pick the first storage of the current user, like options.defaultUploadFolder = first:/ which would select the root of first storage that the user has access to.
  • provide an Event before any calls to LocalDriver are done to be able to shortcut the creation of the user_upload folder
  • Make it possible to define a custom default upload fodler for the LocalDriver instead of teh hardcoded /user_upload/. For me it would be enough to set it to / (of the current storage).
Actions #6

Updated by Stefan P over 2 years ago

For the reference, I now workaround it like this:

<?php
declare(strict_types=1);

namespace MyVendor\MyProject\Patches\FalApi;

class LocalDriver extends \TYPO3\CMS\Core\Resource\Driver\LocalDriver
{
    public function getDefaultFolder(): string
    {
        return '/';
    }
}

And in LocalConfiguration.php :

'SYS' => [
    'fal' => [
        'registeredDrivers' => [
            'Local' => [
                'class' => \MyVendor\MyProject\Patches\FalApi\LocalDriver::class
            ]
        ]
    ]
]
Actions #7

Updated by Stefan P over 2 years ago

  • Subject changed from Link Browser (RTE and inputLink) creates user_upload folder even if uploads are diabled (and it creates it in a random storage) to Link Browser (RTE and inputLink) and DefaultFactory creates user_upload folder even if uploads are diabled (and it creates it in a random storage)

We just noticed that the DefaultFactory of the Core FolderStructure also has user_upload as a default node. Why is this?

It also has importexport as a default node, even when ext:impexp is not even installed...

All these directories are no "default" directories, they are only needed in very special scenarios:
  • Upload enabled for BE users at all with no other special folder configured (and then the FAL API creates the directory on-the-fly anyways)
  • ext:impexp installed (and I bet thsi extension creates it also on-the-fly, did not verify it because we don't use it)

Why are these folders marked as "default"?

Actions #8

Updated by Benni Mack 11 months ago

  • Sprint Focus set to Stabilization Sprint
Actions

Also available in: Atom PDF