Bug #98951
closed
Add constant for BE or FE context
0%
Description
Hello core team,
thank you for new Event "BootCompletedEvent". In earlier versions of TYPO3 I have used the Hook "TYPO3\CMS\Core\Database\TableConfigurationPostProcessingHookInterface".
With TYPO3 version 12 you have removed the constant TYPO3_MODE. That's no problem in general, but there is no replacement for such early EventListeners.
I can't use:
ApplicationType::fromRequest($GLOBALS['TYPO3_REQUEST'])->isBackend()
as request object was not build until now.
Please add the information about FE or BE context to something like Environment class.
Stefan
Updated by Benni Mack over 1 year ago
- Status changed from New to Needs Feedback
what do you want to achieve with the event, what should only be loaded in FE/BE context?
Updated by Stefan Froemken over 1 year ago
Hi Benni,
it's for my extension mysqlreport. I need the earliest possible Event of TYPO3 to register my SqlLogger to Doctrine. It needs the TYPO3_MODE to decide, if a query was executed for BE or FE context.
Stefan
Updated by Benni Mack over 1 year ago
Hi Stefan,
thanks for your feedback. Do you also need to distinguish between CLI and non-CLI in your extension?
Can you also quickly share what different things you need for backend and frontend?
Here is the main situation: One can now run a frontend "subrequest" (= executing a frontend call in a backend environment) in their installation so you might run into other problems...
Updated by Stefan Froemken over 1 year ago
Good morning Benni,
in first place mysqlreport will only log that information into database, so that an administrator can see which database queries were called in BE or FE. Currently, mysqlreport does not support query logging on CLI. But maybe that can be a feature for future releases.
The bigger problem is, that an administrator can decide to activate logging queries only for BE and/or FE. To get that working I need the current TYPO3_MODE at a very early state in the bootstrap process of TYPO3.
Nice greetings and maybe we see us within the next hours. Happy birthday TYPO3.
Stefan
Updated by Christian Kuhn 12 months ago
- Status changed from Needs Feedback to Rejected
Hey Stefan.
I fear we won't do something like that and I have to reject this issue. Here is why:
The TYPO3 bootstrap does not know if it is a FE or BE call. This is good. It shouldn't. The bootstrap is basically identical in FE and BE. The first place that knows about FE/BE are the application classes: Frontend/Http/Application, Backend/Http/Application and (internal) Install/Http/Application. Those create the Request object and handle it. They also set the 'applicationType' Request attribute since they know they are FE or BE. This is also why ApplicationType needs the request to determine BE/FE (ApplicationType->fromRequest()). This won't change.
We also can't add some constant and set it to BE or FE: This would fail when doing a BE call and then doing a FE sub request. This was one of the strong reasons why TYPO3_MODE had to ultimately fall - it was a non-constant constant!
I suggest to register your logging as an early middleware instead, if you need to keep your BE/FE distinction: Afaik, early bootstrap does not do any queries anyway, caches are for instance all file based at this point. I guess you may miss calls from extensions that fire DB calls in ext_tables / ext_localconf files, but that is not a good idea if an extension triggers this, so the worst thing that can happen is that those are not seen by your logger. Another option is to register always very early and then unregister in a FE/BE middleware again if not wanted.