Bug #53002
closedCalculation of GIFBUILDER object properties using stdWrap fails
100%
Description
Hey,
I stumbled upon a juicy bug in GIFBUILDER which is somehow related to #41487.
Short description:
Whenever GIFBUILDER object properties are modified with stdWrap, they can not make use of calculations anymore. If calculations are used, they will fail (return wrong values).
Long description
An IMAGE-Object made with GIFBUILDER is requested. Lets say I use the offset-parameter and overwrite it, if a certain condition is met.
10 = IMAGE 10 { file = GIFBUILDER file { XY = 300,225 format = jpg quality = 90 10 = IMAGE 10 { file = fileadmin/user_upload/someimage.png file.maxW = 640 file.minW.override = 300 offset = 300-[10.w]/2,225-[10.h]/2 offset.override = 640-[10.w]/2,225-[10.h]/2 offset.override.if.isTrue.field = tx_myext_somefield } } }
This request calls GifBuilder->start() (see http://api.typo3.org/typo3cms/60/html/_gif_builder_8php_source.html). In this method some GifBuilder-properties like boundingbox, dimensions and offset will be calculated for the object itself, as well as for all child-objects (1,2,3,40,50,60… 10 in my case)
On line 268 the offset-properties is modified with stdWrap, if existing. The bug is caused here, but let's keep going. Now the calculations start, and will return correct values!
Next. In GifBuilder->make() the image is created and all GifBuilder-Objects are rendered. On line 406 »stdWrap« is applied again to every GifBuilder-Object. But the calculations are not repeated as required. The bug is now in effect, since the next method will simply do an intval() on the parameter and therefore cause wrong values.
In my example the offset-parameter will look like this:
(start) = 300-[10.w]/2,225-[10.h]/2 (override) = 640-[10.w]/2,225-[10.h]/2 (calc) = 150,75 (override again) = 640-[10.w]/2,225-[10.h]/2 (intval) = 640,225
Solution:
Either change the stdWrap-loop on line 406 and exclude all properties with calculations (offset,dimensions,set,…), or change the calculation-loop and unset all »[key].«-arrays.
I have a patch for the latter solution and can send it to gerrit.
The bug effects all TYPO3 versions since 4.5.
Updated by Gerrit Code Review about 11 years ago
- Status changed from New to Under Review
Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/24923
Updated by Wouter Wolters almost 10 years ago
- Status changed from Under Review to Needs Feedback
Updated by Gerrit Code Review almost 10 years ago
- Status changed from Needs Feedback to Under Review
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/24923
Updated by Dan Kleine (Untenzu) almost 10 years ago
In case anybody wants to review this one… Easier example than the one above:
Save http://i.imgur.com/oonUTii.png to /fileadmin/user_upload/someimage.png
Use this TypoScript:
10 = IMAGE 10 { file = GIFBUILDER file { XY = 300,225 format = jpg 10 = IMAGE 10 { file = fileadmin/user_upload/someimage.png file.maxW = 800 offset = 150-150,-50 offset.override = 150-300,-50 } } }»offset« parameter looks like this:
- (start) = 150-150,-50
- (override) = 150-300,-50
- (calc) = -150,-50
- (override again - which is the bug, this should not happen) = 150-300,-50
- (intval) = 150,-50
- Result…
- with the patch: -150,-50 (image is set off to the left, you see "omei")
- without the patch (left half of the image is white, all you see is "s"): 150,-50
Updated by Daniel Goerz over 9 years ago
- Target version set to 7.5
- Sprint Focus set to On Location Sprint
Updated by Anja Leichsenring over 9 years ago
- Sprint Focus changed from On Location Sprint to Remote Sprint
Updated by Gerrit Code Review over 9 years ago
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/42639
Updated by Dan Kleine (Untenzu) over 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset aa1b84416e9952ae05d0533069ebcd6b19773f76.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed