CacheManager 'assets' cache is not configurable in ext_localconf.php
The IconRegisty is loaded in backend mode and reads the configuration (caches from 'assets') during object construction.
IconRegistry is usually instantiated during ext_localconf.php (due to extensions registering icons),
and therefore create's the 'assets' cache during ext_localconf.php loading.
After CacheManager has created the assets cache once, it will never be recreated again,
when the final configuration is set, after all ext_localconf.php files have been loaded.
[TASK] Do not create caches during ext_localconf.php phase
CacheManager has a design problem:
The CacheManager is used to create the core_cache. That core_cache
is used to read the (possibly) cached CacheManager configuration,
which is then used to configure the already-being-used CacheManager.
That means the initialization sequence currently is like:
new CacheManager(!$failsafe) | setInitialCacheConfiguration() |
loadExtLocalconf() | setFinalCachingFrameworkConfiguration()
Between initial creation of the CacheManager and
setFinalCachingFrameworkConfiguration() the CacheManager is in a limbo
state, as it may already be used to create a cache although the final
configuration (which may be configured in ext_localconf.php) for that
cache has not been set. The final configuration (for that created cache)
will then be ignored, as the cache has already been created.
This is not a theoretical problem, but is actually happening in core
for two caches (introduced due to patches in the v9 development
phase, more on those later).
In v10 we want to change the sequence to the following:
$coreCache = createCoreCache() | loadExtLocalconf |
new CacheManager(!$failsafe, $cachingConfiguration, $coreCache);
We want to delay CacheManager until ext_localconf.php has been loaded
(maybe also after baseTca loading) in v10.
Therefore GeneralUtility::makeInstance(CacheManager::class) usage in
ext_localconf.php is deprecated now.
Note: The core cache cannot be modified in ext_localconf.php - that was
always the case and wouldn't make sense (as that cache is used to actually
load the cached ext_localconf.php)
Two caches are actually loaded too early during ext_localconf.php loading
currently. We fix these as a drive-by: * extbase_reflection: the extbase Object\Container is instanciated in
EXT:extbase/ext_localconf.php. The Object\Container then instanciates
the ReflectionService in its constructor which itself creates the
extbase_reflection using the CacheManager (all of that during
This is actually a regression introduced in
We change the Container to load the reflection cache on demand. * assets: * IconRegistry uses the 'assets' cache and loads cached backend
icons during object construction.
This cache was introduced in https://review.typo3.org/c/54020/
using the core cache, and was later changed to 'assets' in
https://review.typo3.org/54061 * PageRenderer loads cached requireJS configuration from 'assets'
We inject assetsCache to these services from Bootstrap for now. We'll
only be able to properly refactor this, when dropping support for
We also adapt the ExtensionManagementUtility to retrieve the coreCache
as parameter, instead of statically. Although these methods are marked
@internal, we keep them for 9LTS to not break extensions (using this
regardless of being @internal, e.g. helhum/typo3-console) shortly before
Tested-by: TYPO3com <firstname.lastname@example.org>
Reviewed-by: Susanne Moog <email@example.com>
Tested-by: Susanne Moog <firstname.lastname@example.org>
Reviewed-by: Frank Naegler <email@example.com>
Tested-by: Frank Naegler <firstname.lastname@example.org>