Project

General

Profile

Actions

Bug #95476

closed

Site configuration imports broken in v11.5

Added by Chris Müller over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
Start date:
2021-10-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
7.4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I am using imports in the site configuration's config.yaml like this:

imports:
  - { resource: 'EXT:myext1/Configuration/Sites/config.yaml' }
  - { resource: 'EXT:myext2/Configuration/Sites/config.yaml' }
  - { resource: 'EXT:myext3/Configuration/Sites/config.yaml' }

When I flush the cache (or remove var/cache completely) and make also a clean install of composer dependencies the following exception is thrown:

Call to a member function isPackageActive() on null
in /var/www/html/public/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php line 120

at TYPO3\CMS\Core\Utility\ExtensionManagementUtility::isLoaded('myext1')
in /var/www/html/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php line 2816

at TYPO3\CMS\Core\Utility\GeneralUtility::getFileAbsFileName('')
in /var/www/html/public/typo3/sysext/core/Classes/Configuration/Loader/YamlFileLoader.php line 125

at TYPO3\CMS\Core\Configuration\Loader\YamlFileLoader->getStreamlinedFileName('EXT:myext1/Configuration/Sites/config.yaml', '/var/www/html/config/sites/main/config.yaml')
in /var/www/html/public/typo3/sysext/core/Classes/Configuration/Loader/YamlFileLoader.php line 81

at TYPO3\CMS\Core\Configuration\Loader\YamlFileLoader->loadAndParse('EXT:myext1/Configuration/Sites/config.yaml', '/var/www/html/config/sites/main/config.yaml')
in /var/www/html/public/typo3/sysext/core/Classes/Configuration/Loader/YamlFileLoader.php line 164


Related issues 1 (0 open1 closed)

Has duplicate TYPO3 Core - Bug #95401: Site configuration imports broken in v11.4Closed2021-09-29

Actions
Actions #1

Updated by Chris Müller over 2 years ago

  • Has duplicate Bug #95401: Site configuration imports broken in v11.4 added
Actions #2

Updated by Chris Müller over 2 years ago

Sorry for the buzz, an extension of mine which uses the TYPO3 Yaml loader throws this exception. Ticket can be closed.

Actions #3

Updated by Benjamin Franzke over 2 years ago

May you document what your extension did to trigger this?

Did it use ExtensionManagementUtility inside Configuration/Services.php?

Actions #4

Updated by Chris Müller over 2 years ago

In my extension "matomo_widgets" I am reading the config/sites/xxx/config.yaml in the Services.php via TYPO3's YamlFileLoader to read the site configuration values for this extension (and also to resolve the imports). In the site configuration the widgets can be activated or deactivated. Dependend on the status I configure the dashboard widgets (or not).

Naively, I just used in Services.yaml GeneralUtility::makeInstance() to get the YamlFileLoader, which works in v10.4 until v11.3. Now, I am a little stuck. The problem is the call of GeneralUtility::getFileAbsFileName() in line 125 of the YamlFileLoader which calls ExtensionManagementUtility::resolvePackagePath() which triggers the exception.

https://github.com/brotkrueml/typo3-matomo-widgets/blob/master/Configuration/Services.php#L64

Actions #5

Updated by Benjamin Franzke over 2 years ago

  • Status changed from New to Closed

Ok, thanks for the explanation.

This is not supported, sorry. Actually this API isn't supported in Services.php on purpose:
Non-service onfiguration needs to be processed runtime (can be cached there) but not by compiletime.

Why shouldn't configuration be processed at compile time?

Configuration that is processed at compile time, then requires the dependency injection cache to be cleared, whenever configuration is changed.

Furthermore the dependency injection Container state becomes harder to understand when too many configuration formats have an influence.

Why did it work in v10 nonetheless?

ExtensionManagementUtility() usage in Services.php has never been an
intended usage, but was technically possible in TYPO3 v10 as a side
effect of runtime activated packages, and therefore got documented in
example code.

Also see
https://review.typo3.org/c/Packages/TYPO3.CMS/+/71272 and
https://review.typo3.org/c/Packages/TYPO3.CMS/+/71252
for reference for the decision in TYPO3 core.

What to do instead?

Please process the configuration during runtime and let us know if/why that's not possible.

Actions

Also available in: Atom PDF