Bug #49056
closedCall stdWrapPostProcess hook even if "if" returned FALSE
0%
Description
I use the stdWrap hooks in Formhandler to add and remove submitted form values to $_GET/$_POST.
I use stdWrapPreProcess to add them and stdWrapPostProcess to remove them.
Problem:
If the user adds and "if" somewhere to the TypoScript, the stdWrapPostProcess method isn't called and the values can't be removed again.
e.g.:
markers { test = TEXT test { value = test if.isTrue.data = GP:debug } }
I found out, that an "if" evaluating to FALSE sets a "stopRendering" flag.
It would be nice to call at least stdWrapPostProcessing in any case.
I would like to know if that would be acceptable before pushing something to Gerrit.
Here are the suggested changes:
diff --git a/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php b/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php index de341f5..f554898 100644 --- a/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php +++ b/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php @@ -2019,6 +2019,13 @@ class ContentObjectRenderer { $isExecuted[$functionName] = TRUE; $isExecuted[$functionProperties] = TRUE; } + } elseif($this->stopRendering[$this->stdWrapRecursionLevel]) { + // Hand over the whole $conf array to the stdWrapHookObjects + if ($functionType === 'hook') { + $singleConf = $conf; + } + $functionName = 'stdWrap_stdWrapPostProcess'; + $content = $this->{$functionName}($content, $singleConf); } } unset($this->stopRendering[$this->stdWrapRecursionLevel]);
Updated by Ernesto Baschny about 11 years ago
- Category set to TypoScript
- Status changed from New to Accepted
Tough decision, as it is not documented how these hooks will behave. All other stdWrap methods stop being called if a "short circuit" if evaluates to false. Same currently happens to the hook.
But being seen as a counter-part of the "preProcess" part, it sounds logical that it gets called every time and thus I would say we could change the behavior here to be consistent and make it work as expected. So go ahead and push your suggested change to gerrit, and we'll give it a try. Don't forget to ease the reviewers live to add some "working example" (i.e. a sample extension you could attach to this issue, or an easy example using your Formhandler extension with easy steps on "how to reproduce").
Thanks Reinhard!
Updated by Gerrit Code Review about 11 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23309
Updated by Reinhard Führicht about 11 years ago
Steps to reproduce:
- Setup any Formhandler form (e.g. the Basic Contact Form Demo available here [1])
- Add a marker ###test### to the HTML template
- Configure the marker ###test### in TypoScript:
markers { test = TEXT test { value = test if.isTrue.data = GP:debug } }
- View the form page and have a look at the action attribute of the form:
formhandler/contact-form/?no_cache=1&contact%5BrandomID%5D=753bdb698e030abd358b4c57082cfc7e
Problem:
The parameter "randomID" shouldn't be there.
Formhandler hooks into stdWrap and adds internal parameters to $_GET temporarily. They would be removed in stdWrapPostProcess again, but they aren't since the condition evaluates to FALSE and the mathod isn't called.
Updated by Gerrit Code Review about 11 years ago
Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23309
Updated by Gerrit Code Review about 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/23309
Updated by Gerrit Code Review almost 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/23309
Updated by Markus Klein over 9 years ago
- Status changed from Under Review to New
- Target version deleted (
6.2.0) - Is Regression set to No
Updated by Susanne Moog almost 5 years ago
- Status changed from New to Rejected
Revisiting this issue, Ernestos comment and the abandoned patch I will reject this issue for now, as changing that would lead to unexpected behaviour and also introduce inconsistencies when using if.