Project

General

Profile

Actions

Bug #17883

closed

Nested USER_INT, COA_INT, etc. objects are not rendered

Added by Oliver Hader almost 17 years ago. Updated over 14 years ago.

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

0%

Estimated time:
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)


Files

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

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #18374: XCLASSing USER_INT objects does not workClosedOliver Hader2008-03-05

Actions
Actions #1

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.

Actions #2

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

Actions #3

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...

Actions #4

Updated by Ingo Renner over 16 years ago

committed to 4.2

Actions #5

Updated by Oliver Hader over 16 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)
Actions #6

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.

Actions #7

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

Actions

Also available in: Atom PDF