Bug #91654
closedMissing request.getNormalizedParams() in CLI context
0%
Description
Using the request
condition for comparing the HTTP host fails in CLI context.
Setup:
[request.getNormalizedParams().getHttpHost() == '9lts.ddev.site'] page.10 = TEXT page.10.value = Hello World [global]
Executing a console command like /var/www/html/bin/typo3cms extension:activate tika
results in this error:
TYPO3 [ERROR] request="24a8a0f11c56c" component="TYPO3.CMS.Frontend.Configuration.TypoScript.ConditionMatching.ConditionMatcher": Unable to get a property on a non-object. - {"expression":"request.getNormalizedParams().getHttpHost() == '9lts.ddev.site'","exception":"RuntimeException: Unable to get a property on a non-object. in \/var\/www\/html\/vendor\/symfony\/expression-language\/Node\/GetAttrNode.php:83
We're using TYPO3 CMS 9.5.18 (haven't seen a fix in 9.5.19).
According to documentation the `request` condition should work in all contexts. Or does that not include CLI?
Setting it to [request.getNormalizedParams() || request.getNormalizedParams().getHttpHost() == '9lts.ddev.site']
resolves the error, so I believe getNormalizedParams()
is null.
Updated by Moritz Ahl almost 4 years ago
Is grouping blocks of TS conditions by brackets a valid syntax? Example:
[request.getNormalizedParams() && (request.getNormalizedParams().getHttpHost() == "sub1.domain.de" || request.getNormalizedParams().getHttpHost() == "sub2.domain.de" || request.getNormalizedParams().getHttpHost() == "sub2.domain.ddev.site")]
Intention: By first testing for request.getNormalizedParams() the following conditions are not evaluated anymore if the first one already returns null.
Updated by Benni Mack about 3 years ago
- Status changed from New to Needs Feedback
maybe you want to check out https://github.com/b13/host_variants
Updated by Christian Kuhn almost 3 years ago
- Status changed from Needs Feedback to Closed
hey. it seems the documentation has been adapted meanwhile: it now (correctly) states that request is only available in FE+BE, but not CLI. cli task that for instance crawl the frontend, thus need to create a proper requests on their own.
i think the issue is pretty much resolved, also together with the remark from benni, so i hope it's ok to close for the time being. please ping us in case you disagree or open a fresh issue.