Bug #95781
closedPHP Warning: Undefined array key "uid" in /app/vendor/symfony/expression-language/Node/GetAttrNode.php
0%
Description
Error appears in Frontend on "Debug"-Mode
Typo3 Log:
Level: 1
Channel: php
Details: Core: Error handler (BE): PHP Warning: Undefined array key "uid" in /app/vendor/symfony/expression-language/Node/GetAttrNode.php line 97
Typo3: 11.5.1
PHP 8.0.10
Updated by Georg Ringer over 3 years ago
relevant line in symfony is
return $array[$this->nodes['attribute']->evaluate($functions, $values)];
Updated by Stefan Bürk over 3 years ago
Thanks for the report.
Can you provide eventually some kind of more information or what is involved to get this error ?
Updated by Bastian Holzem over 3 years ago
- File TYPO3 Exception.pdf added
Error appears in Frontend (on every Page) if Preset > Debug settings > Debug ist activated
don't could offer a screenshot of error because i get another error now before this
"(1/1) #1476107295 TYPO3\CMS\Core\Error\Exception
PHP Warning: Undefined array key "file" in /app/web/typo3/sysext/frontend/Classes/ContentObject/ImageResourceContentObject.php line 32"
Updated by David Hoeckele about 3 years ago
We had the same issue with TypoScript-Conditions like [page["uid"] 123] - these conditions caused the warnings above in the TYPO3 backend / on the backend login screen.
Changing the conditions to [page && page["uid"] 123] resolved the warnings.
Updated by David Hoeckele almost 3 years ago
- Has duplicate Bug #96907: Undefined array key "uid" - /symfony/expression-language/Node/GetAttrNode.php line 97 added
Updated by Felix Heller almost 3 years ago
- File typo3-backend-php-warning-expression-language-getattrnode.png added
David Hoeckele wrote in #note-5:
We had the same issue with TypoScript-Conditions like [page["uid"] 123] - these conditions caused the warnings above in the TYPO3 backend / on the backend login screen.
Changing the conditions to [page && page["uid"] 123] resolved the warnings.
I can confirm this. I've tested it with TYPO3 11.5.9 and PHP 8.0.18. With PHP 7.4.3, this error doesn't occur, so this is a problem related to PHP 8. The version of symfony/expression-language
is 5.4.8. To reproduce this issue, execute the following steps in the TYPO3 backend:
- Module "Settings": Set "Debug" as "Debug settings" in the "Configuration Presets".
- Module "Template tools": Create a new TypoScript template with a simple condition:
page = PAGE page.10 = TEXT page.10.value = HELLO WORLD! [page["is_siteroot"] == 1] page.10.value = HELLO ROOT! [END]
After saving the TypoScript template, a PHP warning is shown in the backend:
PHP Warning
Core: Error handler (BE): PHP Warning: Undefined array key "is_siteroot" in /var/www/html/example/vendor/symfony/expression-language/Node/GetAttrNode.php line 97
David Hoeckele's workaround prevents the error message, in this case:
[page && page["is_siteroot"] == 1] page.10.value = HELLO ROOT! [END]
Updated by Felix Heller almost 3 years ago
- File deleted (
typo3-backend-php-warning-expression-language-getattrnode.png)
Updated by Chris Müller almost 3 years ago
- Related to Bug #97624: Undefined array key "module" - /symfony/expression-language/Node/GetAttrNode.php line 97 added
Updated by Česlav Przywara almost 3 years ago
Seems to be still a problem on TYPO3 11.5.10. I am running non-composer install on PHP 8.0 and get plenty of these PHP warnings triggered by use of page
in TypoScript conditions.
Updated by Česlav Przywara almost 3 years ago
I found the culprit.
The problem is caused by EXT:frontend\Classes\Configuration\TypoScript\ConditionMatching\ConditionMatcher.php
being executed in backend context. This is why no page data are passed to expression resolver.
Below are two callstacks (from TYPO3 11.5.10). Both start at relevant action and controller.
First callstack leads to the point where expression variables are initialized via FE ConditionMatcher.
Obviously, $page
variable is set to an empty array in backend context:
protected function updateExpressionLanguageVariables(): void
{
$page = $GLOBALS['TSFE']->page ?? [];
...
TYPO3\CMS\Frontend\Configuration\TypoScript\ConditionMatching\ConditionMatcher->updateExpressionLanguageVariables (d:\kitzspitz\typo3_src\typo3\sysext\frontend\Classes\Configuration\TypoScript\ConditionMatching\ConditionMatcher.php:51) TYPO3\CMS\Core\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher->initializeExpressionLanguageResolver (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher.php:81) TYPO3\CMS\Frontend\Configuration\TypoScript\ConditionMatching\ConditionMatcher->__construct (d:\kitzspitz\typo3_src\typo3\sysext\frontend\Classes\Configuration\TypoScript\ConditionMatching\ConditionMatcher.php:46) TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\Utility\GeneralUtility.php:3204) TYPO3\CMS\Core\TypoScript\TemplateService->generateConfig (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\TypoScript\TemplateService.php:970) TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager->getTypoScriptSetup (d:\kitzspitz\typo3_src\typo3\sysext\extbase\Classes\Configuration\BackendConfigurationManager.php:75) TYPO3\CMS\Extbase\Configuration\ConfigurationManager->getConfiguration (d:\kitzspitz\typo3_src\typo3\sysext\extbase\Classes\Configuration\ConfigurationManager.php:111) TYPO3\CMS\Fluid\View\TemplatePaths->getContextSpecificViewConfiguration (d:\kitzspitz\typo3_src\typo3\sysext\fluid\Classes\View\TemplatePaths.php:95) TYPO3\CMS\Fluid\View\TemplatePaths->fillDefaultsByPackageName (d:\kitzspitz\typo3_src\typo3\sysext\fluid\Classes\View\TemplatePaths.php:128) TYPO3\CMS\Backend\View\Drawing\BackendLayoutRenderer->__construct (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\View\Drawing\BackendLayoutRenderer.php:58) TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\Utility\GeneralUtility.php:3204) TYPO3\CMS\Backend\Controller\PageLayoutController->renderContent (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\Controller\PageLayoutController.php:714) TYPO3\CMS\Backend\Controller\PageLayoutController->main (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\Controller\PageLayoutController.php:617) TYPO3\CMS\Backend\Controller\PageLayoutController->mainAction (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\Controller\PageLayoutController.php:227)
A bit later, second call stack leads to the exact place that generates the warning:
Symfony\Component\ExpressionLanguage\Node\GetAttrNode->evaluate (d:\kitzspitz\typo3_src\vendor\symfony\expression-language\Node\GetAttrNode.php:97) Symfony\Component\ExpressionLanguage\Node\BinaryNode->evaluate (d:\kitzspitz\typo3_src\vendor\symfony\expression-language\Node\BinaryNode.php:90) Symfony\Component\ExpressionLanguage\ExpressionLanguage->evaluate (d:\kitzspitz\typo3_src\vendor\symfony\expression-language\ExpressionLanguage.php:67) TYPO3\CMS\Core\ExpressionLanguage\Resolver->evaluate (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\ExpressionLanguage\Resolver.php:81) TYPO3\CMS\Core\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher->evaluateExpression (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher.php:201) TYPO3\CMS\Core\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher->match (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\Configuration\TypoScript\ConditionMatching\AbstractConditionMatcher.php:183) TYPO3\CMS\Core\TypoScript\Parser\TypoScriptParser->parse (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\TypoScript\Parser\TypoScriptParser.php:191) TYPO3\CMS\Core\TypoScript\TemplateService->generateConfig (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\TypoScript\TemplateService.php:1023) TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager->getTypoScriptSetup (d:\kitzspitz\typo3_src\typo3\sysext\extbase\Classes\Configuration\BackendConfigurationManager.php:75) TYPO3\CMS\Extbase\Configuration\ConfigurationManager->getConfiguration (d:\kitzspitz\typo3_src\typo3\sysext\extbase\Classes\Configuration\ConfigurationManager.php:111) TYPO3\CMS\Fluid\View\TemplatePaths->getContextSpecificViewConfiguration (d:\kitzspitz\typo3_src\typo3\sysext\fluid\Classes\View\TemplatePaths.php:95) TYPO3\CMS\Fluid\View\TemplatePaths->fillDefaultsByPackageName (d:\kitzspitz\typo3_src\typo3\sysext\fluid\Classes\View\TemplatePaths.php:128) TYPO3\CMS\Backend\View\Drawing\BackendLayoutRenderer->__construct (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\View\Drawing\BackendLayoutRenderer.php:58) TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\Utility\GeneralUtility.php:3204) TYPO3\CMS\Backend\Controller\PageLayoutController->renderContent (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\Controller\PageLayoutController.php:714) TYPO3\CMS\Backend\Controller\PageLayoutController->main (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\Controller\PageLayoutController.php:617) TYPO3\CMS\Backend\Controller\PageLayoutController->mainAction (d:\kitzspitz\typo3_src\typo3\sysext\backend\Classes\Controller\PageLayoutController.php:227)
First and second callstack diverge in TYPO3\CMS\Core\TypoScript\TemplateService->generateConfig
method:
First (lines 969-970):
/** @var ConditionMatcher $matchObj */
$matchObj = GeneralUtility::makeInstance(ConditionMatcher::class);
TYPO3\CMS\Core\TypoScript\TemplateService->generateConfig (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\TypoScript\TemplateService.php:970)
Second (lines 1022-1023):
// Finally parse the Setup field TypoScript code (where constants are now substituted)
$config->parse($all, $matchObj);
TYPO3\CMS\Core\TypoScript\TemplateService->generateConfig (d:\kitzspitz\typo3_src\typo3\sysext\core\Classes\TypoScript\TemplateService.php:1023)
No idea how this can be fixed properly, but hopefully this helps a bit :-)
Updated by Torben Hansen over 2 years ago
The problem does not only occur, when debug mode is active but also in backend context (e.g. TYPO3 login page or various backend modules).
The TYPO3 documentation has been updated recently regarding this topic to use traverse()
to ensure the array key exist before accessing - see https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/commit/5b811807768be31d456ade77f23332d4920ccf5b
Example:
[traverse(page, "uid") == 123]
Updated by Georg Ringer over 2 years ago
- Related to Bug #98197: Undefined array key in form variants if variable of variant condition is empty added
Updated by Frank Nägler over 2 years ago
Looks like it is related and maybe solved with #98515 ?
Updated by Chris Müller over 2 years ago
- Is duplicate of Bug #98515: Undefined array key with symfony expression results in log entries added
Updated by Chris Müller over 2 years ago
- Has duplicate Bug #99001: PHP Warning: Undefined array key "module" in /typo3_src-11.5.17/vendor/symfony/expression-language/Node/GetAttrNode.php line 97 added
Updated by Ian Solo over 2 years ago
Another use case, with TYPO3 11.5.18-dev and PHP 8.1 and a form.yaml like (simplified):
renderables variants condition: 'formValues["items-count"] != 2'
Updated by Felix Nagel about 2 years ago
- Related to Bug #94707: Undefined array key / Trying to access array offset on value of type null / PHP Version 8.0.8 added
Updated by Felix Nagel about 2 years ago
- Related to Bug #99130: Form Variants: Dynamic validators on formValues break in PHP 8 added
Updated by Felix Nagel about 2 years ago
FYI: #99130 seems like the same issue but the ticket already has a patch attached
Updated by Chris Müller almost 2 years ago
- Related to Bug #100098: PHP Warning in Backend with php 8.2 added
Updated by Sybille Peters almost 2 years ago
Workaround in TypoScript documentation:
instead of using "page" in TypoScript conditions directly, use traverse()
(Was already mentioned above, but without the link.)
Updated by Sybille Peters almost 2 years ago
- Has duplicate Task #89176: Provide better way to traverse array in TS conditions added
- Has duplicate Bug #88756: TypoScript – Symfony Expressions: request.getQueryParams() should do an "is defined" validation added
Updated by Christian Kuhn almost 2 years ago
- Status changed from Accepted to Rejected
rejected. see #98515
use traverse() or ?? operator to sanitize conditions.