Bug #72600
open
Singleton ConfigurationManager creates problems with nested extbase plugins
0%
Description
This bug is a bit complicated to describe.
Currently the extbase ConfigurationManager is a singleton which has a state, for example AbstractConfigurationManager::$extensionName
When one extbase plugin calls cObjGetSingle on typoscript which also contains an extbase plugin, the configuration manager will hold incorrect values for the first plugin after the call.
This happens for example in the powermail extension, which allows fields to render a TypoScript object path. After rendering the typoscript, all calls to configurationManager->getConfiguration will return the configuration of the other plugin.
Another shortened example:
# TypoScript
page = PAGE
page.10 = USER
page.10 {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
extensionName = Plugin1
pluginName = plugin1
vendorName = Plugin1
}
lib.plugin2 = USER
lib.plugin2 {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
extensionName = Plugin2
pluginName = plugin2
vendorName = Plugin2
}
# Plugin1Controller.php
class Plugin1Controller extends \TYPO3\CMS\Extbase\Mvc\Controller\ActionController {
public function plugin1Action() {
$correct = $this->configurationManager->getConfiguration(ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
$string = $this->configurationManager->getContentObject()->cObjGetSingle('USER', $GLOBALS['TSFE']->tmpl->setup['lib.']['plugin2.']);
$incorrect = $this->configurationManager->getConfiguration(ConfigurationManagerInterface::CONFIGURATION_TYPE_FRAMEWORK);
}
}
Plugin1 renders TypoScript which contains Plugin2. Afterwards Plugin1 cannot get it's own configuration.
Updated by Robert Vock almost 9 years ago
It might be possible to fix this problem in Bootstrap::run.
If the current configuration is cached before the request is handled, it can be restored AFTER the request has finished:
public function run($content, $configuration)
{
// cache current state of configuration manager
$objectManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\Object\ObjectManager::class);
$configurationManager = $objectManager->get(\TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface::class);
$oldCObject = $configurationManager->getContentObject();
$oldConfiguration = $configurationManager->getConfiguration($configurationManager::CONFIGURATION_TYPE_FRAMEWORK);
$typoScriptService = $objectManager->get(\TYPO3\CMS\Extbase\Service\TypoScriptService::class);
$oldConfiguration = $typoScriptService->convertPlainArrayToTypoScriptArray($oldConfiguration);
// perform normal initialization and request
$this->initialize($configuration);
$result = $this->handleRequest();
// restore state of configuration manager
$this->configurationManager->setContentObject($oldCObject);
$this->configurationManager->setConfiguration($oldConfiguration);
return $result;
}
This worked for me, but I am not sure if there are any downsides to this.
Updated by Manfred Egger almost 6 years ago
I can confirm this problem and I also have a similar problem with FLUIDTEMPLATE ContentObject, but I couldn't get the workaround code working. Problem occurs in TYPO3 8.7 and 9.5 as well.
Edit: I guess that https://forge.typo3.org/issues/82033 has the same cause.
Updated by Benni Mack over 4 years ago
- Related to Bug #82033: extbase parameters in FLUIDTEMPLATE : configuration lost for extension Form added