Bug #86372

CacheManager 'assets' cache is not configurable in ext_localconf.php

Added by Benjamin Franzke about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Could have
Assignee:
-
Category:
System/Bootstrap/Configuration
Target version:
-
Start date:
2018-09-25
Due date:
% Done:

100%

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

Description

Since commit https://review.typo3.org/c/54020/ + followup https://review.typo3.org/54061 (released only in v9) it is no longer possible to configure the 'assets' cache in ext_localconf.php files.

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.

Associated revisions

Revision ad847e9b (diff)
Added by Benjamin Franzke about 1 year ago

[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
ext_localconf.php loading).
This is actually a regression introduced in
https://review.typo3.org/54381
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
ext_localconf.php altogether.

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
the release.

Change-Id: I22935dae3acb6e8de14fa98a6b88f3477a3ea313
Releases: master
Resolves: #86353
Resolves: #86371
Resolves: #86372
Reviewed-on: https://review.typo3.org/58371
Tested-by: TYPO3com <>
Reviewed-by: Susanne Moog <>
Tested-by: Susanne Moog <>
Reviewed-by: Frank Naegler <>
Tested-by: Frank Naegler <>

History

#1 Updated by Gerrit Code Review about 1 year ago

  • Status changed from New to Under Review

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58371

#2 Updated by Gerrit Code Review about 1 year ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58371

#3 Updated by Benjamin Franzke about 1 year ago

  • Priority changed from Should have to Could have

Seems this is not a regression (introduced in v9).
The problem actually exists since the introduction of the 'assets' cache in https://review.typo3.org/42730

#4 Updated by Gerrit Code Review about 1 year ago

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58371

#5 Updated by Gerrit Code Review about 1 year ago

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58371

#6 Updated by Gerrit Code Review about 1 year ago

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58371

#7 Updated by Benjamin Franzke about 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#8 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF