Bug #98992
closed
form DataStructureIdentifierHook uses $GLOBALS['LANG'] which may not be initialized
0%
Description
I noticed $GLOBALS['LANG'] may not be initialized in some contexts, this is also mentioned in LanguageService:
* Usually this is injected into $GLOBALS['LANG'] when in backend or CLI context, and * populated by the current backend user. Don't rely on $GLOBAL['LANG'] in frontend, as it is only * available in certain circumstances! * In Frontend, this is also used to translate "labels", see TypoScriptFrontendController->sL() * for that.
We are not in Frontend, but somehow it is not initialized in my case either (when running an Upgrade Wizard in the BE).
I have an Upgrade wizard which wants to migrate some Flexforms. I use FlexFormTools::cleanFlexFormXML which instantiate the DataStructureIdentifierHook which will throw an exception in the constructor because $GLOBALS['LANG'] is null.
It calls- TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools::cleanFlexFormXML
- which calls the TYPO3\CMS\Form\Hooks\DataStructureIdentifierHook constructor
- which calls $this->getLanguageService()
- which tries to return $GLOBALS['LANG']
EXT:form is installed here but it is not relevant at all to the Flexforms which are to be converted.
see attached stackdump file
Files
Updated by Sybille Peters over 1 year ago
This can be used as workaround before calling cleanFlexFormXML()
use TYPO3\CMS\Core\Configuration\FlexForm\FlexFormTools;
use TYPO3\CMS\Form\Hooks\DataStructureIdentifierHook;
// ...
// save and remove hook
$saveDataStructureIdentifierHook = null;
if (isset($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][FlexFormTools::class]['flexParsing'][DataStructureIdentifierHook::class])) {
$saveDataStructureIdentifierHook = $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][FlexFormTools::class]['flexParsing'][DataStructureIdentifierHook::class];
unset($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][FlexFormTools::class]['flexParsing'][DataStructureIdentifierHook::class]);
}
$xml = $this->flexformTools->cleanFlexFormXML('tt_content', 'pi_flexform', $row);
// ....
// restore hook
if (saveDataStructureIdentifierHook) {
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS'][FlexFormTools::class]['flexParsing'][DataStructureIdentifierHook::class] = $saveDataStructureIdentifierHook;
}
(or save it and restore it if necessary)
Updated by Franz Holzinger over 1 year ago
- Related to Bug #99434: Keep the $GLOBALS variables unto redirect to install tool added
Updated by Christian Kuhn 6 months ago
- Related to Bug #90784: Form plugin - Finishers : cannot translate "empty" value in labels added
Updated by Christian Kuhn 6 months ago
- Related to deleted (Bug #99434: Keep the $GLOBALS variables unto redirect to install tool)
Updated by Christian Kuhn 6 months ago
- Related to Task #100676: Reduce further includeLLFile usages after getLL removal added
Updated by Christian Kuhn 6 months ago
- Status changed from New to Closed
Ok, this is still an issue in v11: The access to globals LANG in __construct() has been introduced with #90784, including v11, and has later been removed again with #100676 for v12. The hook still uses getLanguageService(), but only at deeper levels and certain circumstances.
Note the CLI call cleanup:flexforms does init globals lang, so this is only an issue in your install tool upgrade wizard use case.
AFAIK, upgrade wizards don't init backend users nor globals lang (but unsure about that). It might be possible to do that in an upgrade wizard, though, but I'm unsure about the impact.
Your workaround is another alternative for v11.
The issue has been relaxed with v12 and I don't consider this scenario critical for v11. I hope it's ok to close.
Updated by Christian Kuhn 6 months ago
- Related to Bug #97972: FlexFormTools can not be used in frontend with form framework installed added