Bug #68123

Broken extbase configurationManager 1st level cache

Added by Marc Bastian Heinrichs over 5 years ago. Updated about 1 year ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Since merging fix for #59505 the configuration managers return of the configuration is broken a very special way. It could be validated with the news extension. A defined news detail page in the list plugin has no effect anymore.

Here is why:
Setting the configuration in the configurationManager results in a cleared 1st level cache. This is new since #59505.
Inside the widget rendering process the first getConfiguration call is done by the LocalizationUtility without a pluginName (coming from the TranslateVH). So no call to getContextSpecificFrameworkConfiguration, so no override from FF. This is cached then and used after for the later link rendering the LinkViewHelper from news, which knows nothing about the FF config.

So the main issue here is the 1st level cache key in AbstractConfigurationManager::getConfiguration that was basically changed with https://review.typo3.org/#/c/6362/

I would suggest to expand the cache key.


Updated by Marc Bastian Heinrichs over 5 years ago

  • Subject changed from Broken extbase configurationManager 1st lvel cache to Broken extbase configurationManager 1st level cache

Updated by Marc Bastian Heinrichs over 5 years ago

  • Priority changed from Must have to Should have

It turned out, that fixing the 1st level cache doesn't help, so it's a real regression in #59505.
But for some some very special scenarios, the cache key could causes problems, I would say, so I let the issue stay.


Updated by Susanne Moog about 1 year ago

  • Status changed from New to Rejected

As there were no other reports in the last few years I'm closing this issue now. If there is still an issue please report a new issue.

Also available in: Atom PDF