Bug #88082

FrontendUserImageUpdateWizard fails, when there are multiple storages

Added by Torben Hansen 5 months ago. Updated 3 months ago.

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

0%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The FrontendUserImageUpdateWizard copies images from /uploads/pics/ to fileadmin/_migrated/, but fails to lookup the copied images in FAL when there are multiple storages.

    public function init()
    {
        $storages = GeneralUtility::makeInstance(StorageRepository::class)->findAll();
        $this->storage = $storages[0];
        $this->registry = GeneralUtility::makeInstance(Registry::class);
        $this->recordOffset = $this->registry->get($this->registryNamespace, 'recordOffset');
    }

When there are multiple storages, $storages[0] will not always be the fileadmin storage, since initializeLocalCache in StorageRepository uses ->orderBy('name') when all available storages are initialized.

The FrontendUserImageUpdateWizard should either work with the default storage for both the copy and the lookup operation or ,if $GLOBALS['TYPO3_CONF_VARS']['BE']['fileadminDir'] is used for the copy process, lookup for a storage named like the fileadminDir configured.

History

#1 Updated by Torben Hansen 5 months ago

  • Description updated (diff)

#2 Updated by Susanne Moog 4 months ago

  • Category set to File Abstraction Layer (FAL)

#3 Updated by Markus Klein 3 months ago

  • Status changed from New to Accepted

Also available in: Atom PDF