Bug #17883
closedNested USER_INT, COA_INT, etc. objects are not rendered
0%
Description
The following TypoScript won't work at the moment, because TSFE doesn't check for new *_INTs after one has been rendered.
6 = COA_INT
6 {
10 = TEXT
10.value = FIRST,
20 = COA_INT
20 {
10 = TEXT
10.value = SECOND,
20 = COA_INT
20 {
10 = TEXT
10.value = THIRD,
}
}
}
(issue imported from #M6885)
Files
Updated by Oliver Hader almost 17 years ago
The attached patch integrates a reprocessing for *_INT objects. Furthermore the inclusion of libraries ("includeLibs") was moved from index_ts.php and publish.php to tslib_fe.
Updated by Ralf Merz almost 17 years ago
Hi all,
for that I had to use nested USER_INTs I´ve tried Oliver´s patch.
And tattaaa: It works! Great!
So I give +1 on testing.
more detailed description:
On the project I do, we use commerce. In the checkout, on tx_commerce_pi3, I wanted to add the newloginbox, but only on the first step.
Therefor I´ve added a new marker ###LOGIN_BOX### in the billing-address template of commerce and implemented the processMarker hook in function getBillingAddress() in pi3 of commerce.
In my TS template I´ve put the newloginbox plugin into commerce_pi3 like:
plugin.tx_commerce_pi3 {
loginBoxUID = USER_INT
loginBoxUID.userFunc = plugin.tx_newloginbox_pi1->main
}
In my hook I fetch the loginBoxUID with
$loginBox = $pObj->cObj->cObjGetSingle($pObj->conf['loginBoxUID'],$pObj->conf['loginBoxUID.']);
and filled my marker with
$markerArray['###LOGIN_BOX###'] = $loginBox;
But in my Frontend I only got sth. like:
as loginbox.
This was because of nested USER_INTs as commerce_pi3 AND newloginbox_pi1 are both USER_INTs.
Now, after having patched this with Oliver´s patch, it works!!!
Again, thanks to Oliver! +1
Greets
Ralf
Updated by Ingo Renner almost 17 years ago
Oliver, can your take care of getting it into the core (sending reminders and such) as users reported the patch to be working...
Updated by Oliver Hader over 16 years ago
- TYPO3_4-1 (rev. 3276) --> fixed in TYPO3 4.1.6
- TYPO3_4-2 (rev. 3265, by Ingo) with followup (rev. 3275)
Updated by Jo Hasenau over 16 years ago
Don't know what the patch does exactly but IMHO it would have been enough to patch the TS parser itself so that it would switch XXX_INT objects to XXX objects when rendered within another XXX_INT object before rendering the whole stuff.
Since the surrounding XXX_INT object already makes sure that none of the containing elements will be taken from cache, nesting of XXX_INT objects will just slow down the rendering process without any additional advantage.
plugin.tx_commerce_pi3 = USER_INT
plugin.tx_commerce_pi3 {
loginBoxUID = USER_INT
loginBoxUID.userFunc = plugin.tx_newloginbox_pi1->main
}
switching it internally to
plugin.tx_commerce_pi3 = USER_INT
plugin.tx_commerce_pi3 {
loginBoxUID = USER
loginBoxUID.userFunc = plugin.tx_newloginbox_pi1->main
}
might have been enough to solve the problem and still have no cached output for the newloginbox.
Regarding performance I guess it might be better to avoid reprocessing.
Updated by Oliver Hader over 16 years ago
Hi Joey,
there are two scenarios:- user defined caching for the first/parent USER_INT - everything below can be handled by a several extension
- installing multiple and different plugins on a system - nested XXX_INTs did not work either - thus everytime you get a strange output you've to start debugging anywhere and will finally find out that nested XXX_INTs do not work
However, this patch was committed. If you experience any bugs, please create a new bug report and relate to this one. If you think that performance could be optimized, please open a feature request and hopefully come up with a patch.
Thank you in advance!
Cheers, Olly