Bug #99300
closed
ConfigurationManager causes ext_tables to fail.
0%
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 Christian Kuhn over 1 year ago
- Status changed from New to Rejected
Hey. Thanks for the report.
I'm afraid we're not able to resolve this issue in the core, the extension has to be updated, and the core has no other solution than to reject the issue.
Details:
ext_tables.php files are parsed early within TYPO3 bootstrap. Before a request is created. As such, it is invalid to rely on request-state at this point in time with an extension. In the past, the "constant" TYPO3_MODE has been set by TYPO3 depending on the given entry point.
This however was very problematic, since it made the constant being "not constant", but it changed depending on the used application (frontend / backend). When looking at sub requests, where a request to TYPO3 is done within another request (for instance to render a 404 page), this constant essentially was a hard blocker and had to vanish. TYPO3 v11 thus deprecated TYPO3_MODE, and v12 removed it.
With v11 and v12, the "mode" is now calculated after the request has been created, after the main bootstrap and thus after ext_tables.php are parsed. Having code that depends in ext_tables.php files on TYPO3_MODE or request-state is thus invalid.
In your use case, it's most likely a pretty bad idea to fire the extbase ConfigurationManager at this early point in time, since that's very expensive. There are solutions that should allow avoiding this, but it heavily depends on why the extension in question needs to trigger this calculation at this point. From core point of view, this extension behavior is a bug in the extension that needs to be resolved differently. Since the core does not know why extensions may use this construct, the migration strategy documented in https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/11.0/Deprecation-92947-DeprecateTYPO3_MODEAndTYPO3_REQUESTTYPEConstants.html#typo3-mode-and-typo3-requesttype-in-ext-localconf-php-and-ext-tables-php-files is relatively vague with only some general tips. In general the extension needs to be refactored to get rid of this misbehavior.
It would be great if you could document the use case and the change needed to update the extension.