Shopware Themes und Templating mit Twig erklärt

Wer in Shopware mehr als Farben und Fonts anpassen will, landet früher oder später beim Twig-Templating. Das klingt nach Entwickler-Thema, ist es auch, aber du als Händler oder Shop-Betreiber solltest die Grundprinzipien kennen. Sonst weißt du nicht, was Agenturen oder Entwickler überhaupt tun, wenn sie an deinem Theme arbeiten, und du kannst nicht einschätzen, ob eine Anforderung fünf Stunden oder fünfzig Stunden braucht.

Was ein Shopware-Theme ist

Ein Theme in Shopware 6 ist im Kern ein strukturiertes Bündel aus drei Bestandteilen: Twig-Templates (für die HTML-Struktur), SCSS-Dateien (für das Styling) und JavaScript-Plugins (für clientseitige Interaktionen). Hinzu kommen Theme-Konfigurationsdateien, über die sich bestimmte Werte wie Farben, Fonts und Abstände als Variable steuern lassen.

Shopware liefert ein Standard-Theme mit, das den Namen „Storefront” trägt. Dieses Theme ist gleichzeitig die Basis für alles, was du anpasst. Du arbeitest dabei fast nie direkt auf dem Standard-Theme, sondern erstellst ein sogenanntes Child-Theme, das sich die Standard-Dateien per Vererbung holt und nur die Teile überschreibt, die du ändern willst.

Das ist ein wichtiges Prinzip: Shopware-Themes überschreiben nie die Original-Dateien des Systems. Sie legen stattdessen neue Dateien an denselben relativen Pfaden ab. Shopware erkennt das und benutzt bei der Seitenausgabe automatisch die Theme-Datei, wenn sie vorhanden ist, und sonst die Core-Version.

Twig: Die Template-Sprache von Shopware

Twig ist eine Template-Engine, die aus dem Symfony-Ökosystem stammt. Shopware 6 basiert auf Symfony, deshalb liegt Twig als Templating-Lösung nahe. Im Unterschied zu reinem HTML erlaubt Twig, dynamische Inhalte direkt im Template zu steuern.

Ein einfaches Beispiel: Der Produktname auf einer Produktdetailseite kommt nicht als statischer Text ins Template, sondern als Variable. In Twig sieht das so aus:

<h1>{{ page.product.name }}</h1>

Twig kennt außerdem Schleifen für Listen, Bedingungen und sogenannte Blöcke. Blöcke sind der entscheidende Mechanismus für Template-Vererbung.

Template-Vererbung mit sw_extends und Blöcken

Jedes Twig-Template in Shopware definiert benannte Blöcke. Ein Block ist ein Bereich im Template, der von einem anderen Template gezielt überschrieben oder erweitert werden kann. Statt der ganzen Datei zu kopieren, reichst du nur den Block an, den du ändern willst.

Der Shopware-eigene Tag sw_extends ersetzt den normalen Twig-extends-Tag und sichert dabei, dass die Shopware-spezifische Vererbungskette korrekt abgearbeitet wird. Das ist wichtig, sobald mehrere Plugins dasselbe Template erweitern, weil sw_extends die Erweiterungen kettet, anstatt sie gegenseitig zu überschreiben.

In der Praxis sieht ein Überschreiben so aus: Du legst eine Datei unter demselben Pfad in deinem Theme ab, verwendest sw_extends mit dem Original, und überschreibst nur den Block, den du brauchst. Der Rest der Seite bleibt unverändert und wird weiter aus dem Core gezogen.

Der Theme-Manager: Was ohne Code geht

Für viele Anpassungen brauchst du kein Twig. Im Shopware-Backend gibt es einen Theme-Manager, über den du folgende Dinge direkt setzen kannst:

• Primärfarbe, Akzentfarbe und Hintergrundfarbe
• Schriftart und Schriftgrößen (innerhalb der Theme-Konfiguration)
• Logo und Favicon
• Button-Stile, Link-Farben und Hover-Zustände
• Abstände und einige Raster-Einstellungen

Was genau konfigurierbar ist, hängt vom jeweiligen Theme ab. Das Standard-Storefront-Theme bietet eine gute Basis. Kommerzielle Themes aus dem Shopware Store oder eigene Themes können diese Konfigurationsmöglichkeiten erweitern oder einschränken.

Der Theme-Manager reicht, wenn du ein konsistentes Erscheinungsbild auf Basis des Standard-Layouts willst. Sobald du den Seitenaufbau veränderst, eigene Sektionen hinzufügst oder den Checkout anpasst, brauchst du ein eigenes Theme mit angepassten Twig-Templates.

Child-Theme erstellen: Wann es sich lohnt

Ein Child-Theme ist der empfohlene Weg, sobald du mehr als superfizielle Anpassungen am Design machst. Es erbt alles vom Eltern-Theme und überschreibt nur gezielt, was du brauchst. Updates des Eltern-Themes werden dadurch meistens problemlos eingespielt, weil du den Standard-Code nicht angefasst hast.

Typische Szenarien, bei denen ein Child-Theme sinnvoll ist:

• Du willst das Header-Layout verändern, zum Beispiel die Navigation umstrukturieren oder ein Mega-Menü einbauen.
• Die Produktdetailseite soll anders aufgebaut sein als im Standard, mit eigenen Bild-Slider-Logik oder angepassten Informationsblöcken.
• Du brauchst eigene Kategorie-Layouts für unterschiedliche Warenbereiche.
• Der Checkout soll im Branding stärker abweichen oder bestimmte Felder anders platzieren.

Ein Child-Theme wird als eigenständiges Shopware-Plugin entwickelt und registriert. Es hat eine eigene theme.json, die die Eltern-Theme-Abhängigkeit definiert, und eine Verzeichnisstruktur, die der Shopware-Konvention folgt. Die Storefront-Templates liegen unter Resources/views/storefront/, SCSS unter Resources/app/storefront/src/scss/.

SCSS und der Build-Prozess

Shopware kompiliert SCSS-Dateien beim Theme-Build zu CSS. Das passiert nicht automatisch im laufenden Betrieb, sondern muss explizit ausgelöst werden, entweder über die Shopware-CLI oder das Backend. Bei aktiver Entwicklung bedeutet das einen Workflow mit lokalem Build und anschließendem Deployment.

Wer mit Tailwind CSS oder anderen Utility-Frameworks arbeiten will, muss das in den Shopware-Build-Prozess integrieren. Das ist machbar, aber nicht trivial. Für die meisten Projekte ist natives SCSS mit BEM-Methodologie die sauberere Wahl, weil sie weniger Reibung mit dem Shopware-Build-System erzeugt.

Plugins können eigene SCSS-Dateien mitliefern. Diese werden beim Theme-Kompilieren eingebunden. Wenn viele Plugins eigene Styles hinzufügen, entsteht schnell unkontrolliertes CSS-Gewicht. Das ist eine der häufigsten Ursachen für schlechte Core Web Vitals in Shopware-Shops, neben zu vielen JavaScript-Dateien.

Plugins als Theme-Erweiterer

Nicht jede visuelle Anpassung kommt aus dem Theme. Plugins können ebenfalls Twig-Templates überschreiben, eigene Blöcke einfügen und JavaScript mitliefern. Das Shopware-Plugin-System ist dafür ausdrücklich ausgelegt.

Das hat einen praktischen Vorteil: Du kannst Funktionen, die optische Änderungen mit sich bringen, sauber als Plugin paketieren, ohne das Theme selbst zu komplizieren. Zum Beispiel ein Plugin, das auf der Produktdetailseite einen Konfigurator einblendet, oder eines, das in der Kategorie-Ansicht ein Badging-System für neue Produkte hinzufügt.

Die Kehrseite: Wenn mehrere Plugins denselben Template-Block erweitern wollen, muss die Reihenfolge stimmen, und manchmal ist ein manuell erstelltes Zusammenführungs-Template nötig. Das ist ein bekanntes Problem bei Projekten mit vielen aktiven Plugins und sollte bei der Plugin-Auswahl berücksichtigt werden.

Der Unterschied zur klassischen Storefront-Lösung zeigt sich deutlich, wenn du die Shopware Headless Store API in Betracht ziehst. Dort entfällt das Twig-Templating vollständig, weil das Frontend komplett separat entwickelt wird.

Häufige Fragen

Muss ich Twig können, um ein Shopware-Theme anzupassen?

Für reine Farb- und Logo-Anpassungen nein. Sobald du aber Seitenstrukturen veränderst, Blöcke verschiebst oder eigene Inhalte einfügst, wirst du Twig-Dateien bearbeiten. Twig ist kein schwieriges System, aber du brauchst ein Grundverständnis der Vererbungslogik, sonst entstehen leicht Fehler, die schwer zu debuggen sind.

Kann ich ein beliebiges Drittanbieter-Theme als Basis nehmen?

Ja, technisch ist das möglich. Vorsicht ist geboten, wenn das Drittanbieter-Theme nicht aktiv gepflegt wird. Nach Shopware-Minor-Updates können Template-Dateien veralten, was zu Darstellungsfehlern oder fehlenden Funktionen führt. Wir empfehlen bei Kundenprojekten in der Regel, auf dem Standard-Storefront-Theme aufzubauen und nur die nötigen Teile per Child-Theme zu überschreiben. Das hält den Update-Aufwand niedrig.

Was passiert mit meinem Theme bei einem Shopware-Update?

Child-Themes, die sauber nach dem Vererbungsprinzip gebaut sind, überleben Updates meistens ohne Probleme. Kritisch wird es, wenn das Update Core-Templates verändert, die du überschrieben hast. Dann musst du prüfen, ob deine Überschreibung noch kompatibel ist. Das ist kein Problem, wenn du weißt, welche Templates du angepasst hast. Deshalb führen wir in unseren Projekten eine saubere Liste aller Theme-Überschreibungen.

Ist es besser, alles im Theme oder als Plugin zu lösen?

Als Faustregel: Layout und Design gehören ins Theme, Funktionalität in Plugins. Ein Plugin, das auch optische Änderungen mitbringt, ist trotzdem ein Plugin, kein Theme. Wenn du diese Grenze konsequent ziehst, bleibt das Theme schlank und Plugins bleiben unabhängig austauschbar. In der Praxis gibt es Grauzonen, die eine Einzelfallentscheidung erfordern.

Weiterführende Überlegungen

Das Twig-Templating ist eng mit dem verknüpft, wie die Shopware Storefront insgesamt aufgebaut ist. Wer einen neuen Shop auf Shopware aufsetzen will, findet auf unserer Seite zur Onlineshop-Erstellung eine Übersicht, wie wir Projekte planen und umsetzen. Und wer wissen will, ob sein bestehendes Theme technisch noch auf der Höhe ist, spricht uns am besten direkt an.