InitialiseTypesEvent dispatched in BE context
infabo opened this issue · comments
Current behavior
TypeError: Brotkrueml\Schema\EventListener\AddBreadcrumbList::getTypoScriptFrontendController(): Return value must be of type TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController, null returned
File "/typo3conf/ext/schema/Classes/EventListener/AddBreadcrumbList.php", line 115, in Brotkrueml\Schema\EventListener\AddBreadcrumbList::getTypoScriptFrontendController
return $GLOBALS['TSFE'];
File "/typo3conf/ext/schema/Classes/EventListener/AddBreadcrumbList.php", line 60, in Brotkrueml\Schema\EventListener\AddBreadcrumbList::__invoke
foreach ($this->getTypoScriptFrontendController()->rootLine as $page) {
File "/typo3/sysext/core/Classes/EventDispatcher/EventDispatcher.php", line 51, in TYPO3\CMS\Core\EventDispatcher\EventDispatcher::dispatch
$listener($event);
File "/typo3conf/ext/schema/Classes/Manager/SchemaManager.php", line 59, in Brotkrueml\Schema\Manager\SchemaManager::__construct
$event = $eventDispatcher->dispatch(new InitialiseTypesEvent());
File "/typo3/sysext/core/Classes/Utility/GeneralUtility.php", line 3249, in TYPO3\CMS\Core\Utility\GeneralUtility::makeInstanceForDi
return new $finalClassName(...$constructorArguments);
...
(82 additional frame(s) were not displayed)
Brotkrueml\Schema\EventListener\AddBreadcrumbList::getTypoScriptFrontendController(): Return value must be of type TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController, null returned
Expected behavior/output
Don't dispatch InitialiseTypesEvent in BE-context.
Steps to reproduce
We have a call of schema:type.person in one of our Fluid-templates. We use a section called Preview in this template, to render CE-previews in page module. schema:type.person is used in another Fluid-section - so not used in BE - but Fluid still compiles the whole template (even if we just use $view->renderSection('Preview', ...))
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
- schema version(s): 2.7.0
- TYPO3 version(s): 11.5.24
- Is your TYPO3 installation set up with Composer (Composer Mode): yes
- OS: Linux
Possible Solution
PR with possible fix on the way
Additional context
Add any other context about the problem here.
I just tried to reproduce the issue with current main-branch. Seems like this issue is already resolved. So waiting for a new release.
Thanks!
Sorry, still able to reproduce in dev-main.
@infabo I am curious where in backend the SchemaManager is instantiated. It should only be used by the page renderer hook and there is the check for frontend/backend. Your stack trace ends when it becomes interesting.
Ahh.. I see: "to render CE-previews in page module".
Hmmm. Don't like the check for backend/frontend for this case. Will think about it.
Problem is, the view helpers are called anyway. This should be avoided in backend context. The SchemaManager is the part where now an error occurs.
I guess I need to provide an example of how we use it.
<html xmlns="http://www.w3.org/1999/xhtml" lang="en"
xmlns:f="http://typo3.org/ns/TYPO3/Fluid/ViewHelpers"
xmlns:schema="http://typo3.org/ns/Brotkrueml/Schema/ViewHelpers"
data-namespace-typo3-fluid="true">
<f:section name="Main">
<f:comment>Regular FE markup goes here</f:comment>
<schema:type.person
identifier="foobar"
></schema:type.person>
</f:section>
<f:section name="Preview">
<f:comment>Some BE preview markup goes here</f:comment>
</f:section>
</html>Section Main is used for FE. Section Preview we use for backend previews in page module.
In the PageLayoutViewDrawItemHook we use it like:
- Load the template
- render output of Preview section
$view = GeneralUtility::makeInstance(StandaloneView::class);
$view->setTemplatePathAndFilename("EXT:site_package/Resources/Private/Templates/Element.html");
// enrich some data here
$itemContent = $view->renderSection(
'Preview',
[
'data' => $row,
....
],
true
);
It is because of the Fluid template parser, that creates an instance of every viewhelper found in the whole template. Regardless of sections that are actually used. Because of this, every __construct is executed and leads to this issue.
Problem is, the view helpers are called anyway. This should be avoided in backend context. The SchemaManager is the part where now an error occurs.
My PR was just a "cheap" way to avoid these PSR-events to be dispatched, so to say, cure the symptom first. As the viewhelper are not called actually, just instantiated by the Fluid template parser, I have no followup error in SchemaManager.
Can confirm, working for me!
@infabo Thanks for the contribution.