Project

General

Profile

Actions

Bug #88082

closed

FrontendUserImageUpdateWizard fails, when there are multiple storages

Added by Torben Hansen over 5 years ago. Updated over 1 year ago.

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

0%

Estimated time:
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.

Actions #1

Updated by Torben Hansen over 5 years ago

  • Description updated (diff)
Actions #2

Updated by Susanne Moog over 5 years ago

  • Category set to File Abstraction Layer (FAL)
Actions #3

Updated by Markus Klein over 5 years ago

  • Status changed from New to Accepted
Actions #4

Updated by Torben Hansen over 1 year ago

  • Status changed from Accepted to Closed

Closing issue, since the FrontendUserImageUpdateWizard has been removed with TYPO3 v10.

Actions

Also available in: Atom PDF