TYPO3 Core

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.

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

Oliver, can your take care of getting it into the core (sending reminders and such) as users reported the patch to be working...

committed to 4.2

• TYPO3_4-1 (rev. 3276) --> fixed in TYPO3 4.1.6
• TYPO3_4-2 (rev. 3265, by Ingo) with followup (rev. 3275)

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.

Hi Joey,

• 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