To the English article

Neue Wege beschreiten heißt Umdenken! Altbewährte Herangehensweisen kritisch beleuchten, über den Tellerrand hinausblicken und Neues ausprobieren. Besonders die Erfahrungen aus Vorgängerversionen erlauben es, eine Software mit Blick auf die sich wandelnden Anforderungen des ohnehin schnelllebigen Marktes vernünftig weiterentwickeln zu können. Andernfalls nämlich droht ein System zu einem angestaubten Monolithen zu verkommen. Mit Shopware 6 wurde viel umgedacht, viel Raum für Neues geschaffen. Weil Shopware nicht nur eine reine Software für Anwender ist, sondern ebenso als eine Art Framework für Entwickler fungiert, sind auch die Anforderungen und Bedürfnisse aus der Developer Community ein wichtiges Thema bei der Weiterentwicklung. Während sich der Löwenanteil wie so oft im Software-Business unter der Oberfläche befindet und sich zumeist den Blicken der Mehrheit entzieht, dreht sich im E-Commerce vieles aber auch um Optik, Look & Feel, Performance und Co. — Grund genug also, mit Shopware 6 auch im Frontend neue Wege zu gehen! Shopware 6 setzt vollständig auf dem bewährten PHP-Standard-Framework Symfony auf. Nur verständlich also, dass damit die ebenfalls aus dem Hause SensioLabs stammende Template-Engine Twig Einzug gehalten hat und damit das bisher verwendete Smarty ablöst. Aber die Standardisierung hört hier noch lange nicht auf — im Gegenteil! Bootstrap CSS Framework statt Eigenentwicklung, Sass statt LESS, objektorientiertes JavaScript (ES6), Webpack … die Liste ist lang und ebenso die daraus resultierenden Vorteile und Änderungen. Welche Neuerungen Dich konkret erwarten und worauf es in der Shopware 6 Storefront ankommt, das wird Dir Martin Schindler, Software Architect bei dasistweb, im weiteren Verlauf dieses Beitrags aufzeigen. Grafik_Martin_Schindler

## In Einzelteile zerlegt — die Shopware 6 Storefront Um das große Ganze verstehen zu können, musst Du oft zunächst die einzelnen Bestandteile betrachten und wie diese schlussendlich auch zusammenspielen. Aus diesem Grund werden nachfolgend die einzelnen Komponenten der neuen Storefront betrachtet, beginnend mit den drei elementaren Schichten einer webbasierten Applikation und den verwendeten neuen Tools und Standards. Damit für Dich nachvollziehbarer wird, weshalb manche Dinge plötzlich anders als bisher gewohnt laufen, werden Brücken zu den verschiedenen Pendants aus Shopware 5 geschlagen. the-three-typical-layers-of-a-web-application

the-three-typical-layers-of-a-web-application

The three typical layers of a web application

### Strukturschicht (Structure & Content) Das Fundament eines Web-Frontends bildet die Strukturschicht — in ihrer einfachsten Ausprägungsform bestehend aus statischem HTML Markup, aufgeteilt in logische oder inhaltsbezogene Abschnitte. Für die Realisierung höherer, technischer Anforderungen existieren sogenannte Template-Engines, die das Rendern von HTML Markup mit Hilfe von Vorlagen (Templates) übernehmen. Nichts Neues für jeden, der bereits mit einer früheren Version von Shopware gearbeitet hat. Neu ist jedoch, dass fortan Twig als Template-Engine zum Einsatz kommt, während bis einschließlich Shopware 5 noch auf Smarty gesetzt wurde. Ebenfalls aus den Händen der Symfony-Macher allein schon aus Gründen der Integration und der Interoperabilität ist im Symfony-Kosmos eine rein logische Schlussfolgerung. Ohne weiter großartig auf Details eingehen zu wollen, gilt Twig als eines der schnellsten, sichersten und flexibelsten unter den etablierten, PHP-basierten Template-Engines auf dem Markt. Wie so oft gilt auch hier: Neue (oder besser “andere”) Technologien bringen eine gewisse Einstiegshürde mit sich. Beispielsweise die Syntax — diese unterscheidet sich bei Twig natürlich von der altbekannten Smarty Schreibweise. Nützliche Informationen zum Umgang mit Twig, dem Funktionsumfang, Erweiterbarkeit und Coding Standards findest Du in der offiziellen Dokumentation. #### Die wichtigsten Aspekte im Umgang mit Twig in der Storefront __Debugging__ — Ein simpler VarDump auf ein Objekt in der View konnte Smarty gehörig in die Knie zwingen. Bei Twig sieht das gänzlich anders aus — zum Glück! Dank der integrierten VarDumper-Komponente und dem DebugBundle von Symfony können fortan alle Variablen in der Storefront sorgenfrei ausgegeben werden: 0019sfdGMuN3FLv2

Und dabei steht zusätzlich die Übersichtlichkeit der Debug-Ausgabe im Vordergrund. Dank der visuellen Aufbereitung gehören unübersichtliche “print\_r” Ausgaben somit der Vergangenheit an: skalare-datentypen

Skalare Datentypen, Arrays sowie Objekte können mittels {{ dump() }} bequem debugged werden

__ Textbausteine__ — Ebenfalls anders gestaltet sich das Thema Textbausteine. Während im Smarty Kontext noch mit eigens dafür entwickelter Snippet-Funktion gearbeitet und jeder Textbaustein durch eine Kombination aus Name und Namespace identifiziert wurde, läuft es in Twig etwas anders: 002JPsGI4BlTHtZf

Über den “trans” Filter, welchen Symfony und Twig standardmäßig bereitstellen, können Textbausteine an beliebiger Stelle im Template gesetzt und aus der zugrundeliegenden Datenquelle (z. B. messages.de.yaml für deutsche Textbausteine, messages.en.yaml für englische Übersetzungen) konsumiert werden. __ Extends & Include__ — Technisch gut gelöst ist in Twig das Thema Erweiterbarkeit. Die Möglichkeit der Erweiterung des Funktionsumfangs durch eigene Tags, Filter, Functions und Tests über einen rein objektorientierten Ansatz und die Unit-Testbarkeit solcher, stellt besonders für Projekte im Enterprise-Sektor ein reizvolles Instrument zur Implementierung individueller Bedürfnisse dar. Und gerade diesen Instruments bedient sich auch die neue Storefront. Weil Plugins sowie individuelle Themes eine mehrstufige Vererbungshierarchie bilden, die Twig im Standard nicht unterstützt, wurden zwei Shopware-spezifische TokenParser implementiert, die mittels der Tags “sw\_include” sowie “sw\_extends” in der Storefront Anwendung finden. Diese beiden sind anstelle der eigentlich im Standard bestehenden Tags “include” und “extends” zu verwenden und gewährleisten so, dass ein Überschreiben von Template Blöcken, etwa durch Plugins, möglich ist. Möchte man also beispielsweise eine View von einer anderen erben lassen, ist darauf zu achten, dass “sw\_extends” verwendet wird: 003TXII6RAVC6MAG

Gleiches gilt für den Fall, dass man in einer View eine Template-Datei einbinden möchte. Hier ist “sw\_include” zu verwenden: 004tkYVh9066Krhh

__ Icons & Thumbnails__— Natürlich bietet es sich an, kleine Helferlein zu implementieren, die das Daily Business für Template Developer erleichtern sollen. Aus diesem Grunde ist “sw\_icon” entstanden, welches das bequeme Konfigurieren und Laden von SVG-Icons ermöglicht: 005

Ebenso komfortabel ist die Verwendung von “sw\_thumbnails”, das anhand der übergebenen Parameter einen <img> Tag mit korrekt konfigurierten “srcset”- und “sizes”-Attributen rendert: 006

Die Organisation der Twig Files in der Storefront und deren Aufbau hat sich im Vergleich zu Shopware 5 natürlich auch etwas verändert. Allerdings gibt es hier keine großartigen, technischen Finessen auf die gesondert eingegangen werden müsste. So viel für den Moment zur Strukturschicht. ### Präsentationsschicht (Presentation) In der heutigen Zeit ist ein Onlineshop ohne modern anmutendes, benutzerzentrisches Look & Feel unvorstellbar geworden. Die sogenannte __Präsentationsschicht__ erlaubt es, den Look einer Applikation mittels CSS an das HTML Markup zu binden. Dabei gilt — je allgemeiner die CSS Definitionen gehalten sind, desto losgelöster sind diese vom konkreten Markup. Je spezifischer, desto schneller können Änderungen im Markup zu ungewollten, sichtbaren Side-Effects führen. Weil CSS heutzutage viel mehr ist als nur Styles auf Selektoren zu setzen, gibt es seit etlichen Jahren diverse, sogenannte CSS Preprozessoren. Mithilfe dieser lassen sich syntaktische Regeln und Sprachkonstrukte verwenden, um effizienter CSS zu erzeugen. Genauer gesagt wird durch eine eigene Stylesheet-Sprache der eingeschränkte Funktionsumfang von CSS durch Variablen, Funktionen, Mixins und Co. erweitert. Weil der Browser allerdings nur CSS verarbeiten kann, werden die erzeugten Files mittels des Preprozessors zu einem vorangehenden Zeitpunkt in valides CSS kompiliert. Dieses Kompilat wird schließlich im HTML Markup geladen und vom Browser interpretiert. #### Der Preprozessor Umstieg: von LESS zu Sass Wer schon mit Shopware 5 gearbeitet hat, der kennt bereits die Stylesheet-Sprache LESS. Bei Shopware 6 ist nun ein konsequenter Umstieg auf Sass erfolgt. Beim Vergleich von Frameworks, Sprachen oder Tools steckt der Teufel wie so oft im Detail — die bekanntesten CSS Preprozessoren (Sass, LESS, Stylus, PostCSS) unterscheiden sich funktional betrachtet circa 20% voneinander, die restlichen 80% sind deckungsgleich. Zu behaupten, Sass sei besser, schneller, toller als LESS, wäre daher eine rein subjektive Aussage. Ein Kriterium das für den Umstieg auf Sass spricht und zudem nicht so leicht von der Hand zu weisen ist, ist jedoch das Thema der Verbreitung. Wie nachfolgendes Diagramm zeigt, wurde bei einer Umfrage die Verteilung diverser CSS Preprozessoren ermittelt. Dabei hebt sich Sass ganz klar von der Konkurrenz ab: front-end-tooling-survey-2018

The Front-End Tooling Survey 2018 (Ashley Nolan)

Ein weiteres Argument für den Umstieg von LESS auf Sass ist das Thema “CSS Framework”. Nach ausführlicher Evaluation fiel für Shopware 6 die Entscheidung hierbei auf das etablierte Bootstrap Frontend-CSS-Framework, dessen Marktanteil sich ebenso deutlich von bestehenden Alternativen absetzt. Mit Version 4 des Frameworks sind Source-Files fortan als Sass-Files (genauer gesagt in der Syntax-Ausprägung SCSS für “Sassy CSS”, also mit der Dateiendung \*.scss) geschrieben. Somit liegt auch aus diesem Aspekt heraus der Umstieg zu Sass förmlich auf der Hand. ### Bootstrap 4: Source-Files nutzen und profitieren Wie eben erwähnt, liegen die Source-Files von Bootstrap als Sass-Files vor. Es ist somit möglich, die darin definierten Variablen, Mixins und Functions für eigene Zwecke zu nutzen. Welche dies sind und wie sie man sie verwendet, kannst Du der offiziellen Dokumentation entnehmen. Nun, nichts wirklich Neues … schließlich konnten in Shopware 5 bereits definierte LESS Konstrukte wiederverwendet werden. Was also ist hier nun als konkreter Benefit für die neue Storefront zu nennen? __Dokumentation eines gewissermaßen Standards__ — Anstelle von Eigenimplementierungen wird dank der Verwendung von Bootstrap auf einen in gewisser Weise bestehenden Standard gesetzt. Functions, Mixins und Co. sind so allein durch die Community bereits tausendfach getestet, werden regelmäßig verbessert sowie erweitert und liegen in entsprechender Form ausführlich dokumentiert vor. Ein Umstand, der bei Anpassungen in der Storefront ein rasches, zielgetriebenes Vorankommen ermöglicht. __Reduktion auf das Wesentliche__ — Insbesondere weil viele Themen und Probleme (z. B. Grid-System, diverse Komponenten, Browser-spezifische Eigenheiten, etc.) dank des Bootstrap Frameworks bereits als gelöst anzusehen sind, liegt der Fokus bei der Implementierung der neuen Storefront auf dem wirklich Wesentlichen. Durch die Verwendung der Source-Files und ferner explizit jener Bestandteile, die in der Storefront auch tatsächlich benötigt werden, lässt sich außerdem das Kompilat, d. h. das am Ende erzeugte CSS-File, ebenfalls auf das Wesentliche reduzieren. Dies wiederum dient der Performance und verbessert die Ladezeit der Storefront. __SCSS in trockenen Tüchern__ — Ein bekanntes Paradigma des Software Engineerings ist DRY (Don’t repeat yourself). Dieses besagt, dass redundanter Code vermieden oder zumindest reduziert werden sollte. Dank Variablen, Mixins und Functions sowie der Möglichkeit, von bestehenden Selektoren zu erben (mittels @extend Anweisung), können Definitionen und Konstrukte bequem wiederverwendet werden. Weil Bootstrap hier ein zahlreiches Portfolio mitbringt, können schnell und unkompliziert neue Buttons, Labels, Notifications, Grids und Co. erzeugt werden. Ein großes Benefit, besonders um schnell den groben Aufbau einer View zu implementieren. Aber selbstverständlich auch, wenn es um die Feinheiten geht. __Erweiterbarkeit __— Aufgrund der großen Verbreitung von Bootstrap, auch in anderen Webapplikationen und -systemen, können bereits heute zahlreiche 3rd-Party Module konsumiert und für die eigenen Zwecke in der Storefront eingesetzt werden. Gewisse, notwendige Anpassungen lassen sich selbstverständlich nie gänzlich vermeiden. Dafür ist das Thema Frontend einfach oft zu spezifisch bzw. vom jeweiligen Projektscope abhängig. Um jedoch schnelle Erfolge oder gar technische Durchstiche zu erzielen, ist dies ein maßgeblicher Benefit der Verwendung des Bootstrap 4 CSS-Framework in der neuen Shopware 6 Storefront. __Corporate Identity__ — Wer sich bereits mit Bootstrap befasst hat, der weiß, dass dort zahlreiche Variablen zur individuellen Konfiguration einladen. So kann man an einem zentralen Ort die Stellschrauben betätigen um damit das gesamte Look & Feel auf die eigenen Bedürfnisse anzupassen. Dank der mit “!default” Keyword versehenen Variablen innerhalb der Bootstrap Source-Files eine ziemlich praktische Sache. Besonders auch im Hinblick auf das Thema “Skins” im Kontext der neuen Storefront. Das mitgelieferte “Shopware Skin”, eine Ansammlung von SCSS-Files, liegt sozusagen als Schicht über den Bootstrap Stylesheet Definitionen und schmückt das Default-Theme der neuen Storefront somit im CI von Shopware. Ist hierfür in einem eigenen Projekt kein Bedarf, kann dieses “Skin” entfernt bzw. durch ein eigenes ersetzt werden. #### Organisation ist die halbe Miete Um auch die in einem Softwareprojekt omnipräsente Frage nach der Organisationsstruktur von Ordnern und Dateien geklärt zu haben, orientiert sich die neue Storefront grundsätzlich am sogenannten 7–1 Pattern, einem Organisationsmuster das sich im Sass Umfeld über die Zeit etabliert hat. Aufgeteilt in sieben getrennte Bereiche (bzw. Ordner) sind so diverse Verantwortlichkeiten logisch getrennt. Nachfolgende, beispielhafte Darstellung der Organisationsstruktur von SCSS Files soll diese Trennung von Verantwortungsbereichen verdeutlichen: 007

Die klare Aufteilung ermöglicht dabei nicht nur ein übersichtlicheres Organisieren von Styles, vielmehr weist sie den Entwickler zugleich darauf hin, Anpassungen bewusster vorzunehmen sowie neue Dateien konsequenter dem geeigneten Themengebiet zuzuordnen.

Tipp

Eine möglichst lose Kopplung von Komponenten zu anderen Files ermöglicht es, diese ohne größere Mühen in andere Themes oder gar Projekte zu migrieren.

### Verhaltensschicht (Behaviour) Zu guter Letzt wird über die Struktur- und die Präsentationsschicht schließlich die __Verhaltensschicht__ gestülpt. Auf dieser Ebene ist all das angesiedelt, das dem Anwender eine interaktive Bedienung ermöglicht. Im Falle einer Webapplikation übernimmt dies primär die Skriptsprache JavaScript, kurz JS. Weil der JavaScript zugrundeliegende, standardisierte Sprachkern ECMAScript es seit Version 6 erlaubt, objektorientierten Code in einer Syntax ähnlich anderer klassenbasierter Programmiersprachen zu erzeugen, hat JS in den letzten Jahren deutlich das Interesse der Programmierwelt für sich geweckt. Und weil mit der OOP-ähnlichen Schreibweise analog dazu ebenfalls Themen aus der Softwarearchitektur Einzug halten (Clean Code Prinzipien, Vererbung, Komposition, Separation of Concerns, etc.), hat sich auch das Qualitätsbewusstsein in diesem Bereich deutlich zum Positiven gewandelt. Für die Entwicklung der neuen Storefront stand schnell fest, dass auf ES6 und somit klassenbasierte Syntax gesetzt wird. So sind schließlich auch diverse Tools — genauer gesagt Helferklassen — entstanden, die unterschiedlichste Aufgaben in der neuen Storefront übernehmen. Die wichtigsten im Überblick: __ViewportDetection __— Während in Shopware 5 noch der “StateManager” für allerlei Dinge verantwortlich war, gibt es in der Shopware 6 Storefront nun eine dedizierte ViewportDetection-Klasse. Im Zusammenspiel mit den von Bootstrap bereitgestellten CSS-Viewports bietet diese Klasse die Möglichkeit, über eigens dafür erzeugte Events auf das Wechseln des Viewports zu reagieren: 008_whiteIly5k0pxWqRDj

Zusätzlich hierzu stehen separate Events je Viewport zur Verfügung, sowie Methoden um den aktuellen Viewport zurück zu erhalten. Wichtig zu erwähnen ist, dass die Klasse sich ausschließlich mit diesem Thema befasst (Separation of Concerns, d. h. Trennung von Verantwortlichkeiten). __DeviceDetection__ — Die DeviceDetection Klasse wiederum hat zur Aufgabe mit kleinen, statischen Funktionen durch einfache Anwendung bool’sche Aussagen über das verwendete Device zu treffen. Möchte man beispielsweise in Erfahrung bringen, ob es sich beim aktuellen Gerät um ein TouchDevice handelt, ist dies folgendermaßen möglich: 009qyweCTpznEe7R

__DomAccess__ — Schnell und typsicher prüfen ob ein Node Element ein Attribut besitzt? Dies ist unter anderem Aufgabe der DomAccess Helferklasse. Die Klasse abstrahiert den Zugriff auf Node Elemente, Attribute und Data-Attribute und kümmert sich darum, dass verlässliche Ergebnisse zurück erhalten werden. 010_neu

Ein weiteres Beispiel verdeutlicht, welchen Komfort die Helferklasse zusätzlich bereitstellt. Will man eine Klasse implementieren, deren Ausführung nur dann erfolgen soll, wenn der korrespondierende Selektor als Bedingung im HTML Markup auffindbar ist, dann lässt sich dies exemplarisch wie folgt lösen: 010uaXuZUYQnxBuR

Intern wird eine Exception geworfen, wenn der angegebene Query Selector kein Ergebnis liefert. Auf diese kann dann per try/catch reagiert werden. Als dritter, optionaler Parameter ist es außerdem möglich den Strict-Mode auszuschalten, somit kommt bei Nichtauffinden eines Elements ein bool’sches FALSE zurück. Prüfungen auf “!== typeof undefined” und Co. gehören damit der Vergangenheit an. Es genügt damit immer die Prüfung auf “!== FALSE”. __HttpClient__ — Wer bereits JavaScript-seitig mit asynchronen Requests gearbeitet hat, der weiß worauf es ankommt. Bestehende, noch aktive Requests abbrechen bevor man einen neuen absetzt, die richtige Request Methode verwenden, Callbacks, ContentType festlegen und im Kontext mit der neuen Shopware 6 API sogar zudem Zugriffscredentials setzen. Weil all das nun hinter ein einfach zu verwendendes Interface gewandert ist, bietet die HttpClient Klasse die Grundlage für ein “easy-to-use” HTTP Request-Handling ohne großen Overhead wie nachfolgender Auszug zeigt: 011TdAyBByb3tlaI

Zahlreiche weitere, kleine Helferlein sowie Features sorgen in der neuen Storefront für eine übersichtliche, moderne JS Code-Basis die es dem Entwickler ermöglicht, schnell gewünschte Ergebnisse zu erzielen und den Funktionsumfang auf seine projektspezifischen Bedürfnisse anzupassen. ### Webpack Module Bundler Zu guter letzt erfährst Du im nachfolgenden, was für die Verwendung der genannten neuen Technologien aus verschiedenen Aspekten heraus essentiell ist. Während bei Shopware 5 noch Grunt als TaskRunner im Einsatz war um beispielsweise CSS und JS Code zu kompilieren, kommt Shopware 6 nun mit dem Module Builder Webpack im Schlepptau. Internationale Größen wie Airbnb, Trivago, Adobe, Slack und Co. setzen schon seit geraumer Zeit auf Webpack, welches sich mittlerweile langsam aber sicher zu einer “State of the art”-Technologie entwickelt hat. Dank Webpack ist es uns beispielsweise möglich, den in ECMAScript 6 geschriebenen JS-Code mittels Babel Compiler in Cross Browser kompatibles JavaScript umzuwandeln. Ferner kümmert sich Webpack dank zahlreicher Plugins und Loader um das Kompilieren von SCSS zu CSS, das Erzeugen browser-spezifischer CSS Anweisungen (Autoprefixing), die Minimierung der Kompilate, etc. Dies eröffnet zudem weitere Möglichkeiten, die vor allem im Enterprise Sektor interessant sind. Mittels Webpack lassen sich, nur um einen kleinen Ausblick in die Zukunft zu wagen, sogenannte Entrypoints realisieren. Kleine, geschnürte Pakete sozusagen, die je View nur den Code beinhalten, der dort auch tatsächlich benötigt wird. Dies reduziert ungewollte Side-Effects bei Anpassungen, die Dateigrößen von CSS und JS Kompilaten sowie die Last für den Client, sprich den Browser da nur das JavaScript läuft, das im Kontext der jeweiligen View zum Einsatz kommt. Natürlich ist dies nicht einfach so ohne weiteres Zutun möglich. Wie man das allerdings am Besten anstellt und welche Aufwände hierfür anfallen, sollte Thema eines anderen Beitrags sein. Dass man im Entwicklungsstadium eines Projekts andere Anforderungen an die Systemumgebung hat als dies im Produktionsmodus der Fall ist, kann auch im Bereich der Storefront dank der flexiblen Webpack Konfiguration berücksichtigt werden. Die hierfür zur Verfügung stehenden Konfigurationsdateien lauten: * webpack.base.config.js — Beinhaltet die Grundkonfiguration, die für alle verfügbaren Environments gelten * webpack.dev.config.js — Hier finden sich Konfigurationen, die für Webpack im Modus “dev” oder “watch” gelten * webpack.hot.config.js — Konfigurationen, die explizit für den eingebauten Webpack HMR Modus gelten * webpack.prod.config.js — Speziell für den Produktionsmodus angepasste Konfiguration Je eingestellter Environment (dev|watch|hot|prod) werden die Basiskonfiguration und die spezifische Konfiguration zusammengemerged. Es entsteht daraus die finale Konfiguration von Webpack mittels welcher schließlich JS und CSS Files erzeugt, mitsamt notwendiger Ressourcen (Fonts, Images, etc.) in den Build-Folder gezogen und bereitgestellt werden. Eine ausführliche Dokumentation steht auf der offiziellen Website von Webpack zur Verfügung und kann für eigene Anpassungen zu Rate gezogen werden. ### Fazit Seit Shopware 5 ist viel geschehen, einiges hat sich grundlegend verändert und es wurde mit der Zeit gegangen. Für mehr Qualität, mehr Abgrenzung, mehr Möglichkeiten — auch in der Storefront. Dass dieser Umstand ein gewisses Maß an Umdenken erfordert, liegt in der Natur der Sache. Doch nur so ist es möglich, Shopware 6 und die damit zu realisierenden Projekte auf ein neues Level zu bringen. Der Markt entwickelt sich weiter und mit ihm die Anforderungen. Die neue Shopware 6 Storefront gibt Dir und Deinem Projekt alle Möglichkeiten an die Hand um auch künftig mit der Zeit gehen zu können. #### Das könnte Dich auch interessieren: Shopware 6 - Entdecke die technischen Highlights vom Early Access Version 2 Einblicke in die Core Architektur von Shopware 6 API first - entdecke die Möglichkeiten mit unserer Core Architektur

Bleibe auf dem Laufenden

Du interessierst Dich für weiteren Developer Content? Dann folge uns und erhalte aktuelle Informationen zu Produkt-Releases, Updates, Security-Hinweisen, der Academy und weiteren wichtigen technischen Insights aus dem Shopware Universum und der Community.

Jetzt auf Twitter folgen

Jetzt zum Developer Newsletter anmelden

Das solltest Du über die neue Shopware 6 Storefront wissen

Newsletter

Über Shopware

Produkt

Lösungen

Ressourcen

Community