Bug #95962
closed
BootCompletedEvent unsuitable to replace extTablesInclusion-PostProcessing hook
Added by Oliver Eglseder almost 3 years ago.
Updated almost 2 years ago.
Sprint Focus:
Remote Sprint
Description
Discussing following deprecation: Deprecation-95065-HookExtTablesInclusion-PostProcessing.rst
There is a huge difference between the hook and the event. The hooks use case was to run some code after the ext_tables.php were included (you know, the "PostProcessing"-part of the hook's name). The new event is dispatched before the ext_tables.php files were included.
This makes the event ultimately unsuitable to replace the hook. Also, no other event will be dispatched after loding those files, so there is no chance to get any equivalent chance to run code, except the registration of your own Middleware which dispatches an event or runs the code, which seems to bet of an overkill. (Also, each extension author would have to do it own their own).
To actually replace the removed hook with an coequal event, a new event has to be dispatched right after the call to Bootstrap::loadExtTables()
in BackendRouteInitialization
.
- Status changed from New to Under Review
The Feature also references the AfterTcaCompilationEvent, not just BootCompletedEvent, as it is indeed not a 1:1 replacement.
Did you consider whether that event solves your usecase?
So, what is the exact usecase?
Again, its true that the event(s) are not 1:1 replacements, but I really wonder what the usecases are, ext_tables.php is used less and less these days, so there is no need for a hook in my opinion…
The patch https://review.typo3.org/c/Packages/TYPO3.CMS/+/72160 doesn't give a reason.
- Status changed from Under Review to Needs Feedback
My use case is very simple. I need to register a Backend Module dynamically after all ext_tables.php files were loaded.
See https://github.com/in2code-de/in2publish_core/blob/9.5.3/Classes/Tools/ToolsRegistry.php#L99
The "Tools Module" is a bare Backend Module. Other Extensions (and the Extension in2publish_core itself) register "Tools", which are nothing else than Controller-Action-Combinations for the Module registration via the ToolsRegistry.
The Hook is used to actually register the Module with all Controller/Actions which where registered as "Tool" after all ext_tables.php files have been included.
The BootCompletedEvent is triggered too early and there is no other event after the ext_tables files have bee included. So this event is actually required to maintain this functionality.
Oliver Eglseder wrote in #note-8:
My use case is very simple. I need to register a Backend Module dynamically after all ext_tables.php files were loaded.
See https://github.com/in2code-de/in2publish_core/blob/9.5.3/Classes/Tools/ToolsRegistry.php#L99
The "Tools Module" is a bare Backend Module. Other Extensions (and the Extension in2publish_core itself) register "Tools", which are nothing else than Controller-Action-Combinations for the Module registration via the ToolsRegistry.
The Hook is used to actually register the Module with all Controller/Actions which where registered as "Tool" after all ext_tables.php files have been included.
The BootCompletedEvent is triggered too early and there is no other event after the ext_tables files have bee included. So this event is actually required to maintain this functionality.
Another approach would be, to always load the ext_tables.php-files BEFORE the BootCompletedEvent-event is fired.
In TYPO3\CMS\Core\Core\Bootstrap::init the ext_tables.php-files are NOT loaded before BootCompletedEvent-event is fired (ext_tables.php are loaded AFTER the BootCompletedEvent-event is fired).
In TYPO3\CMS\Core\Core\BootService:loadExtLocalconfDatabaseAndExtTables the ext_tables.php-files ARE loaded before BootCompletedEvent-event is fired.
I have the same problem:
I must dynamically register Backend Modules - based on 'repository-results' (DB-queries), which i can get/call in BootCompletedEvent-event.
My current "bugfix" is, to check if $GLOBALS['TBE_MODULES'] is null. When $GLOBALS['TBE_MODULES'] is null, than i call "Bootstrap::loadExtTables"...not ver nice, but it works for me.
- Sprint Focus set to Remote Sprint
- Status changed from Needs Feedback to New
- Status changed from New to Rejected
as discussed, you've found a workaround for v11, and module registration API is new in v12 (during boot time), so nothing needed to be done here.
Also available in: Atom
PDF