[BUG] Shared viewhelper instances can lead to wrong rendering #4246
Comments
dkd-kaehm
added a commit
to dkd-kaehm/ext-solr
that referenced
this issue
Dec 10, 2024
…tting All entries in Services.yaml become the `shared` setting dependent on its implementation and context. All non-Singleton-Like classes are set to `shared: false` which could stuck with objects states: * on Builder-Objects * on Query-Objects * on other object, those state change is not global relevant Some classes were commented with todos. Relates: TYPO3-Solr#3995 Fixes: TYPO3-Solr#4183, TYPO3-Solr#4246
1 task
dkd-kaehm
added a commit
to dkd-kaehm/ext-solr
that referenced
this issue
Dec 11, 2024
…tting All entries in Services.yaml become the `shared` setting dependent on its implementation and context. All non-Singleton-Like classes are set to `shared: false` which could stuck with objects states: * on Builder-Objects * on Query-Objects * on other object, those state change is not global relevant Relates: TYPO3-Solr#3995 Fixes: TYPO3-Solr#4183, TYPO3-Solr#4246 Ports: TYPO3-Solr#4251
dkd-kaehm
added a commit
that referenced
this issue
Dec 11, 2024
…tting All entries in Services.yaml become the `shared` setting dependent on its implementation and context. All non-Singleton-Like classes are set to `shared: false` which could stuck with objects states: * on Builder-Objects * on Query-Objects * on other object, those state change is not global relevant Some classes were commented with todos. Relates: #3995 Fixes: #4183, #4246
dkd-kaehm
added a commit
that referenced
this issue
Dec 11, 2024
…tting All entries in Services.yaml become the `shared` setting dependent on its implementation and context. All non-Singleton-Like classes are set to `shared: false` which could stuck with objects states: * on Builder-Objects * on Query-Objects * on other object, those state change is not global relevant Relates: #3995 Fixes: #4183, #4246 Ports: #4251
|
@deschilter Thank you for working out the issue! I can confirm that we also have this problem. With the change from the pull request, the problem has disappeared. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
In the Services.yaml the viewhelpers are configured without
shared: false. This can lead to side-effects as the viewhelpers have instance specific properties likerenderChildrenClosure. If the value of a previous usage of the viewhelper is not reset properly, the wrong content will be rendered.To Reproduce
I found a situation where this happens. You will need two separate pages (Page 1 and Page 2) and to separate plugins with a different template (Template A and Template B) with a call to
s:searchForm. The Child-Fluid of the SearchFormViewHelper should differ between the templates.On Page 1 insert the plugin with Template A.
On Page 2 insert the plugin with Template A first and below it the plugin with Template B.
The plugin with Template B on Page 2 will output the same Child-Fluid as the plugin with Template A.
This is because the same instance of the SearchFormViewHelper is used for both templates. The cache for Template A has been built, which results in the
renderChildrenClosurebeing set. The cache for Template B is not built, so the property is not overridden.Expected behavior
A different instance of SearchFormViewHelper should be used for each call in the fluid templates.
Is there a reason why viewhelpers are currently shared?
Used versions (please complete the following information):
The text was updated successfully, but these errors were encountered: