Bug #17883

Nested USER_INT, COA_INT, etc. objects are not rendered

Added by Oliver Hader almost 12 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Communication
Target version:
-
Start date:
2007-12-04
Due date:
% Done:

0%

TYPO3 Version:
4.1
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

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)

0006885_v2_41.patch View (6.34 KB) Administrator Admin, 2007-12-13 16:22

0006885_v2_trunk.patch View (6.36 KB) Administrator Admin, 2007-12-13 16:22


Related issues

Related to TYPO3 Core - Bug #18374: XCLASSing USER_INT objects does not work Closed 2008-03-05

History

#1 Updated by Oliver Hader almost 12 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.

#2 Updated by Ralf Merz almost 12 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:
<!-- INT_SCRIPT.3jkjlj34kljm,m344909ßdsndn --> 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

#3 Updated by Ingo Renner almost 12 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...

#4 Updated by Ingo Renner over 11 years ago

committed to 4.2

#5 Updated by Oliver Hader over 11 years ago

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

#6 Updated by Jo Hasenau over 11 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.

#7 Updated by Oliver Hader over 11 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

Also available in: Atom PDF