Actions
Bug #99300
closed
ConfigurationManager causes ext_tables to fail.
Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2022-12-07
Due date:
% Done:
0%
Estimated time:
TYPO3 Version:
11
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
Description
Hello,
I investigated an issue which was reported by some of our editors.
They got this type of error while editing in the frontend.
The default controller for extension "Someextension" and plugin "Someplugin" can not be determined.
This only occurs if there is an active backend session while trying to show the frontend in the same browser (other tab).
I was able to track this back to an own extension.
The Extension fires a
\TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\Configuration\ConfigurationManager::class);
in the ext_table.php context.
The TypoScript config is required at this point, because the Modules for the backend are generated based on some ExtensionConfiguration and TypoScript.
This all works fine again, when the part which access the ConfigurationManager is encapsulated in a
if (TYPO3_MODE == 'BE') {
...
}
The error in the Frontend is gone, and the behavior in the backend is as expected.
ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isBackend()
Does not work in ext_tables.php, because $GLOBALS['TYPO3_REQUEST'] is null at this point.
Is there a way to determine the TYPO3_MODE in the ext_tables without using the now deprecated TYPO3_MODE in the ext_tables context?
Updated by
Actions