Einige Bilder im webp-Format werden angezeigt, andere nicht

[planepix]

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

[seibtph]

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

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

[ausi]

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>

[seibtph]

Hat bei mir leider nicht geholfen.

[planepix]

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?

[ausi]

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

[planepix]

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

Imagine\Gd\Imagine

[ausi]

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

[planepix]

GD 2.1.1 - Webp enabled
Imagick 3.4.4

[ausi]

@seibtph wie ist deine GD version?

[Toflar]

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

[ausi]

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

[Toflar]

Ist ein Versuch Wert ;)

[planepix]

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

[ausi]

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

[planepix]

Die Information im Finder (Mac OS) liefert 44.085 Byte.

[m-knorr]

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

[Toflar]

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?

[m-knorr]

Haben kein mod_pagespeed drauf!

[ausi]

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

[m-knorr]

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

Werde aber mal den Support anschreiben.

[m-knorr]

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! 🤔

[ausi]

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?

[seibtph]

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

[Nightwing0815]

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

[m-knorr]

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

🤞

Werde morgen berichten.

[Nightwing0815]

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/

[m-knorr]

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.

[fritzmg]

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

[Nightwing0815]

@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:

Oder verstehe ich das Feature falsch? Wie gesagt, Firefox Beta Android, selbst auf Desktop gestellt, nimmt .webp?!?

[fritzmg]

Wenn die URL funktioniert, ist das ursprüngliche Problem behoben.