no responsive image is generated

Question

no responsive image is generated

Closed this issue 7 years ago · 28 comments

Hello,

it doesn't work (fluid_styled_responsive_images Version 1.1.1).

I've included the follwing static templates:
Content Elements (fluid_styled_content)
Content Elements CSS (optional) (fluid_styled_content)
Fluid Styled Responsive Images (fluid_styled_responsive_images)

into my TYPO3 7.6.6.

TypoScript-Setup:

tt_content.textmedia.settings.responsive_image_rendering.sourceCollection {
  small {
    width = 360m
    srcset = 360w
    sizes = 100vw
  }
  medium {
   width = 720m
    srcset = 720w
    sizes = 100vw
  }
  large {
    width = 940m
    srcset = 940w
    sizes = 100vw
  }
  bigger {
    width = 1140m
    srcset = 1140w
    sizes = 100vw
  }
}

No image is rendered to the srcset-attribute in the textmedia-elemtent:

<div class="ce-textpic ce-left ce-intext">
    <div class="ce-gallery" data-ce-columns="1" data-ce-images="1">
        <div class="ce-row">
            <div class="ce-column">
                <figure>    
                    <img sizes="100vw, 100vw, 100vw, 100vw" title="Titel Dateiebene" alt="Alternativer Text Dateiebene" src="fileadmin/_processed_/1/8/csm_DSC02028_067a75714b.jpg">
                    <figcaption>
                        Beschreibung Dateiebene
                    </figcaption>
                </figure>
[...]

If I set the width-settings to a comment,:

tt_content.textmedia.settings.responsive_image_rendering.sourceCollection {
  small {
#    width = 360m
    srcset = 360w
    sizes = 100vw
  }
  medium {
#   width = 720m
    srcset = 720w
    sizes = 100vw
  }
  large {
#    width = 940m
    srcset = 940w
    sizes = 100vw
  }
  bigger {
#    width = 1140m
    srcset = 1140w
    sizes = 100vw
  }
}

I get the following img-tag with srcset-attribute, but again no scaled image is generated:

[...]
<img sizes="100vw, 100vw, 100vw, 100vw" srcset="fileadmin/user_upload/images/DSC02028.JPG 360w, fileadmin/user_upload/images/DSC02028.JPG 720w, fileadmin/user_upload/images/DSC02028.JPG 940w, fileadmin/user_upload/images/DSC02028.JPG 1140w" title="Titel Dateiebene" alt="Alternativer Text Dateiebene" src="fileadmin/_processed_/1/8/csm_DSC02028_067a75714b.jpg">
[...]

Answer 1 · 2016-05-23T17:13:17.000Z

I guess the actual image width is smaller than the one you want to generate. Then it doesn't make sense processing an image. It's possible to downscale an image, but you can't properly upscale it.

Please have a look at the image width.

Answer 2 · 2016-05-28T17:24:23.000Z

It still does not work, I updated to TYPO3 7.6.9 and fluid_styled_responsive_images V1.2.0.
The image is not the problem, it is 3.32 MB, 4.608px × 3.456px.

The images aren’t rendered in the code:

<figure>
    <img src="fileadmin/_processed_/1/8/csm_DSC02028_067a75714b.jpg" alt="Alternativer Text Dateiebene" title="Titel Dateiebene" srcset="fileadmin/user_upload/images/DSC02028.JPG 360w, fileadmin/user_upload/images/DSC02028.JPG 720w, fileadmin/user_upload/images/DSC02028.JPG 940w, fileadmin/user_upload/images/DSC02028.JPG 1140w" sizes="100vw, 100vw, 100vw, 100vw" />
    <figcaption>Beschreibung Dateiebene</figcaption>
</figure>

Answer 3 · 2016-06-03T07:45:15.000Z

If that is the output of my extension, that it worked well. You have all srcset entries, as defined in the configuration. If an image is big enough and you define smaller image widths, then the extension simply calls a core process with these params, so it processes the file.

Did you check that imagemagick/graphicsmagick is properly installed and configured in your installation?

Answer 4 · 2016-06-03T10:18:10.000Z

Sorry, I don’t get it. It does not work in my opinion, the large image is not processed to its smaller variants, only the original file is referenced in all parts of the srcset-attribute.

I just checked the image processing in the install tool, there is no problem with:
Convert image formats to jpg
Writing gif and png
Scaling images
Combining images
Only the nice text and shadow under option in the GDlib-part do not work.

You can get access to my sandbox to check it, I would be pleased.

Answer 5 · 2016-06-03T10:27:24.000Z

I believe you. That's not the issue here. I simply can't reproduce it in my environment and I didn't have such issues when I used this extension in production. What I'd need to solve this, is a reliable and reproducible case where I can debug the problem with xdebug. Because, what my extension really just does, is calling the core processing method with an image width.

You are not the first and not the only one with this issue, so I guess there is a bug somewhere, but currently I don't see what I can do about it.

What you could do:
See if that issue is depending on the image file. Does that happen only with specific images and reliably in all instances?

Is that issue depending on the GFX settings of TYPO3? Maybe you have both imagemagick and graphicsmagick and can test if just one of these fail.

However, please let me know:

The TYPO3 version.
The imagemagick/graphicsmagick version
The OS
Your GFX settings.

And last but nor least, please upload the exact failing image.

Then I can try to reproduce that locally and find a fix for that issue.
Thanks.

Answer 6 · 2016-06-03T15:08:48.000Z

I tried the following images with the same problem:
https://upload.wikimedia.org/wikipedia/commons/e/e1/The_Lady_with_an_Ermine.jpg
https://upload.wikimedia.org/wikipedia/commons/8/81/Max_Bense_Raum_und_Ich_1934.JPG

TYPO3 CMS 7.6.9
fluid_styled_responsive_images 1.2.0

> convert --help
Version: ImageMagick 6.6.0-4 2015-11-27 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP

Usage: convert [options ...] file [ [options ...] file ...] [options ...] file
[…]

I can’t switch the graphics library because this is a shared hosting package.

Operating system: Unix
PHP version: 7.0.6
PHP CGI detected: Yes

Apache/2.2.22
Server Version: 5.1.73-log - MySQL Community Server (GPL)
Datenbank-Client Version: libmysql - mysqlnd 5.0.10 - 20111026

> lsb_release -a:
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.10 (squeeze)
Release:        6.0.10
Codename:       squeeze

[GFX][image_processing] = 1
[GFX][thumbnails] = 1
[GFX][thumbnails_png]
[GFX][gif_compress] = 1
[GFX][imagefile_ext] = gif,jpg,jpeg,tif,tiff,bmp,pcx,tga,png,pd
[GFX][gdlib] = 1
[GFX][gdlib_png] = 0
[GFX][im] = 1
[GFX][im_path] = /usr/bin/
[GFX][im_path_lzw] = /usr/bin/
[GFX][im_version_5] = im6
[GFX][im_v5effects] = 1
[GFX][im_mask_temp_ext_gif] = 1
[GFX][im_noScaleUp] = 0
[GFX][im_noFramePrepended] = 0
[GFX][im_stripProfileCommand] = +profile '*'
[GFX][im_useStripProfileByDefault] = 1
[GFX][jpg_quality] = 80
[GFX][png_truecolor] = 1
[GFX][colorspace] = sRGB

Answer 7 · 2016-06-03T15:14:25.000Z

thx, will try it this weekend.

Answer 8 · 2016-06-03T16:42:05.000Z

As a first test, I checked if the image is the issue. At least not in my local installation.

Answer 9 · 2016-06-03T16:55:17.000Z

I finally found a case where you get this exact html code:
<img src="fileadmin/The_Lady_with_an_Ermine.jpg" alt="" title="" sizes="100vw, 100vw, 100vw, 100vw">

It always happens, when processed images cannot be created or written. Please check that files can be created in fileadmin/_processed_/.

Answer 10 · 2016-06-03T17:06:19.000Z

Forget about that comment. Just saw that you have images in the srcset, just not processed. So it's not that the processing fails with an exception. But still I am sure that the processing doesn't work and simply returns the original file path. There is no other possible reason for that. In any case of an exception during the processing of images, the extension completely skips that processed image.

If you look at this line (https://github.com/alexanderschnitzler/fluid-styled-responsive-images/blob/master/Classes/Resource/Rendering/ImageRenderer.php#L192) you will see that the original image is processed and returns a ProcessedFile. Can you debug that on your server and check the following?

You really get back instances of ProcessedFile (get_class($processedFile)).
The core creates database entries in sys_file_processedfile. If so, is the original file path stored as identifier for the processed files?
$localProcessingConfiguration is not empty at that point. It must contain a width attribute IIRC.

Answer 11 · 2016-06-03T18:15:35.000Z

I’m sorry, I’m not an extension developer. I don’t know how to check that.

Answer 12 · 2016-06-04T11:44:17.000Z

Then I don't know how to help you any further. Sorry.

Answer 13 · 2016-06-04T12:57:03.000Z

Maybe you can give me some hint or code snippet that I can place inside the code to dump objects or variables for debugging. Thx.

Other guess: Do you have the extension ws_textmedia_bootstrap with it’s static template activated?

Answer 14 · 2016-06-07T07:47:37.000Z

Can't you find someone who can shortly check all that for you? Just looking at the database and inserting the mentioned php snippet.

PS: I don't have that extension installed.

Answer 15 · 2016-06-07T08:17:55.000Z

The extension is just a thin wrapper, provides some base configuration for fluid styled responsive images and passes everything to the f:media ViewHelper.

You should be able to verify an assumption that there's something fishy with ws_texmedia_bootstrap by simply disabling the extension.

Answer 16 · 2016-06-12T10:31:34.000Z

@cedricziel THX, I’m pretty much aware of interferencing extensions and how to avoid that.

@alexanderschnitzler

I tested the following:

I uploaded a new pic (4608 x 3456px) and created an new content element type text & media and inserted the new image.

The original image is placed at:
fileadmin/user_upload/images/DSC02031.JPG

The rendered HTML code:

<div class="ce-column">
    <figure>
        <img sizes="100vw, 100vw, 100vw, 100vw" srcset="fileadmin/user_upload/images/DSC02031.JPG 360w, fileadmin/user_upload/images/DSC02031.JPG 720w, fileadmin/user_upload/images/DSC02031.JPG 940w, fileadmin/user_upload/images/DSC02031.JPG 1140w" title="Titel" alt="Alternativer Text" src="fileadmin/_processed_/8/3/csm_DSC02031_96c3428d11.jpg">
        <figcaption>
            Beschreibung
        </figcaption>
    </figure>
</div>

TYPO3 added the following five entries to the table sys_file_processedfile:

to screenshot

Dumping the following,

var_dump(get_class($processedFile));
var_dump($localProcessingConfiguration);

I got:

string(37) "TYPO3\CMS\Core\Resource\ProcessedFile"
array(2) {
  ["width"]=>
  NULL
  ["crop"]=>
  string(0) ""
}

string(37) "TYPO3\CMS\Core\Resource\ProcessedFile"
array(2) {
  ["width"]=>
  NULL
  ["crop"]=>
  string(0) ""
}

string(37) "TYPO3\CMS\Core\Resource\ProcessedFile"
array(2) {
  ["width"]=>
  NULL
  ["crop"]=>
  string(0) ""
}

string(37) "TYPO3\CMS\Core\Resource\ProcessedFile"
array(2) {
  ["width"]=>
  NULL
  ["crop"]=>
  string(0) ""
}

HTH

Karionis

Answer 17 · 2016-06-13T09:26:40.000Z

Thanks for the info. It really helps a lot.

First of all I don't think that the screenshot shows the right processed images. It looks more like entries, created from the backend. But it's not a problem as I already see the actual issue.

$localProcessingConfiguration has an invalid width. So, I am very sorry, but it seems that it's rather the extension and not the TYPO3 core that has a bug. Still I don't know how that is possible but I will investigate this.

Answer 18 · 2016-06-13T10:39:46.000Z

That’s probably because I commented the width settings:

# für fluid_styled_responsive_images
tt_content.textmedia.settings.responsive_image_rendering.sourceCollection {
  small {
#    width = 360m
    srcset = 360w
    sizes = 100vw
  }
  medium {
#   width = 720m
    srcset = 720w
    sizes = 100vw
  }
  large {
#    width = 940m
    srcset = 940w
    sizes = 100vw
  }
  bigger {
#    width = 1140m
    srcset = 1140w
    sizes = 100vw
  }
}

I did that because there’s no rendering of responsive images in the image tag at all when setting (uncommenting) the widths:

<div data-ce-images="1" data-ce-columns="1" class="ce-gallery">
    <div class="ce-row">
        <div class="ce-column">
            <figure>    
                <img sizes="100vw, 100vw, 100vw, 100vw" title="Titel" alt="Alternativer Text" src="fileadmin/_processed_/8/3/csm_DSC02031_96c3428d11.jpg">
[…]

In this case the var_dump command isn’t even executed…

Answer 19 · 2016-06-13T11:50:12.000Z

Don't get me wrong but this consumes a lot of time and now finding out that I am searching for an error at the completely wrong place while you simply commented out the width definition really makes me angry. For sure a width definition is needed. Why didn't you tell me so? Now, we start from scratch...

As this gets more and more time consuming it would be best if you (temporarily) gave me access to the server where you experience that bug. Meanwhile you can also use the latest version in develop which adds logging of errors, so one can look at a log file for debugging quite obvious errors like missing/wrong configuration.

Answer 20 · 2016-06-13T12:10:25.000Z

Dont’ get me wrong, but

in my first posting I posted my TypoScript settings with the rendering in the frontend for both scenarios (≈ told you so).
I offered you access to my installation in my third posting.

Take me serious. Thanks.

I’ll try to get the developer version and provide you access.

Karionis

Answer 21 · 2016-06-13T13:50:41.000Z

Yes, you described both scenarios but who would think we are talking about the case where you leave out the image widths? How would you scale images if no image width is given? Isn't it logical that this case cannot work anyway? Whatever...

It might sound strange but I will need ssh access, so I can debug the codebase on the server. I can give you my public key, so you can easily remove access afterwards. Is that manageable?

Answer 22 · 2016-06-13T14:52:52.000Z

Found the root of all evil!

Before the responsive images are created the TYPO3\CMS\Frontend\DataProcessing\GalleryProcessor does it's job, processes the given image (default width 300px) and therefore all further processings fail because the image is too small.

I recommend setting these highlighted values to a very high number, like 6000.

Answer 23 · 2016-06-13T14:57:07.000Z

This ticket is kind of a duplicate for #8

Answer 24 · 2016-06-13T15:27:38.000Z

Nice! Many thanks!

Hmm, those settings should be mentionied in the documentation or will that be part of the static template of the next version?

Cheers

Karionis

Answer 25 · 2016-06-13T15:33:00.000Z

Problem is, that this is not my setting. And that GalleryProcessor is a core thing which processes images before this extension renders all other versions. I am thinking about that for a while now and I guess the best solution is to not rely on the given image but use the physical image width instead and make all that an option.

Answer 26 · 2016-06-13T15:44:54.000Z

I see the difficulties now, why is there no support for responsive images like version 6.2.x which can be easily selected in the constants editor? Is it planned?

Answer 27 · 2016-06-13T15:52:30.000Z

The reason is that you use fluid_styled_content instead of css_styled_content and people didn't think of responsive images. There has been a code sprint lately, so maybe there will be something in the core some day. For now you need an extension unfortunately.

Answer 28 · 2016-06-13T15:53:25.000Z

I don't think that there will be an extension like that in < 7.4 and i think that using the real image dimensions is not the best option, because then you have no real control of the generated results. For example: if there is an image with the width of 6000 pixel, TYPO3 will always process ALL images defined in your srcset, regardless of what TYPO3 (or any other extensions which extend or replace the GalleryProcessor) choose as possible maximum width.
I wrote an extension for bootstrap components which replaces the GalleryProcessor (https://github.com/sonority/bootstrap_components) and in this case, the extensions decides which will be the best maximum width of an image (relative to text/grid). A change like that would possible break other things/extensions which are able to handle (maximum) image-sizes.

But you are right: there is definitly a need of responsive image handling in TYPO3!