Bug #40254
closed
Empty return value in uri.image view helper
Added by Michael Grundkötter over 11 years ago.
Updated over 8 years ago.
Description
The render() Method in Tx_Fluid_ViewHelpers_Uri_ImageViewHelper contains these lines:
$imageInfo = $this->contentObject->getImgResource($src, $setup);
...
$imageInfo[3] = t3lib_div::png_to_gif_by_imagemagick($imageInfo[3]);
Problem is, that tslib_cObj::getImgResource() does not return numeric indices in the return array, but string indices ($imageInfo['origFile'] instead of $imageInfo3). Thus, the return value of this view helper is always empty. If I simply change that line to:
$imageInfo[3] = t3lib_div::png_to_gif_by_imagemagick($imageInfo['origFile']);
it works again. (the "fix" should be a little better, of course).
- Status changed from New to Needs Feedback
- Priority changed from Must have to -- undefined --
I tried it on current master with
<f:uri.image src="EXT:myext/Resources/Public/Img/my.gif" />
and the result correctly was
typo3conf/ext/EXT:myext/Resources/Public/Img/my.gif
it also works with png files and the setting $GLOBALS['TYPO3_CONF_VARS']['FE']['png_to_gif'] = 1;
What exactly are the steps to reproduce this error?
This only occurs, if image magick is not used/available. I know it is not that case that often, but at least the original image should be used instead of generating an empty return string as url.
You may reproduce it, setting the im path values in localconf to '' or something else.
A simple check whether the array index 3 is !empty should be enough to decide to use the index origFile instead.
Which version do you use? I can not reproduce this on current master.
Please provide further information so we have the chance to reproduce it.
- Project changed from 534 to 2559
- Category changed from 963 to Fluid: ViewHelpers
- Status changed from Needs Feedback to New
- Priority changed from -- undefined -- to Could have
- Target version set to Fluid 6.2
- Complexity set to easy
I see, the most important information here is "This only occurs, if image magick is not used/available. "
So, let's discuss the proposed fallback using the original image.
- Target version deleted (
Fluid 6.2)
- Complexity deleted (
easy)
- Project changed from 2559 to TYPO3 Core
- Category changed from Fluid: ViewHelpers to Fluid
- TYPO3 Version set to 6.2
- Is Regression set to No
Someone might want to confirm this as fixed on non-LTS versions. It has been a while but I'm quite sure that last time I tried to run a 6.2+ TYPO3 without GraphicsMagic, f:image was correctly returning the original image when unable to scale. All of the code mentioned in this report is no longer relevant as the ImageService is now used to wrap around image scaling functions - so this should mean that TYPO3 defaults to original image everywhere, not just in f:image and others.
If I'm right, this issue can be closed.
- Status changed from New 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/44138
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44138
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44138
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/44138
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Rejected
This issue is not easily solvable if the image processing is disable/broken as there are many edge cases where the browser is not able to scale the same way as image processing does.
This issue won't be fixed for now in the core.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by Anonymous 
Updated by