Task #97638
closedUse local TypoScriptFrontendController instead of $GLOBALS['TSFE'] in ContentObjects
100%
Description
The ContentObjectRenderer
already offers the possibility to use a local version of the TypoScriptFrontendController
, if this is not available the global version is used.
So the base is there to use different initialized frontend environments without risking conflicts, but unfortunately most ContentObjects still access the global version $GLOBALS['TSFE'] directly, e.g. the ImageResourceContentObject
:
public function render($conf = [])
{
$GLOBALS['TSFE']->lastImgResourceInfo = $this->cObj->getImgResource($conf['file'] ?? '', $conf['file.'] ?? []);
if ($GLOBALS['TSFE']->lastImgResourceInfo) {
$imageResource = $GLOBALS['TSFE']->lastImgResourceInfo[3];
$theValue = isset($conf['stdWrap.']) ? $this->cObj->stdWrap($imageResource, $conf['stdWrap.']) : $imageResource;
} else {
$theValue = '';
}
return $theValue;
}
From my point of view it makes sense in general to rely less on global objects, but with the indexing of EXT:solr there are also concrete use cases in which consistent access to the local objects is helpful.
Since the ContentObjectRenderer itself falls back on the global object of the TypoScriptFrontendController
, an adaption of the ContentObjects should be uncomplicated and should not result in a breaking change:
/**
* @return TypoScriptFrontendController|null
* @internal this is set to public so extensions such as EXT:solr can use the method in tests.
*/
public function getTypoScriptFrontendController()
{
return $this->typoScriptFrontendController ?: $GLOBALS['TSFE'] ?? null;
}
(TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer)