50°North

Die älteren werden sich erinnern: Rate mal mit Rosenthal war eine Quizsendung im ZDF. Ich würde das gerne wieder aufleben lassen.

Wo findet man in Shopware die Einstellmöglichkeit, dass Filter sich automatisch aktualisieren (Live reload, AJAX reload oder wie auch immer man das nennen will)?

• Einstellungen – Grundeinstellungen – Storefront – Filter / Sortierung
• Artikel – Kategorien
• Einstellungen – Caches / Performance – Einstellungen – Allgemein – Filter

„Einstellungen – Caches / Performance – Einstellungen – Allgemein – Filter“ ist so richtig wie nicht intuitiv.
Und während sich in „Einstellungen – Caches / Performance – Einstellungen – Allgemein – Kategorien“ Sachen finden, die sich auch in „Einstellungen – Grundeinstellungen – Storefront – Kategorien / Listen“ hat man diese nicht ganz unwichtige Option nicht doppelt und dreifach untergebracht.

Ihr wollt einen Block in einem Shopware-Template ändern und erweitert daher das Eltern-Template:

{extends file="parent:frontend/listing/text.tpl"}

So weit so bekannt. Wollt ihr jetzt aber in diesem Template Snippets aus dem Elterntemplate ohne Namespace verwenden führt das dazu, dass ein neues Snippet im Namespace eurer neuen Datei (hier also „frontend/listing/text”) angelegt wird.

{s name='ListingActionsCloseOffCanvas'}{/s}

Um das zu verindern müsst ihr einen evtl. gesetzten globalen Namespace nach dem vererben erneut setzen oder den gewünschten Namespace bei jedem Snippet mit angeben.
Also entweder so:

{extends file="parent:frontend/listing/text.tpl"}
{namespace name="frontend/listing/listing"}

Oder so:

{s namespace='frontend/listing/listing' name='ListingActionsCloseOffCanvas'}{/s}

Für den Fall, dass man aus einer Smarty-Variable ein Snippet zaubern will:

{$namespace = "frontend/language"}
{$name = $lang.locale}
{""|snippet:$name:$namespace}

Konkretes Beispiel:
Man hat den locale einer Sprache (z.B. de_DE), möchte aber ganz gerne „Deutsch“ im Frontend ausgeben. Mit dem Code oben geht genau das, Smarty gibt jetzt den Inhalt des Snippets „de_DE“ aus dem Namespace „frontend/language“ aus. Der Namespace ist dabei wichtig, sonst funktioniert es nicht!

Man kann über den cat-Modifier außerdem noch den Namen erweitern, damit man als Snippet-Name nicht nur „de_DE“ in der Datenbank stehen hat:

{$name = "lang_"|cat:$lang.locale}

und bekommt damit lang_de_DE als Name.

Ich mag das Theme-Konzept von Shopware ja eigentlich. Es gibt ein Bare-Theme, das außer HTML nichts enthält. Kein Styling, kein Javascript, einfach nur reines HTML.
Darauf aufbauend gibt es ein Responsive-Theme das, wie der Name schon sagt, responsive ist und über Variablen im Backend farblich auch ein bisschen angepasst werden kann. Das ist für den Wohnzimmerhändler sicherlich toll und man sieht auch mittlerweile unzählige Shops, die das Responsive-Theme nutzen und außer Logo und Farbe nichts geändert haben. Kann man machen, ist dann halt kacke.

Für unsere Ansprüche ist das natürlich nichts. Wir haben ein komplett selbst gestaltetes Theme, das auch nach allen Regeln der Kunst umgesetzt werden soll. Und da es so ganz anders ist als das Default-Theme wäre es natürlich gut, wenn man nicht den ganzen CSS-Ballast, den das Responsive-Theme mitbringt, rumschleppen müsste.

Weil sind wir doch mal ehrlich: Shopware 5 und damit die Grundlage des Responsive-Themes ist von 2015, der letzte Commit auf das Repo von pocketgrid, welches das Responsive-Theme nutzt, ist sogar noch ein Jahr länger her. Mittlerweile haben wir echtes CSS Grid und es wäre fahrlässig, das nicht zu nutzen.

Nur: Der Weg von

zu

ist ganz schön steinig und unnötig beschwerlich.

Vom Bare-Theme erben

Funktioniert total gut. Also bestimmt. Wenn man einen frisch installierten Shop hat ohne ein einziges Plugin. Das dürfte aber eher die Ausnahme sein. Schon bei einem Shop, der lediglich das PayPal-Modul installiert hat, scheitert das Kompilieren des Themes:

Während der Bearbeitung von Shop "Demoshop" ist ein Fehler aufgetreten: variable @tabletViewportWidth is undefined in file custom/plugins/SwagPaymentPayPalUnified/Resources/views/frontend/_public/src/less/_modules/index/sidebar.less in sidebar.less on line 11, column 30 09| } 10| 11| @media screen and(min-width: @tabletViewportWidth) { 12| .paypal--sidebar { 13| .unitize(margin-bottom, 20); 14|

Öh ja, das ist so semi-gut. Kann man prinzipiell nachrüsten, sobald man aber noch ein paar komplexere Plugins am Start hat wie beispielsweise die Advanced Promotion Suite knallt es auch bei den Farbwerten, die man eigentlich über das Backend konfigurieren kann (aber eben nicht beim Bare-Theme).

$discardedLessThemes beim Responsive-Theme

Also vom Responsive-Theme erben. Seit Shopware 5.4 gibt es da die Möglichkeit, sowohl in den Vererbungspfad des CSS/LESS als auch das Javascripts einzugreifen. Für LESS/CSS mittels discardedLessThemes, für das Javascript mittels discardedJavascriptThemes.

Da also das Responsive-Theme eintragen und kompilieren und alles ist super. Natürlich nicht. Auch hier hat man die Rechnung ohne die Plugin-Autoren gemacht. Direkt als erstes fliegt einem wieder der Tablet-Viewport um die Ohren. Hat man sich dafür ein eigenes LESS-File angelegt knallt zumindest in unserem Fall das Amazon-Pay-Plugin. Und zwar mehrfach aufgrund des Zugriffs auf jetzt nicht mehr vorhandene Definitonen aus dem Bereich der Buttons. Also auch hier eigene LESS-Files anlegen und leere Definitionen dort eintragen.
So geht das Spielchen, das einem Marathon gleicht, munter weiter, bis alle Plugins, die noch nichts davon gehört haben, dass die Vererbung mittlerweile abschaltbar ist, zufrieden gestellt sind. Erst dann hat man für einen Shop mit diversen Plugins auch endlich eine wirklich CSS-freie Darstellung. Also quasi Bare-Theme ohne die Probleme mit den fehlenden Farbdefinitionen.

Nur: CSS-frei ist das ganze deswegen noch lange nicht, da sorgt schon jedes Plugin dafür, dass da wieder ein bisschen was zusammen kommt, aber zumindest lässt sich so der Umfang des CSS schon mal auf ca. 2500 Zeilen reduzieren, während der gleiche Shop mit Responsive-Theme auf 25.000 Zeilen kommt. Es ist noch ein weiter Weg…