If the first line is generated, this means that the splitChar IS working actually.

So if the second line fails, this means, that there is something wrong while changing the copied version of listNum from 0 to 1.

So could you please check if adding the following line gives you the desired output:

20.text.listNum.splitChar = |

Hello!

First Thank you for your support. Unfortunately, the attempt did not help. I think either it is up to the copying direction, or the splitChar type (pipe) is not allowed?

I don't know...

Best regards

If the character was not allowed, you should see the whole text including this character, which is not the case according to you original description.

I will try to reproduce the bug and see what might be the reason.

Actually it has nothing to do with the splitchar, since the second line doesn't show up at all - even if you just fill in a second text without using listNum.

In my second test it did not show up, because this line moves it out of the "viewport" of the GIFBUILDER

20.offset = 10,20+[10.h]+50

replacing it with

20.offset = 10,20+[10.h]+10

works - BUT - and now it's getting interesting: it does NOT work with listNum (with or without splitChar) although the height of the whole GIFBUILDER image is calculated correctly. So it renders an image of the expected size with the second line missing.

On the other hand both, listNum AND splitChar are working with a simple non GIFBUILDER TEXT Element

I have tried the same offset. "Of course" brought nothing. Has indeed worked. The font is not it either. There must have something else to blame. I'm just going to continue testing - only if it is a bug, it's all a waste of time :-(
It worked even to the update. There was otherwise not in between. Are there innovations in the GIFBUILDER - I do not know ....

Finally I managed to nail down the problem. It's a double stdWrap execution for TEXT elements resulting in a double listNum for the string.

So the first execution of listNum in the element 20 will give you the second part of the split already, while the second execution won't find the splitChar anymore and therefor can't give you a second part.

Part1|Part2 wil be converted to Part2 and then again converted to an empty string.

Atttached is a patch that should fix this behaviour by removing the extra stdWrap call for text elements.

Please test and report if this works for you.

Super Jo Hasenau!

Wonderful, it has solved the problem right away!

Thank you so much

ps. back a bit further to a final TYPO3 version ;-)

Hello Jo,

I dug my way through this problem too today (unfortunately before I found this bug report) and I came to the same conclusion as you did: stdWrap happens twice on GIFBUILDER object properties.

The concern I have with your solution is, that you take out the first (and much older) stdWrap code block while you leave in the block that has been added with 4.5. With your patch the stdWrap for all GIFBUILDER properties happens later in the GIF rendering process than it does in 4.4. A lot of calculations are now done on non-stdWrapped values. Under some conditions your solution will change the results of these calculations.

I guess we have to leave the 4.4 way of stdWrapping the params and eliminate the recurring code at the point that was introduced with 4.5. An alternative patch is attached.

It is quite hard to understand all the side effects, but here is one example I found that renders differently with your patch and my patch. My patch renders textMaxLength=10 - which is correct and as 4.4. did it. Your patch renders textMaxLength=1.

page.100 = IMAGE
page.100 {
    file = GIFBUILDER
    file {
      XY = 100,40
      10 = TEXT
      10{
        text = foobarfoobarfoobar
        textMaxLength = 1
        textMaxLength.wrap = |0
        offset = 0,20
      }
    }
}

Cheers, Jörg.

This bug is still very much alive and kicking in 4.5.15 (and very likely in the 4.6 and 4.7 branches too).
I am amazed that it does not affect thousands of websites. Or maybe it does and their owners just do not find their way to this bug report.

My patch ("20110324 Patch 17779 4.5.2.diff") still works with 4.5.15 (simply needs a little line number shift) and my argument against JoH's solution is still valid.

So how can we proceed on this?

Oh, and it would make sense if a moderator could adapt the title of this bug report!
Something like...

stdWrap executed twice on GIFBUILDER object properties

...would make it much easier for others to find this report, so they can test and comment on the patches given here.

Hi Jo,

On the other hand it seems that people don't have too many problems with the current bug.

yes, this is what amazes me.
For more than a year now I have to patch each and every TYPO3 update before I apply it to some of my systems.
Probably people face this problem but just don't dive deep enough into the code to get to the cause and understand that it really is a bug.

I did a lot of GIFBUILDER stuff recently and never ran into the double stdWrap trap.

Maybe you simply did not stdwrap any TEXT object within GIFBUILDER?
My little example above shows how easy it is to reproduce the problem.
Actually ANY stdwrap around any GIFBUILDER TEXT object is repeated. Here is another very simple and speaking example:

page.100 = IMAGE
page.100 {
    file = GIFBUILDER
    file {
      10 = TEXT
      10{
        offset = 0,20
        text = foo
        text.wrap = A|B
      }
    }
}

actually your patch does not solve the problem but does a simple revert to old school stdWrap functionality.

Could you drop a quick note why stdwrap was added to a later point in the execution chain ("new school" functionality :) and why it was not removed from the earlier point altogether but duplicated? This would help me understand what to look after in trying to improve your patch. It would also allow me to understand why you think my patch does not solve the problem. Because in all my implementations it solves it and I could not observe any negative side effects so far.

The initial idea of new stdWrap functionality was to provide a full set of stdWrap functions for each stdWrap function.
So we would get a kind of "chained TypoScript" to kake things like this possible:

10 = TEXT
10.dataWrap = {field:somefield}{field:anotherfield}
10.dataWrap.override = {field:yetanotherfield}
10.dataWrap.override.if.isFalse.field = somefield

We already had some stdWrap functions like override, that were stdWrap aware, but i.e. dataWrap was not.
As a consequence we wanted to implement the same principles to GIFBUILDER as well.

So we have to implement the same recursion as we did with original stdWrap functions but we have to make sure that functions that have been executed already will be removed from the stdWrap chain. This way a chained stdWrap function will silently remove itself leaving the key with the processed value only.

So I guess the problem is, that the removal of executed functions is buggy.

And maybe I didn't have too many problems, since I was working with something like that

10 = TEXT
10.text.cObject = COA

After all it seems inside the COA nothing is executed twice, even though the content of the COA itself might be generated twice.

Hi Jo,

I did some further debugging on this. The matter is complex and side effects can be easily overlooked, especially with my rather limited knowledge of the code details. So - if you agree - I would like to discuss my findings here with you and request your feedback.

Setup¶

All my tests are done with 4.5.15.

I am using the simple TS Setup as listed above. Here it is again:

page.100 = IMAGE
page.100 {
    file = GIFBUILDER
    file {
      10 = TEXT
      10{
        offset = 0,20
        text = foo
        text.wrap = A|B
      }
    }
}

Results¶

All stdwraps are executed within class.tslib_gifbuilder.php.

The first stdwrap happens here:

External code tslib_cObj->getImgResource() 
calls
  tslib_gifBuilder->start()  
  line 214 calls
    tslib_gifBuilder->checkTextObj()  
    line block 571-578 does the stdwrap

The second stdwrap happens here:

External code tslib_cObj->getImgResource() 
calls
  tslib_gifBuilder->gifBuild()  
  line 371 calls
    tslib_gifBuilder->make()  
    line block 409-416 does the stdwrap

Now, the interesting part is that I do not find ANY code that removes parameters from the list that have already been stdWrapped.
There is indeed an array $isStdWrapped that is filled with the names of all parameters that have been treated with stdWrap. Parameters that are found in this array are skipped. BUT: This array is re-initialized before each of the above loops and it is also local to each of the two functions that contain the stdWrap loops (checkTextObj and make). So basically this array does not have any function (as far as I can see).

Could it be that this coding is very incomplete?
Was $isStdWrapped once meant to become a class property that pertains the list of already treated properties but never did?
It very much smells like that.

I would be very happy if you could have a look at the relevant code parts and tell me your thoughts. You are obviously much more acquainted with that code than me.

BTW: If this is not the right place for such lengthy discussions, just tell me.

Ping.

This bug is still alive and kicking. I have tried my best to nail it down and make removal as painless as possible.
Any estimation when this will be reviewed?

Hi Jörg,

Please push your patch to Gerrit in order to start the review process. All interesting information about the workflow can be found here: http://wiki.typo3.org/Contribution_Walkthrough_Tutorials

Hi Stefan,

quite frankly: No.

I am willing to provide my time to isolate and amend problems in the core and report them back here. But I will not go through 10+ pages of GIT+Gerrit installation and setup, only to prove that I really mean it. I am not available for such acts of dressage. Rather I will keep patching the core on my end until the core team finally sees a need to address the problem.

All information is readily available right here, and Jo Hasenau, who initially created the bug during the StdWrap widening process, is well aware of the problem. He is monitoring this bug report.

This bug is still alive and kickin' in 4.7.4.
The attached patch for 4.5.15 still works as well (line numbers must be adapted).

I have created a new bug report to boil down all the findings and discussions, attach a correct title and make it easier to see the basic problem and its solution. A patch for 4.7.4 is attached too: #41487.
I honestly hope that the core team will finally accept this as a severe bug in GIFBUILDER that has survived much to long.

Hi Benjamin,

this issue can be closed.
See #41487 which was solved about 2 years ago. #41487 was a boil down of the lengthy and intransparent discussion that took place here.

Thanks!