Best practices für wirklich individuelle Shops/Themes "from scratch"

Shopware 6 (German) Themes & Design
1

Hallo Community,

ich beschäftige mich erst seit dem Release von Shopware 6 mit Shopware. Vom Backend/Administrationsbereich bin ich sehr begeistert, aber die Storefront taugt mir leider nicht wirklich. Bisher habe ich zwei Shops mit „individuellem“ Theme umgesetzt. Dabei habe ich existierende Templates überschrieben, alle Twig-Blocks beibehalten und neue hinzugefügt um die Kompatibilität mit Drittanbieter-Plugins zu garantieren. Am Ende sitzt man dann mehr oder weniger vor einem Chaos an Templateschnipseln, mehrfach überschriebenen CSS-Klassen und stört sich an Abständen, die schon von Haus aus nicht einheitlich sind etc… Wirkliche Freiheit hat man nur bei eigenen CMS-Elementen.

 

Ich frage mich, ob es eine gute Idee ist für wirklich individuelle Shops und höhere Design-Ansprüche komplett eigene Themes „from scratch“ zu schreiben oder ob das bei Shopware eher unüblich ist?

 

Möglichkeiten die ich für mich sehe sind:

  • Aufgeräumtes und minimales Markup, CSS und JS

  • Absolute Freiheit im Layout und Design

  • Effizientes und abgespecktes Frontend nur mit den Funktionen, die man wirklich braucht 

 

Probleme die ich dabei sehe sind:

  • Alle JS-Funktionen (Warenkorb, Cookies etc.) müsste man natürlich auch selbst schreiben oder irgendwie vererben

  • Man verliert die Kompatibilität mit Drittanbieter-Plugins im Frontend

 

Vue-Storefront habe ich mir auch schon angesehen. Hier hat man natürlich schon mehr Freiheit nur habe ich keine Lust für jeden Auftritt eine Node.js Instanz aufzusetzen. Wäre froh über ein paar Erfahrungen, Tipps und „Best pratices“ zu diesem Thema, danke!

 

2

Hallo @tomtomd Dein Beitrag ist ja schon paar Monate alt und leider hat bisher noch keiner geantwortet. Wie sieht es bei dir inzwischen aus? Hast du bereits angefangen?

3

Hi @yicdeniz, ja leider hat noch niemand geantwortet. Ich kann mir aber vorstellen, das auch andere den Ansatz in Betracht ziehen. Ich teste das gerade ein wenig aus. Man muss das Storefront ein bisschen „hacken“ um wirklich alles rauszuwerfen was man nicht braucht.

Die erste Ebene ist die theme.json, in der man alle Abhängigkeiten mit @Storefront entfernen muss ggf. auch bei den Views.

Für die Skripte habe ich im Theme-Plugin eine webpack.config.js angelegt, die alle Entrypoints außer die von anderen Plugins und dem Theme überschreibt. Somit erhält man am Ende ein Bundle, dass nur die Skripte enthält, die im Theme oder anderen Plugins benötigt werden.

Beim Scss war es etwas schwierig, weil Shopware hier nicht Webpack, sondern phpscss zum Kompilieren verwendet und sich die Pfade nicht überschreiben lassen (zumindest hab ich keinen Weg gefunden). Wenn man hier z.B. auch Bootstrap im Zusammenhang mit npm nutzen möchte, sollte man sich ein Skript schreiben, das die benötigten Packages von node_modules in den scss Ordner kopiert. Es sei denn man möchte den kompletten node_modules Ordner später mit deployen. Im Repository von Shopware sieht man, dass sie das selbst über das copy-to-vendor.js Skript auch so gelöst haben.

Da ich auch Bootstrap verwende, habe ich mir die Twig-Templates dann vorerst alle in mein Theme kopiert und arbeite nur an denen, die relevant sind. Dabei versuche ich wenn es geht auf die existierenden Blöcke zu achten, oft muss ich die Struktur aber komplett umwerfen. Zumindest beim base.html.twig sollte man allerdings die meisten Blöcke beibehalten, weil dort z.B. alle JS-Variablen für die JS-Plugins gesetzt werden. Evtl. werde ich hier auch manche Tempaltes wieder von @Storefront vererben, das wird sich dann zeigen. Ein eigenes Kapitel werden wohl auch noch die Pagelets (z.B. Offcanvas Warenkorb), die normalerweise über Ajax geladen werden.

Bei den JS-Plugins von Shopware war ich überrascht, wie einfach sich diese konfigurieren und in einen komplett andere Template-Struktur integrieren lassen.

Sobald im Zusammenhang ein Plugin aus dem Store genutzt werden soll, muss man dann natürlich seine bzw. die Templates des Plugins anpassen, da entsteht dann immer zusätzlicher Aufwand.

Hoffe ich konnte einen guten Einblick in meine WIP geben :wink:

2 „Gefällt mir“
4

Hi @tomtomd ,

dein Post ist zwar schon länger her, aber wir beschäftigen uns auch seit einiger Zeit mit der „optimalen“ Herangehensweise für wirklich individuelle Themes. Leider erkennt man ja inzwischen bei 99% der Shopware Shops so schon, dass es Shopware ist - eigentlich traurig. Was hat sich bei dir in der Zwischenzeit getan?

Wir werden uns wahrscheinlich langfristig von dem ganzen Standard-Storefront rumgefriemel mit Twig, Bootstrap und weiteren Krankheiten ganz verabschieden und eine eigene headless Storefront mit VueJS & Tailwind aufbauen. Manko daran ist, dass aktuell quasi kein PlugIn „headless fähig“ geschrieben wird, ich hoffe das ändert sich dann irgendwann noch.

5

Hi @m.baumhoegger, genau das ist mittlerweile auch unsere Herangehensweise. Das mit dem Custom PHP Theme ist einfach zu viel Overhead und „Hackerei“. Auf Dauer hat man damit nur Probleme…

Eigentlich ist Shopware 6 ja genau wegen der API so interessant. Die Architektur der normalen Themes lässt aber echt zu wünschen übrig und ist keine gute Basis für Custom Code. Als Plugin Hersteller wurden wir vor kurzem darüber informiert, dass Plugins in Zukunft wohl auch die Auszeichnung „PWA kompatibel“ erhalten können. Ob das aber jeder Hersteller macht sei mal dahingestellt.

Bei einem echten Custom Storefront scheint man nicht drum herum zu kommen sich auch um die Implementierung eines eigenen Frontends für Plugins zu kümmern bzw. Features komplett ohne Plugins zu bauen. Bei Plugins, die stark in das Backend oder die Administration eingreifen, spart man sich zumindest die halbe Arbeit :sweat_smile: Das muss man Kunden dann wohl entsprechend kommunizieren.

1 „Gefällt mir“
6

@tomtomd Cool, danke für deine Antwort. Das mit der PlugIn Auszeichnung ist ja auch längst überfällig, wenn man schon sein System überall als „API first“ vermarktet. Die PlugIn Anpassungen für solche, die noch nicht API fähig entwickelt wurden, muss man dann einfach mit einkalkulieren. Dafür hat man dann auch ein top System, welches sich auch über viele Jahre prima betreiben lässt.

7

@m.baumhoegger ich vermute, dass man das „PWA kompatibel“ Label erhält, wenn das Plugin mit der offiziellen Shopware PWA Lösung kompatibel ist. Dort gibt es ja auch vordefinierte Slots im Frontend, an denen man Plugin Code integrieren kann. Das gilt dann natürlich nicht, wenn man (sinnvollerweise) noch einen Schritt weiter geht und ein komplett eigenes Frontend mit dem shopware-pwa npm Package aufsetzt. Ob ein Plugin grundsätzlich über die API bedienbar ist, ist dann nochmal ein anderes Thema. Wobei das ja zumindest für die Storefront API einhergeht. Dass ein Plugin vollständig über alle APIs bedienbar ist (auch Admin) kann man wohl nur hoffen :sweat_smile:

8

@tomtomd Das stimmt, wobei die Shopware PWA ja immerhin auch auf die API angewiesen ist und die Datenbasis dann die selbe sein müsste, egal ob Shopware PWA oder ganz custom. Die Shopware PWA hat uns überhaupt nicht überzeugt. Da rollt fast die gleiche Anpassungs-Welle auf einen zu wie bei der Standard Storefront. Für die PWA gibt es zwar auch eine entsprechende Erweiterung für das Backend, die headless optimierte Routen hinzufügt (eigentlich auch uncool, dass das überhaupt nötig ist bei einem Api first system aber was solls). Aber immerhin kann man die Daten dann so oder so ansteuern, sofern das entsprechende PlugIn halt API Routen bereitstellt für alle relevanten Controller Actions. Zum Glück hat man wenigstens bei den custom CMS Elementen keine Probleme, da ist es herzlich egal, ob man das Frontend Template dann in twig oder ganz woanders schreibt.

Bei uns geht in Kürze ein Projekt live, in dem wir auf jegliche von Shopware bereitgestellten Packages verzichtet haben und mit einer NuxtJS App direkt auf die Store API gehen. Das war ein Krampf :smiley: Ich hoffe einfach, dass Shopware dem API Anspruch doch noch mehr gerecht wird. Immerhin sind gefühlt 98% der PlugIns sowieso nur relevant für einfachste Do-it-yourself Shops.

9

Um das Thema mal aufzuwärmen:

Nach fast 1 Jahr Theme Entwicklung mit Shopware und Less, Unmengen an zwanghaft vergebenen Klassennamen und endlosem Sass Syntax, konnte ich mich nur noch über die Suchfunktion wirklich zurecht finden in meinen Stylesheets. Jetzt arbeite ich gerade an einem Projekt mit Tailwind CSS und Statamic. Ich war anfangs sehr skeptisch, als ich diese Abnormitäten an CSS Klassen pro HTML Element gesehen hab.

Nach ein paar Tagen Einarbeitungszeit bin ich mit Tailwind aber unfassbar schnell voran gekommen, viel schneller und effizienter als mit klassischem CSS bzw. mit Less. Wenn man wiederkehrende Elemente in kleine Templates auslagert ist auch der Wartungsaufwand bei Änderungen echt überschaubar.

Jetzt steht ja Shopware 6.5 im Raum und würde sowieso dazu führen, sich innerhalb des nächsten Jahres die ganzen Template Files anzusehen und zu überarbeiten. Meine Frage ist jetzt, ob eine Entwicklung mit einem eigenen Theme auf Tailwind CSS Basis ohne Bootstrap überhaupt möglich wäre, weil die meisten Plugins ja ihre HTML Files haben, die ich ja quasi komplett überschreiben müsste in den meisten Fällen und so auch eine gewisse Updatesicherheit verliere.

Hat jemand von euch schon einen Shop komplett ohne Bootstrap und auf Tailwind CSS gebaut?

Lg Alex

10

Ich hatte mir zwischenzeitlich auch mal Tailwind angesehen und muss zugeben, dass ich kein so großer Fan vom Utility-First-Ansatz bin. Ich arbeite schon lange mit Bootstrap und für die meisten Themen reichen die Utility-Klassen von Bootstrap aus (Utility API · Bootstrap v5.3). Sobald es sehr custom wird, kommt man eigentlich eh nicht um eigene Klassen und eigene Komponenten rum. In Tailwind geht das zwar auch ohne aber dafür ist das HTML dann bloated. Das ist persönliche Präferenz imo.

Flagbit arbeitet schon seit längerem an diesem Projekt => GitHub - flagbit/shopware6-tailwind-theme: Shopware 6 Tailwindcss Theme

Als Plugin Hersteller müssen wir uns mit der Storefront anfreunden, da wir diese ja entsprechend überschreiben oder erweitern müssen, wie du erwähnt hast. Plugin-User mit Custom Themes müssen sich dann entweder selbst um die Integration kümmern oder können auf uns zurückgreifen.

Projekten mit höherem Budget würde ich fast immer Vue Storefront oder ein eigenes API basiertes Frontend empfehlen. Da ist man wirklich komplett unabhängig in der Wahl des Tech-Stacks und den meisten Shopware Updates. Ansonsten ist es immer eine Kosten-Nutzen-Frage, auch wenn man als Dev immer gerne die schönste und performanteste Lösung umsetzen möchte.

11

Danke für deinen Input. Mit Tailwind muss man einfach mal arbeiten, ich war auch sehr abgeneigt und hab aber innerhalb weniger Tage inkl. Einarbeitungszeit ein Projekt umgesetzt, für das ich vermutlich mit meinen doch recht brauchbaren CSS und Sass Kenntnisse niemals so sauber und responsive umgesetzt hätte.

Ich habe schon befürchtet, dass ich zumindest auf die Vue Storefront gehen muss. Das Tailwind Theme von Flagbit habe ich mir auch schon angeschaut. Vielleicht werde ich darauf zurückgreifen bzw. mir das mal in einer Installation anschauen.

12

Nachtrag: Außerdem gibt es ja noch Shopware Frontends, was PWA in Zukunft ablöst bzw. schon abgelöst hat: GitHub - shopware/frontends: Shopware Frontends is a framework for building custom, headless storefronts with Shopware 6.

13

Sehr interessant! Das heißt ich muss jetzt auch noch Vue und Nuxt lernen :smiley:
Aber scheint ein ganz vernünftiges Konzept zu sein. Danke für den Link.

14

Gerne, ich versteh zwar noch nicht ganz, wie man dann Plugins dafür anbieten kann, aber vll. ist das bei Custom Storefronts auch garnicht gewollt? Evtl. kann man in Zukunft als Plugin-Hersteller aber auch Composables mitliefern. Wird sich zeigen. :man_shrugging:

15

Analog zu einem Cloud Store. Plugins können per API ihre Funktion zur Verfügung stellen.

16

Yes backend-seitig ist das klar, aber kann man dann in Plugins auch HTML für Shopware Frontends integrieren? Im Repo oben gibt es ja eigene NuxtJS Komponenten für die Standard-CMS-Elemente von Shopware. Das würde ja dafür sprechen, dass man dann nochmal eigene NuxtJS Komponenten mitliefern muss. Oder geht das garnicht und man bietet einfach nur die Daten über die API?

17

So sehe ich das dann auch so. Bisher hat ja viel darauf gebaut, dass Pluginhersteller über die Twig Blöcke bestehender Template-Dateien zu erweitern, in denen dann ja auch zumindest etwas Logik implementiert ist. Es müsste dann eine Referenz geben, wie die Daten die von der API kommen genau zu benutze sind, oder der Hersteller liefert Composables mit.

18

@marco.steinhaeuser Vielleicht gibt ein paar offizielle Referenzen, die Shopware PWA oder sogar Shopware Frontends nutzen? Wäre mal interessant zu sehen, was man daraus alles machen kann.

19

Zu diesem Thema gab’s doch neulich erst einen sehr schönen Blogpost von Björn Meyer: Frontend API with Nuxt + Nitro = Flexibility 🐙

Als Referenzen kann ich diese beiden mal in den Ring werfen, die mit Frontends umgesetzt wurden:

Da kann man sicher WPO-mässig noch viel machen aber man sieht schonmal, wohin die Richtung geht.

Auch für eine PWA habe ich ein wunderschönes Beispiel, darf aber nicht teilen :frowning:

2 „Gefällt mir“
20

Mal ne Frage zu Shopware Frontends. Wir haben aktuell ein 5er-Projekt, dass fast in jeder Ecke angepasst wurde und das wir zu 6 migrieren wollen/müssen.

Es wird fast kein externen (Frontend-)Plugin genutzt. Einzig PayPal ist/wäre eine Option. Ist das Shopware-eigene PayPal-Plugin kompatibel mit Shopware Frontends? Vermutlich nicht - d.h. die Frontend-Logik muss individuell entwickelt werden?

Oder gibt es da bereits Lösungen, die PayPal Checkout in Shopware Frontends integrieren?