Bug #19156
closed
functions in interface.tslib_content_stdwraphook.php gets executed numerous times.
Added by Peter Klein over 16 years ago.
Updated over 14 years ago.
Description
I was using /sysext/cms/tslib/interfaces/interface.tslib_content_stdwraphook.php to extend stdWrap with some extra functionality, when I discovered a weird problem.
When i have 1 content elemnt on my page it works fine, but when there 2 CEs, my extended stdWrap command gets executed twice. With 3 CEs, its executed 3 times and so on.
I then tried using a userFunc instead, which worked perfectly (only executed once for each CE).
Attached is a simple extension that illustrates the problem.
Just install it, and include the static template.
The static template consists of this TS code:
tt_content.text.20.stdWrapHookBug = 1
tt_content.text.20.postUserFunc = user_stdWrapHookBug
(issue imported from #M9058)
Files
I forgot to mention, that after installing the test extension, you should try viewing a page with multiple text CEs in the Frontend.
A related problem is also visible when installing the test plugin.
Notice that the "stdWrapPreProcess" function never gets executed.. (The text from that function should have be displayed in red color.)
Partial solution:
If I in the file "class.tslib_content.php", in the function "start", clear the "stdWrapHookObjects " by inserting this in line 363.
$this->stdWrapHookObjects = array();
Then the 1st problem seems to be solved. (But still no output from the "stdWrapPreProcess" function.
Having exactly the same issue. The problem seems to be clear: due to not resetting the $this->stdWrapHookObjects array in the start() function, the function collects the same call each time when a CONTENT object is created.
Unfortunately the stdWrapHookObjects array is "protected" so we are unable to "clean" this problem via our extension...
I created a patch to solve the original issue. It applies to 4.3-rc1 and hopefully we still get this into 4.3
The second problem:
The content from stdWrapPreProcess is overriden by
if ($conf['field']) {$content=$this->getFieldVal($conf['field']);}
which is a few lines below the stdWrapPreProcess hook.
As you can see, $content is filled with the value of the field 'bodytext', because we have
tt.content.text.20.field = bodytext
I'm not sure if this is the expected behavior or a bug. If it's expected behavior, we should remove $content from the stdWrapPreProcess hook.
Update: I'd propose to open a new bug for this issue.
Committed to trunk, rev 6545
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by