Mal wieder: Miese Bildqualität EKW

Shopware 5 Themes & Design
1

Schönes WE,

ich weiß: altes Thema - gibt es auch viele Threads zu - aber nach wie vor aktuell - und noch immer nicht gelöst.
Heute wird bemängelt: Die Bildqualität von Artikelbildern im Kategorie-Teaser bei Zufallsartikel bei „mobilen Ansichten“ und Tablet.
Es wird schlicht das 200x200-Thumbnail genommen - und hoskaliert. Alleine schon die kleinste Ansicht auf Smartphone ist aber schon über 300 Pixel breit.

Gucken wir mal in den Quellcode:
 

#teaser--{$Data.objectId} {
                        background-image: url('{$images[0].source}');
                    }

                    {if isset($images[0].retinaSource)}
                    @media screen and (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
                        #teaser--{$Data.objectId} {
                            background-image: url('{$images[0].retinaSource}');
                        }
                    }
                    {/if}

                    @media screen and (min-width: 48em) {
                        #teaser--{$Data.objectId} {
                            background-image: url('{$images[1].source}');
                        }
                    }

Hier mal ein Ergebnis aus der realen Welt: 

#teaser--a209ca7b50dcaab2db7c2d4d1223d4d5 {background-image: url('https://www.xxxx.de/media/image/4b/a3/96/hcs-11_200x200.jpg');}@media screen and (min-width: 48em) {#teaser--a209ca7b50dcaab2db7c2d4d1223d4d5 {background-image: url('https://www.xxxx.de/media/image/db/08/71/hcs-11_600x600.jpg');}}@media screen and (min-width: 78.75em) {.is--fullscreen #teaser--a209ca7b50dcaab2db7c2d4d1223d4d5 {background-image: url('https://www.xxxx.de/media/image/f3/97/10/hcs-11_1280x1280.jpg');}}

Der erste Brakepoint ist bei 48 em - warum em und nicht rem?
Nehmen wir mal an, 48em sind wie 48rem - dann wären wir in Responsive schon bei 768px - ab 768px wird dann also das 600x600px Bild genommen, bis 48em 200x200 - ungeachtet, wie breit das EKW-Element innerhalb der EKW eigentlich ist. Obiges Beispiel geht über die ganze Breite beim Smartphone - sonst sieht man ja auch nix. Das Problem ist, dass hier die Media-Einstellungen der Artikel-Folder gelten, und nicht die der Einkaufswelten.
Leute - das ist einfach Murks - da müsst Ihr noch mal ran.
Kein Wunder, dass Artikelbilder in EKW-Kategorieteaser auf Mobile, Mobile-quer und Tab SCHEISSE aussehen, wenn 200x200 auf über 600x600 hoskaliert werden!
*Nächste Woche erstmal die Widget-tpl umbauen*

Ahso: SW 5.4.2

Ggf. sollte man den ganzen Aufbau überdenken, ob die Artikelbilder wirklich als Hintergrundbild eingebunden werden sollen, oder nicht doch besser als Blockelement. Dann kann man auch wieder src-sets nehmen - und gut is… Der ganze Inline-Style ist ja nun auch… ich sach mal nix.

Edit: Hier zeigen sich übrigens die eklatanten Designschwächen von Shopware im Thumbnail / Mediamanager-Konzept.
Das nächste Image wäre bei 600x600px - da würde bei 300x300px wohl Tante Google rummoppern. Blöd nur - das jetzt für Artikel nicht die EKW-Thumbnails zur Verfügung stehen.

2

Das größte Problem ist übrigens der „Zeilenmodus“, da hier für „Kategorieteaser“ eine " feste Höhe von 360px" vorgegeben ist. Dazu noch " background-size: cover" - es wird also immer so eingepasst, dass das Bild vollflächig die Box füllt. So wird das Bild bis 48em immer um den Faktor 1.8 hochskaliert, wenn die Box breiter als 360px wird, sogar noch stärker.
Ein anderes „Thumbnail“ zwischen 600 und 200 gibt es so aber nicht *dumm gelaufen* - bräuchte man hier doch ein 360x360.
Jetzt müsste man sich für die Artikel noch ein weiteres Thumbnail anlegen und „images[0]“ im Code ersetzen. Für vielleicht ein paar wenige Artikel je nach Shop tausende zusätzliche, ungenutze Bilder erstellen.
Hier müsste man so eine Art „dynamische“ Thumbnails zur Laufzeit in einem Cache-Verzeichnis erstellen können (könnte man via Cron auch wieder leeren).
So der Art: /images/dynthumbs/360x360/MeinBild.jpg - und es würde beim Erstaufruf erzeugt werden [größe aus dem Pfad genommen]. So eine Art „Schnittstelle“ zwischen den Thumbnailseinstellungen der verschiedenen virtuellen Ordnern im Mediamanager.

3

netter Vorschlag, ich würde noch eine Stufe davor einsteigen, und zwar bei der Auslieferung der EKW. Lösungsvorschlag: Streichung des Pre-processing mit der HTML-Auslieferung und stattdessen auf jQuery und JSON setzten. Meine praktischer Erfahung damit spart man sich irre Zeit (auslieferung/render) und Datenvolumen und dieser dämliche Ladekreis gehört zu Geschichte. Wird die EKW eigentlich gecached? HTML-Elemente/Nodes reduzieren. Inline-CSS streichen :smiley: ahahahaha, und vor allem die CSS-Klassen auf ein minimum reduzieren und auch mal dessen Logik überdenken. Die Event/subscribe/jQueryplugins… uii. was ein Ritt. Die Hi-Res-Idee überdenken… etc

ich weiß: altes Thema - gibt es auch viele Threads zu - aber nach wie vor aktuell - und noch immer nicht gelöst.

Daran wird sich auch nicht viel ändern. Bei aller Liebe, HTML, CSS, jQuery…etc aus dem Gebrauchsalltag ist ein anderes als das aus dem SW-Headquarter. Mag ja alles professionell nach Lehrbuch programmiert sein (wo ich geistig nicht hinterherkomme) und von ganz netten Menschen (wirklich), aber eben praxisfern wie es nur geht. Auf der anderen Seite verschafft mir das ein ausgefüllten Job! :smiley:

Kleine technische Verbesserung: Ich habe mal ein Plugin gebaut was zumindest die unschärfe mittels CSS ein wenig aufpeppt. Wirkt bei Android und Chrome. Im Grunde eine einfache Sache.

img{
  image-rendering: -webkit-optimize-contrast;
}

 

4

Toll - wegen Block-Geiz-ist-Geil kann man nicht einmal den Inline-Style erweitern. Nur für einen weiteren Brakepoint die ganze tpl überschreiben  Shopware Thumb-down
Mit dem Kat-Teaser hat wirklich wieder jemand sein Meisterwerk abgeliefert.

5

Und zum Ende mal ein kleiner Template-Hack, um den ausgewählten Artikel-Ordner das 200x200 Bild gegen ein anderes auszutauschen.
Zunächst für den Ordner ein weiteres Thumbnail anlegen. Da mindestens 360x360 benötigt werden, es aber durchaus auch etwas mehr sein darf (Breite) habe ich mich für 380x380 entschieden. Es wäre das 4. Thumbnail - da der Index mit 0 anfängt, ist es die „3“.
Nun einfach im Theme testen, ob ein Thumbnail „3“ existiert und die Breite 380 hat. Wenn ja: Datensatz von Image 0 einfach gegen den Datensatz von Image 3 austauschen - und das Theme die Arbeit ohne weitere Eingriffe durchführen lassen.

Hier die widgets/emotion/components/component_category_teaser.tpl aus meinem Theme:

{extends file='parent:widgets/emotion/components/component_category_teaser.tpl'}

{* Category teaser lnk *}
{block name="widget_emotion_component_category_teaser_link"}
    {if isset($images[3].maxWidth) && ($images[3].maxWidth == "380")}
        {$images[0] = $images[3]}
    {/if}
    {$smarty.block.parent}
{/block}

 

6

Schön wäre es wenn du die 380 als Variable hättest.

Feste Werte sind immer böse :wink: Und eine beliebte Fehlerquelle.

7

Ich änder es ja nicht täglich - sonst würde ich das in die Theme.php packen  Wink
Letztlich ist die Abfrage auf die Größe auch nur ein doppeltes Netz - könnte ja sein, dass ich für eine andere Sache in einem anderen virtuellen Ordner schon das Thumb vergeben hätte.
Man könnte auch in einer Schleife durch alle $images gehen und die Breite gegen eine Var aus dem Theme testen. Das wäre dann schon sehr flexiebel.