Shopware 6 Storefront

Shopware ist seit einiger Zeit schon die E-Commerce-Platform unserer Wahl. Mit Shopware 5 durften wir schon zahlreiche Projekte realisieren und betreuen. Wir haben Möglichkeiten und Grenzen des Systems erkundet, Themes und Plugins erarbeitet, überarbeitet und nochmal überarbeitet, unzählige Male Themes kompiliert und Caches geleert und viele individuelle Lösungen gefunden. Nach einigen Jahren so intensiver Erfahrung mit einer Technologie, stellen sich in der Regel zwei Dinge ein: zum einen Sicherheit, Routine und Qualität - zum anderen der Wunsch nach Innovation. Insbesondere wenn sich alles andere so schnell weiterentwickelt, und man in der Zwischenzeit an modernen React- oder Angular-Frontends arbeiten durfte, kann einen der Switch auf ein Shopware 5 Projekt schonmal etwas in der Zeit zurück versetzen, wenn man auf einmal wieder mit jQuery oder extJS zu tun hat. Machen wir uns nichts vor: ein Relaunch von Shopware war überfällig.

Umso mehr haben wir uns über die Ankündigung von Shopware 6 gefreut. Nachdem ich eine Zeit lang das Marketing-Gemunkel und die Buzz-Words nur am Rande aufgeschnappt hatte, bot sich nun endlich die Gelegenheit, in einem ersten Projekt mit Shopware 6 zu arbeiten. In diesem Beitrag möchte ich von diesem Erlebnis berichten und dabei auf Neuerungen, Probleme und meine persönlichen Erfahrungen dabei eingehen.

Ziel der Übung war es, einen bestehenden Shop, den wir betreuen, von Shopware 5 auf 6 zu migrieren. Dabei sollte das Feature-Set und das Erscheinungsbild im Groben erhalten bleiben. Der Shop hatte ein eigenes Theme, ein paar Erweiterungen des Produkt-Listings und der Detailseite um zusätzliche Eigenschaften, hielt sich aber sonst weitgehend an den Standard. Somit ein perfektes Einstiegsthema mit überschaubarer Komplexität. Für die Migration der Daten stellt Shopware ein Plugin bereit. Das Ergebnis war durchwachsen, soll aber nicht Thema dieses Artikels werden. Ich möchte mich auf die Theme-Entwicklung in der neuen Storefront beschränken.

Alles startet mit etwas Verwirrung. Wie gesagt, hatte ich nur am Rande Buzz-Words wie Vue.js, headless etc. aufgeschnappt und hatte dadurch hohe Erwartungen. Ich hatte mich darauf eingestellt, ein hochmodernes losgelöstes Javascript Frontend in Form einer Komponenten-basierten Single-page-application vorzufinden. Nach dem ersten Überfliegen der Doku und der Tutorials stellte sich etwas Ernüchterung ein. Die neue Storefront ist immer noch eine klassische integrierte PHP-Anwendung mit Template Engine und separierten Struktur- (HTML) Design- (CSS) und Funktionalitäts- (JS) Schichten. Im Grunde also alles wie gehabt. Warum es trotzdem Grund zur Freude gibt, erzähle ich gleich. Zunächst soll der Vollständigkeit halber aber noch erwähnt werden, dass es zusätzlich zu dieser klassischen Storefront auch ein paralleles Projekt namens Shopware PWA gibt. Hier findet sich dann tatsächlich genau das, was meiner anfänglichen Erwartung gerecht wird. Shopware 6 setzt sich nämlich aus den Modulen Core, Administration (Backend) und Storefront zusammen, welche eben auch unabhängig voneinander einzeln genutzt werden können. Statt der Storefront lässt sich also auch die Vue.js-basierte Shopware PWA mit dem Core im headless Modus verbinden. Zum Zeitpunkt meiner Recherche wirkte das PWA Projekt noch nicht so richtig feature-complete, machte aber neugierig auf das, was da noch kommt. Hier werden wir auf jeden Fall in Zukunft nochmal anknüpfen.

Also zurück zur klassischen Storefront. Was ist neu? Und warum? Hierzu ein kleiner Überblick über den neuen Tech-Stack.

Tech-Stack

Twig statt Smarty als Template engine:

Same same but different. Abgesehen davon, dass Twig etwas moderner und performanter daher kommt, unterscheidet es sich in erster Linie bloß in der Syntax von Smarty. Diese Entscheidung hängt wohl vor allem damit zusammen, dass Twig bereits im Symfony Framework, auf dem Shopware 6 aufbaut, enthalten ist. Ansonsten kann ich hier bisher keine Vor- oder Nachteile für mich erkennen.

SASS/SCSS statt LESS als CSS Precompiler:

Ich muss ehrlich gestehen, ohne Shopware 5 wäre ich bisher noch nie mit LESS in Berührung gekommen. Obwohl der Funktionsumfang in großen Teilen deckungsgleich sein soll, zeigen Statistiken (und meine Erfahrung bestätigt das), dass SASS hier das vorherrschende Tool der Wahl ist. Der Switch macht also mehr als Sinn; zum einen aus Gewohnheit und zum anderen natürlich auch für das Zusammenspiel mit Drittanbieter-Modulen. Was uns direkt zum nächsten Punkt bringt...

Bootstrap 4

Frontend Frameworks sind perfekt, um Arbeit zu sparen und auf durch riesige Communities optimierten Standards aufzusetzen. Auch hier hat man sich sinnvollerweise für den "Marktführer" entschieden. Jeder hatte schonmal Berührung mit Bootstrap, was den Einstieg sicher deutlich erleichtert, und außerdem ist Bootstrap, wenn auch optisch etwas generisch und altbacken, in dieser Version im Code durchaus auf aktuellem Stand. Vorbei also endlich die Zeiten von floating Grids und den zum Teil doch etwas über-komplizierten CSS Eigenkreationen von Shopware 5.

ES6 Javascript und Helper-Klassen statt jQuery

Es gibt wahrscheinlich nicht mehr viele Frontend-Entwickler, die in den letzten Jahren nicht mal in React oder Angular schnuppern durften. Und ich muss sagen, ES6, klassen- und modulbasiertes JS, typescript etc. haben JavaScript für mich auf ein ganz neues Level gehoben. Seitdem kann ich nicht abstreiten, dass jedes mal ein kleiner Teil von meinem Entwickler-Herz abstirbt, wenn ich noch jQuery-Code schreibe. Vielmehr muss man hierzu vermutlich nicht sagen. Die einzig richtige Entwicklung für ein Setup in 2020! Erwähnenswert seien an der Stelle noch die Helper-Klassen, die Shopware uns im JS zur Verfügung stellt. Von ViewportDetection über DomAccess bis PluginManager sind hier viele komfortable Helferlein dabei, die man von der alten "Plugin-Base" und jQuery gewohnt war.

Webpack als Bundler

Auch hier war die Entscheidung sicher unumgänglich. Webpack ist heute quasi alternativlos der Status Quo als Angelpunkt in der Frontend-Toolchain. Grunt und den PHP-Compiler hat Shopware zum Glück hinter sich gelassen. Das ermöglicht eine intuitive und super schnelle lokale Entwicklung, die Spaß macht.

Getting started - Lokale Dev-Umgebung

Eine der größten positiven Überraschungen war die Dev-Umgebung, die Shopware über ein separates GitHub-Repo zur Verfügung stellt. Hier hat man sich wirklich umfassend Gedanken gemacht und ein Paket geschnürt, mit dem es einem wirklich leicht gemacht wird, Shopware 6 lokal aufzusetzen. Dabei ist außerdem ein eigenes Command-Line-Tool (psh.phar), das die Installation und die üblichen Builds und Console-Tasks während der Entwicklung abstrahiert und vereinfacht. Die einzigen Schwierigkeiten, die mir hier begegnet sind, waren gewohnt systembedingt: Ich muss mich als Apple-User outen. Das hat neben dem wichtigen Coolness-Faktor zum einen historische Gründe, weil ich auf Mac gelernt habe zu entwickeln, aber auch weil ich hin und wieder in der App-Entwicklung auf Apple Tools angewiesen bin. Seit einiger Zeit hat sich Docker im Umgang mit reproduzierbaren Produktions-Umgebungen, aber auch in der Entwicklung durchgesetzt. Auf dem Mac hat man mit Docker leider systembedingt immer wieder enorme Performance-Probleme. Hier lässt sich jedoch mithilfe von verschiedenen File-Sync Ansätzen Abhilfe schaffen. Auch dafür stellt Shopware einige Infos in der Doku zur Verfügung.

Nach einigen Experimenten und Problemen mit NFS und Mutagen bei Shopware 5 habe ich diesmal, wie in der Doku empfohlen, mit docker-sync eine einigermaßen stabile (manchmal verschluckt sich der sync oder dauert sehr lange) und performante Shopware 6 Dev-Instanz hinbekommen. Falls docker-sync mal hängt - die Datei .docker-sync/deamon.log kann helfen. Mir ist es z.B. häufiger passiert, dass er sich über lock-files beschwert hat. Wenn ich die dann einmal gefunden und gelöscht hatte, lief der sync wieder. Je nach Geschmack finden sich in der Doku aber auch Setup-Guides für Vagrant oder MAMP. Insgesamt lässt sich festhalten: durch das Webpack Setup in Kombination mit docker-sync ist die lokale Entwicklung (zumindest auf dem Mac) gefühlt um Lichtjahre schneller und deutlich komfortabler geworden. Die development Scripte machen sich das Hot Module Replacement von Webpack zu Nutze, so dass man Änderungen quasi direkt nach dem Speichern sieht. Wer Shopware 5 schonmal im Entwicklungsmodus ohne HTTP- und Compiler-Cache lokal genutzt hat und sich bei jedem Reload nach einer kleinen CSS Änderung einen Kaffee holen konnte, kann vielleicht nachfühlen, was das für einen Quantensprung bedeutet.

Das neue Shopware 6 Backend

Der Shop läuft also und man hat sich einmal durch die Demo-Artikel in der Storefront geklickt. Spoiler: hier hat sich nicht viel verändert. Die UI wirkt etwas cleaner und moderner, strukturell findet man hier aber größtenteils alles vor, wie von Shopware 5 gewohnt. Aufregender wird es im neuen Backend. Die behäbige und super altbackene extJS Oberfläche ist einem performanten, dynamischen Admin-Dashboard auf Basis von Vue.js gewichen. Der Look ist modern und erinnert an die bekannten Atlassian Tools und auch strukturell wirkt alles deutlich aufgeräumter und benutzerfreundlicher. Klar, am Anfang muss man erstmal etwas suchen. Einige gewohnte Funktionen heißen anders oder finden sich woanders. Ich hab mich aber grundsätzlich schnell zurechtgefunden. In der Anwendung fällt vor allem eine Neuerung auf. In Shopware 5 gab es noch diverse Möglichkeiten, den Shop zu strukturieren. Es gab eine Detail-Seite, ein Kategorie-Listing, Einkaufswelten und Shop-/Infoseiten. All diese Seiten-Typen hatten feste Templates und waren nur bedingt konfigurierbar. In Shopware 6 hat man dies alles runtergebrochen auf ein zentrales CMS-Konzept:

Layouts

Hier kann man sich aus diversen vorgegebenen Blöcken (Text, Bild, Formular, Listing, usw) einen individuell strukturierten Seiten-Typ zusammenklicken.

Kategorien

Über Kategorien lässt sich die Gesamte Navigationsstruktur abbilden, egal ob es sich dabei um eine Produktkategorie, die Startseite oder das Impressum handelt.

Inhalt

Jeder Kategorie kann dann ein Layout zugewiesen und mit Inhalt (Text, Bilder, Produkte usw.) befüllt werden.

Zunächst ist das Ganze etwas verwirrend und gewöhnungsbedürftig, wenn man aus der in Wirklichkeit viel komplexeren SW5 Welt kommt. Wenn man das Prinzip aber einmal verstanden hat, ist das wirklich eine deutliche Verbesserung. Fast jeder Seitentyp (in Zukunft auch die Detailseite) können individuell gestaltet werden. Das erinnert etwas an die Einkaufswelten aus SW5, nur dass jetzt quasi der gesamte Shop aus ihnen besteht und hier Struktur und Inhalt strikt getrennt wurden, was deutlich Komplexität und redaktionellen Aufwand reduziert und trotzdem viel mehr Möglichkeiten bietet, auch ohne Theme-Entwicklung schon einen Shop zu konfigurieren, der nicht unbedingt nach Shopware-Standard aussehen muss. Ein paar kleinere Komfort-Funktionen habe ich noch vermisst. Wie z.B. innerhalb des Kategorie-Baums kopieren und verschieben zu können - wenn man hier einen Fehler in einer oberen Ebene gemacht hat, muss man alle darunter nochmal neu anlegen. Aber hier wird sicher kontinuierlich nachgebessert werden.

Die Storefront-Erweiterung

Nach dem ersten Überblick übers System und die technischen Neuerungen kann also die eigentliche Arbeit beginnen. Wer mit Shopware 5 vertraut ist, wird strukturell vieles wiedererkennen. Zum Individualisieren der Storefront werden Themes und Plugins genutzt. Wie gewohnt, greift hier auch wieder ein Vererbungs-System. Ein selbst erstelltes Custom Theme kann von dem Default Theme erben und so einzelne Blöcke in Twig-Templates überschreiben oder ergänzen. Anders als bei Shopware 5 gibt es allerdings nur noch ein Default Theme namens “Storefront”, keine Kombination aus “Bare” und “Responsive” (die ich nie so ganz nachvollziehen konnte) mehr. Eine weitere Neuerung ist, dass eigene Themes jetzt auch immer als Plugins erstellt und installiert werden. Hier gibt es keine Abgrenzung mehr, was strukturell einiges vereinfacht. So lassen sich in einem Theme-Plugin Erweiterungen der Core-Funktionen, der Darstellungsebene sowie des Backends kombinieren. Auch wenn der ehrgeizige Ansatz meistens ist, möglichst modular gekapselt zu entwickeln, kennen wir aus der Vergangenheit Situationen, in denen das Theme und einzelne Plugins dann doch wieder individuelle Abhängigkeiten haben mussten. So mancher Shop wächst nach einigen Jahren Maintenance und Individualentwicklung so zu einem fragilen Kartenhaus. Da das Theme nun auch selbst ein Plugin ist, können hier also jetzt alle individuellen Abhängigkeiten zentral untergebracht werden. Das schafft in vielen Situationen deutlich mehr Übersichtlichkeit und Stabilität und hilft, Fehler durch Abhängigkeiten zwischen individuellen Plugins und Plugin-Versionen zu vermeiden. Die Entwicklung selbst gestaltete sich relativ reibungslos. Über das CLI-Tool in der Dev-Umgebung lässt sich ein hilfreiches Plugin/Theme-Skeleton erstellen, sodass der Einstieg leicht fällt. An der ein oder anderen Stelle bin ich über unvollständige Artikeldaten gestolpert. So gibt es bei den Artikeleigenschaften z.B. keine Custom Fields (früher “Freitextfelder”) und manche Felder können zwar gepflegt werden, tauchen aber z.B. im Listing nicht in den Artikeldaten auf. Durch entsprechende Event-Hooks und Service-Decorator innerhalb des Theme-Plugins ließen sich diese jedoch hinzufügen und die Daten entsprechend anreichern, sodass die Funktionalität des alten Shops weitestgehend wiederhergestellt werden konnte (in SW5 wären hierfür wieder eigene Plugins nötig gewesen).

Ein Feature, das man (ich zumindest) in der Storefront vermisst, ist das Infinite Scrolling, also das automatische Nachladen von Artikeln im Listing, welches in SW5 zum Standard gehörte. Ich konnte es zum Zeitpunkt meiner Recherche auch tatsächlich nicht in der Roadmap für die Weiterentwicklung von SW6 finden. Warum man auf ein aus UX-Sicht so zentrales und gewohntes Standard-Feature, welches aus meiner Sicht auch nicht besonders aufwändig umzusetzen wäre, verzichtet, erschließt sich mir nicht. Es gibt wohl noch wichtigere Baustellen.

Dafür können wir aber auf der Habenseite auch noch etwas verbuchen. Zum einen werden Icons endlich nicht mehr als Icon-Fonts, sondern als SVGs eingebunden (warum das gut ist). Das erleichtert das Handling und das Erweitern um eigene Icons deutlich. Die File-Struktur fand ich hier etwas verwirrend, geholfen hat mir dabei aber dieser Artikel. Zum Anderen werden Snippets als json und nicht mehr als ini-Dateien angelegt. Wenn auch nur eine andere Syntax, wirkt es moderner und intuitiver.

Fazit

Zusammenfassend war meine Erfahrung mit Shopware 6 bisher also überwiegend positiv. Viele Neuerungen waren überfällig und der Tech-Stack ist endlich wieder zeitgemäß. Besonders gefallen haben mir die neue superschnelle lokale Dev-Umgebung und das neue Backend. Auch bei der Umstrukturierung des CMS hat man sich umfassend Gedanken gemacht und hier einen super neuen Ansatz gefunden, der gleichzeitig sowohl Komplexität verringert als auch Individualität erhöht. Ein paar Funktionen vermisst man noch, aber das System ist noch neu und aktuell sind die Entwicklungssprünge noch deutlich zu sehen. Die Doku und die Tutorials haben hohe Qualität und machen den Ein-/Umstieg leicht. Der Ausblick auf die Shopware PWA als Ersatz oder Ergänzung zur Storefront klingt außerdem sehr vielversprechend (to be continued...).