Project

General

Profile

Actions
Copy link

Bug #40254

closed

Empty return value in uri.image view helper

Added by Michael Grundkötter about 12 years ago. Updated about 9 years ago.

Status:
Rejected
Priority:
Could have
Assignee:
-
Category:
Fluid
Target version:
-
Start date:
2012-08-27
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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

Related issues 1 (0 open — 1 closed)

Related to TYPO3 Core - Bug #71576: Image Processing brokenClosedMorton Jonuschat2015-11-14

Actions
Actions
Copy link
 #1

Updated by Ingo Pfennigstorf about 12 years ago

  • 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?

Actions
Copy link
 #2

Updated by Michael Grundkötter about 12 years ago

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.

Actions
Copy link
 #3

Updated by Ingo Pfennigstorf about 12 years ago

Which version do you use? I can not reproduce this on current master.

Actions
Copy link
 #4

Updated by Alexander Schnitzler about 12 years ago

Please provide further information so we have the chance to reproduce it.

Actions
Copy link
 #5

Updated by Anja Leichsenring almost 12 years ago

  • Project changed from 534 to 2559
  • Category changed from 963 to Fluid: ViewHelpers
Actions
Copy link
 #6

Updated by Alexander Schnitzler over 11 years ago

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

Actions
Copy link
 #7

Updated by Marc Bastian Heinrichs almost 11 years ago

  • Target version deleted (Fluid 6.2)
  • Complexity deleted (easy)
Actions
Copy link
 #8

Updated by Alexander Opitz about 10 years ago

  • 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
Actions
Copy link
 #9

Updated by Claus Due about 9 years ago

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.

Actions
Copy link
 #10

Updated by Gerrit Code Review about 9 years ago

  • 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

Actions
Copy link
 #11

Updated by Gerrit Code Review about 9 years ago

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

Actions
Copy link
 #12

Updated by Gerrit Code Review about 9 years ago

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

Actions
Copy link
 #13

Updated by Gerrit Code Review about 9 years ago

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

Actions
Copy link
 #14

Updated by Gerrit Code Review about 9 years ago

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44138

Actions
Copy link
 #15

Updated by Gerrit Code Review about 9 years ago

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/44138

Actions
Copy link
 #16

Updated by Anonymous about 9 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions
Copy link
 #17

Updated by Morton Jonuschat about 9 years ago

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

Actions
Copy link

Also available in: Atom PDF