Contao: Einige Bilder im webp-Format werden angezeigt, andere nicht

Created on 28 Feb 2020 · 30Comments · Source: contao/contao

Affected version(s)
Contao 4.9.0 und 4.9.1
Description
Einige Bilder als webp werden angezeigt, andere nicht.
Was ich bisher eingrenzen konnte. Im Chrome ( Version 80.0.3987.122 (Offizieller Build) (64-Bit) ) wird das Bild nicht angezeigt, in Firefox ( 73.0.1 (64-Bit) ) und Firefox ( 74.0b9 (64-Bit) ) unter MacOS schon.
Könnte es was mit dem „lazy-load”-Attribut zu tun haben, das bisher nur im Chrome unterstützt wird?

Das Phänomen ist in 4.9.0 und auch in 4.9.1 unverändert zu beobachten…

Installiert ist das Bundle https://packagist.org/packages/postyou/contao-webp-bundle

In Chrome, Opera, Vivaldi wird das Bild nicht angezeigt, in Firefox und Safari ( Version 11.1.2 (11605.3.8.1) ) wird es angezeigt:
Beispiel: https://www.weitzeldesign.com/portfo...stuttgart.html
How to reproduce
Aktuell nur die Website als Beispiel.
Forenlink: https://community.contao.org/de/showthread.php?77301-Manche-Bilder-werden-bei-WEBP-Konvertierung-nicht-angezeigt

Source

planepix

Most helpful comment

Habe auch diese Antwort erhalten und mal den "Umzug" beauftragt.

🤞

Werde morgen berichten.

m-knorr on 2 Mar 2020

👍2

All 30 comments

Bei mir tritt der Fehler auch auf. Habe ich im Forum ja bereits geschrieben. Siehe auch hier: https://c49.philippseibt.com/ (heute auf Contao 4.9 aktualisiert und webp bei den Bildgrößen aktiviert)

Das contao-webp-bundle habe ich aber nicht installiert.

seibtph on 28 Feb 2020

👍1

Bei beiden Websites scheinen die Content-Type-Header für die WebP Bilder zu fehlen. Falls ihr Apache nutzt, fehlt eventuell ein Eintrag wie folgender:

<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>

ausi on 29 Feb 2020

👍1

Hat bei mir leider nicht geholfen.

seibtph on 29 Feb 2020

Hallo Martin, besten Dank für deinen Tipp.
Habe deine Codezeilen in der htaccess ergänzt, Cache neu aufgebaut. Wie bei @seibtph keine Änderungen.

Habe ich das an falscher Stelle ( am Ende der htaccess ) eingetragen?

planepix on 29 Feb 2020

Ich hab mir jetzt mal die Bilder genauer angesehen und bemerkt, dass die Dateien jeweils um genau ein Byte zu kurz sind. Im WEBP-Header ist jeweils die Größe des Bildes in Byte angegeben und diese stimmt bei euren Bildern nicht. Es fehlt also entweder ein Byte oder die Länge im Header ist falsch angegeben.

Anscheinend kommt Firefox damit zurecht, Chrome bricht aber die Darstellung aufgrund des Fehlers ab.

Welche Image-Library wird in eueren Installationen benützt? Das könnt ihr rausfinden indem ihr folgenden Command ausführt:

vendor/bin/contao-console debug:container contao.image.imagine | grep Class

ausi on 1 Mar 2020

Besten Dank für deine Rückmeldung Martin.
Ich erhalte zurück:

Imagine\Gd\Imagine

planepix on 1 Mar 2020

Welche „GD library Version“ setzt du ein? Kann über den Manager unter „Tools › PHP-Informationen“ abgefragt werden.

ausi on 1 Mar 2020

GD 2.1.1 - Webp enabled
Imagick 3.4.4

planepix on 1 Mar 2020

@seibtph wie ist deine GD version?

ausi on 1 Mar 2020

Das 1 Byte Phänomen hatte ich auch schon beobachtet. Bei einem Kunden war‘s ein <?php (also ein Leerzeichen vor dem öffnenden <?php) in der localconfig.php. Aber es könnte auch sonst in einem File sein, das inkludiert wird :)

Toflar on 1 Mar 2020

Hier fehlt aber am Ende ein Byte, denke nicht dass das durch eine falsche php-file kommt.

ausi on 1 Mar 2020

Ist ein Versuch Wert ;)

Toflar on 1 Mar 2020

Im Verzeichnis „system/config” liegen drei Dateien:

„cmsconfig.php” von der Marketing Suite
„dcaconfig.php”
„localconfig.php”

In allen drei Datei ist kein Leerzeichen vor <?php

planepix on 1 Mar 2020

@planepix kannst du bitte die Datei assets/images/5/zon-stuttgart-8d6b5c69.webp von deinem Webspace per SFTP herunterladen und prüfen wie groß die Datei in Bytes ist, 44.085 oder 44.086?

ausi on 1 Mar 2020

Die Information im Finder (Mac OS) liefert 44.085 Byte.
Bildschirmfoto 2020-03-01 um 23 03 23

planepix on 1 Mar 2020

Gleiches Problem bei einer Seite die auf Apache läuft.

Nginx scheint keine Probleme zu machen.

Verwendete Klasse: Imagine\Gd\Imagine

GD Support: enabled
GD headers Version: 2.1.1
GD library Version: 2.1.1

m-knorr on 2 Mar 2020

Interessant. Scheint als würde Apache einfach ein Byte abschneiden :)
Läuft da evtl. mod_pagespeed? Wenn ja, führt das Deaktivieren des Moduls zu einer Veränderung?

Toflar on 2 Mar 2020

Haben kein mod_pagespeed drauf!

m-knorr on 2 Mar 2020

Ich vermute es ist ein bug in der GD version 2.1.1. Verschwindet der Fehler wenn ihr die gdlib aktualisiert?

ausi on 2 Mar 2020

Da habe ich leider keinen Zugriff drauf, da Managed Hosting. 😢

Werde aber mal den Support anschreiben.

m-knorr on 2 Mar 2020

👍1

Warte nun mal auf die Rückmeldung von all-inkl.

An welcher Änderung könnte es denn liegen dass es in 4.8 lief und die 4.9 das entsprechende Problem aufzeigt?

LazyLoading ist ja nur ein hinzugefügtes Attribut auf Template Ebene und hat ja nichts mit der Erstellung der Bilder zu tun! 🤔

m-knorr on 2 Mar 2020

An welcher Änderung könnte es denn liegen dass es in 4.8 lief und die 4.9 das entsprechende Problem aufzeigt?

Das Problem sollte eigentlich nicht mit der Contao-Version zusammenhängen wenn es an der gdlib liegt. War die 4.8-Installation mit der selben PHP-Version?

ausi on 2 Mar 2020

@ausi Bei mir ist auch die GD-Version 2.1.1 installiert und bin auch bei all-inkl, da kann ich die Version selber nicht beeinflussen. Mal gucken was bei der Support-Anfrage von @m-knorr herauskommt. Unter Contao 4.8 habe ich es nicht getestet, hatte gleich von der 4.7 auf die 4.9 geupdated.

seibtph on 2 Mar 2020

Ich vermute es ist ein bug in der GD version 2.1.1. Verschwindet der Fehler wenn ihr die gdlib aktualisiert?

Als ich Deine Nachricht hier gelesen hab, hab ich dem Support geschrieben, mit Verweis auf diesen Thread. Hier die Antwort:

[...] vielen Dank für Ihre Anfrage.

Auf aktuelleren Betriebssystemen steht auch eine aktuellere Version der GDLib zur Verfügung.

Wir bieten auch Server unter Ubuntu 18 mit PHP 7.2 / MySQL 5.7 und Apache 2.4 (http/2, OPcache Unterstützung) an und können Ihren Account gern kostenlos auf solch einen Server umziehen. [...]

Ich täte sagen: morgen sieht man mehr :-)

Nightwing0815 on 2 Mar 2020

Habe auch diese Antwort erhalten und mal den "Umzug" beauftragt.

🤞

Werde morgen berichten.

m-knorr on 2 Mar 2020

👍2

Guten morgen,

der Serverumzug ist erfolgt und ergibt folgende Version:

GD library Version 2.2.5 & imagick module version 3.4.4

Firefox Desktop zeigt trotzdem *.jpg, obwohl *.webp aktiviert ist (Werte in about:config):

image.http.accept image/webp,/ & image.webp.enabled true

Firefox Beta Android zeigt *.webp

Seite: https://uracher-schaeferreigen.de/bilder/

Nightwing0815 on 3 Mar 2020

Guten morgen,

auch hier ist der Umzug erfolgt.

GD Support | enabled
GD headers Version | 2.2.5
GD library Version | 2.2.5

Chrome zeigt die Bilder nun wieder an - also ist das Grundproblem durch die aktualisierte GD Version behoben.

Im Firefox 73.0.1 (64-Bit) werden bei uns die Bilder auch als webp genutzt - da bestand auch vorher kein Problem.

m-knorr on 3 Mar 2020

@Nightwing0815 Poste die URLs zu den WebP Bildern, die nicht angezeigt werden.

fritzmg on 3 Mar 2020

@fritzmg der Direktaufruf funktioniert, aber sollte er nicht das .webp dem .jpg vorziehen?
Link: https://uracher-schaeferreigen.de/assets/images/e/06_bilder-2e0815bf.webp
und das hier meine ich:
Unbenannt
Oder verstehe ich das Feature falsch? Wie gesagt, Firefox Beta Android, selbst auf Desktop gestellt, nimmt .webp?!?