The TYPO3 backend root-page breaks with the following exception, if other extensions registering additional FAL driver through \TYPO3\CMS\Core\Resource\Driver\DriverRegistry and you click edit on a File Storage record with AusDriverAmazonS3 driver:
(1/1) #1463653197 TYPO3\CMS\Core\Configuration\FlexForm\Exception\InvalidSinglePointerFieldException
Field value of field "driver" of database record with uid "3" from table "sys_file_storage" points to a "ds" key AusDriverAmazonS3 but this key does not exist and there is no "default" fallback.
For example, EXT:mautic-typo3 uses the cores DriverRegistry to register its FAL driver. But because the FAL registration of this AWS S3 extension is written directly into the array $GLOBALS['TYPO3_CONF_VARS']['SYS']['fal']['registeredDrivers'] in ext_localconf.php, the loading order matters.
Meaning, after cache-flush it can not be guaranteed that the array holds already all registered FAL configurations of other extensions if the DriverRegistry is doing its job. In our case it seemed, that the mautic-typo3 ext_localconf was loaded first, so the DriverRegistry had no idea about the AWS S3 FAL driver yet which results in the above exception.
Solution:
Using the DriverRegistry for registration solves the issue:
Edit 1:
Maybe this issue will be gone in v11.5 because a similar problem was reported here (TYPO3 FAL Driver Registry is unclear) which was patched in this changeset. Unfortunately we can't test it because EXT:mautic-typo3 is not ready for v11 yet. But I will provide updates on this issue later.
The TYPO3 backend root-page breaks with the following exception, if other extensions registering additional FAL driver through
\TYPO3\CMS\Core\Resource\Driver\DriverRegistry
and you click edit on a File Storage record withAusDriverAmazonS3
driver:For example, EXT:mautic-typo3 uses the cores DriverRegistry to register its FAL driver. But because the FAL registration of this AWS S3 extension is written directly into the array
$GLOBALS['TYPO3_CONF_VARS']['SYS']['fal']['registeredDrivers']
inext_localconf.php
, the loading order matters.Meaning, after
cache-flush
it can not be guaranteed that the array holds already all registered FAL configurations of other extensions if the DriverRegistry is doing its job. In our case it seemed, that the mautic-typo3 ext_localconf was loaded first, so the DriverRegistry had no idea about the AWS S3 FAL driver yet which results in the above exception.Solution: Using the DriverRegistry for registration solves the issue:
Environment: TYPO3 v10.4.28 PHP v7.4 EXT:aus-driver-amazon-s3 v1.11
Edit 1: Maybe this issue will be gone in v11.5 because a similar problem was reported here (TYPO3 FAL Driver Registry is unclear) which was patched in this changeset. Unfortunately we can't test it because EXT:mautic-typo3 is not ready for v11 yet. But I will provide updates on this issue later.