Shopware 6.7.11: Vite-Devserver und Twig-UX

Mit Shopware 6.7.11.0 (Release News Juni 2026) bekommt die klassische Twig-Storefront das größte Frontend-Update seit langem: ein Vite-Devserver ohne zusätzlichen Proxy, ein neues Komponentensystem auf Basis von Twig UX Components, Theme-Konfigurationen als native CSS-Custom-Properties und ein globales window.Shopware-Event-System. Dieser Beitrag erklärt die Neuerungen aus Entwicklersicht, ordnet sie in die Vite-Migration ein und zeigt, wie Sie Ihr Shopware-Theme Schritt für Schritt modernisieren.

Was sich in Shopware 6.7.11 für die Storefront ändert

Anders als die Headless-Variante mit Vue und Nuxt bleibt hier die serverseitig gerenderte Twig-Storefront das Fundament. Shopware modernisiert sie behutsam von innen heraus, statt sie zu ersetzen. Die vier zentralen Neuerungen in 6.7.11.0 laut Release Notes (Shopware Documentation):

Diese Bausteine greifen ineinander: Komponenten lassen sich isoliert entwickeln, ihre Styles über CSS-Variablen aus dem Theme steuern, ihr Verhalten über das globale Event-System koppeln und der gesamte Zyklus läuft über den schnellen Vite-Devserver. Wer schon einmal eine Migration von Shopware 6.6 auf 6.7 begleitet hat, kennt das Muster: Shopware bereitet die Architektur für den nächsten Major-Sprung vor.

Wichtig für die Einordnung: Es handelt sich um eine Evolution, nicht um einen Bruch. Die serverseitig gerenderte Storefront bleibt mit allen Vorteilen erhalten, etwa der guten Indexierbarkeit für Suchmaschinen und kurzen Time-to-First-Byte-Werten bei sauberem Caching. Die neuen Werkzeuge legen sich darüber, ohne dass Sie Ihre Architektur grundlegend umstellen müssten. Genau das macht den Umstieg attraktiv: Sie modernisieren in Ihrem Tempo und behalten die Kontrolle, statt einem erzwungenen Big-Bang-Wechsel zu folgen.

Vite-Devserver: Schluss mit dem Proxy-Setup

Bisher lief die lokale Storefront-Entwicklung über composer watch:storefront. Dieser Befehl startete einen Hot-Proxy, der vor den eigentlichen Shop geschaltet wurde, Assets neu baute und den Browser aktualisierte. Das funktionierte, brachte aber Reibung: ein zusätzlicher Port, ein Proxy-Layer und ein vollständiger Theme-Build bei jeder Änderung. In Shopware 6.7.11 wird composer watch:storefront zugunsten des neuen Devservers als veraltet markiert (Shopware Documentation).

# Neu ab 6.7.11: Vite-Devserver, kein Proxy noetig
composer storefront:dev-server

# Bisheriger Befehl, ab 6.7.11 deprecated
composer watch:storefront

Der neue storefront:dev-server setzt auf den Vite-Devserver. Änderungen an SCSS und JavaScript werden direkt über Vite ausgeliefert, ohne dass ein vorgelagerter Proxy nötig ist. Sie rufen Ihren normalen Storefront-Pfad auf, der Devserver klinkt sich ein und liefert die geänderten Module aus (Shopware Release News Juni 2026). Warum das spürbar ist, zeigt ein Blick auf die Admin-Migration: Vite baut die Core-Administration in rund 18 Sekunden, eine Ersparnis von über 50 % (Shopware Documentation) gegenüber dem bisherigen Webpack-Build.

Vite hat sich in der Frontend-Welt als Standard etabliert: In der Entwicklerbefragung State of JS 2025 erreichte das Tool rund 92 % Zufriedenheit (State of JS 2025) und gehört seit Jahren zu den am positivsten bewerteten Build-Werkzeugen. Der Grund liegt im Dev-Modell: Statt das gesamte Bundle neu zu bauen, liefert Vite nur die geänderte Datei über natives ES-Module-Loading neu aus, was Hot Module Replacement deutlich beschleunigt (Vite-Dokumentation).

Technisch lehnt sich der Storefront-Devserver an die Infrastruktur an, die Shopware bereits für die Administration aufgebaut hat. Dort lädt das Symfony-Bundle pentatrion_vite die korrekten Asset-Dateien anhand einer generierten entrypoints.json, die das Gegenstück vite-plugin-symfony erzeugt (Shopware Documentation). Im Entwicklungsmodus kommt eine eigene Manifest-Datei zum Einsatz, sodass mehrere Bundles parallel ihre Assets ausliefern können. Für Sie als Händler bedeutet das vor allem: weniger bewegliche Teile im lokalen Setup und ein Devserver, der sich nahtlos in den bestehenden Storefront-Aufruf einklinkt.

Ein praktisches Detail rundet das Bild ab: Die theme.json unterstützt nun Einzeldatei-Referenzen aus anderen Bundles über eine bundle-relative Syntax wie @BundleName/path/to/file, sowohl für style- als auch für script-Einträge (Shopware Documentation). Das erleichtert es, Theme-Assets sauber zu organisieren und gezielt aus mehreren Erweiterungen zusammenzuführen, statt monolithische Sammeldateien zu pflegen.

Twig-UX-Komponenten: wiederverwendbare Bausteine

Das neue Komponentensystem ist der strategisch wichtigste Teil des Releases. Twig UX Components bringen ein Konzept in die Storefront, das aus modernen Frontend-Frameworks bekannt ist: gekapselte, parametrisierbare Bausteine, die sich an beliebiger Stelle wiederverwenden lassen, statt große Templates per Block-Override zu überschreiben.

{# Wiederverwendbare Komponente mit Props #}
{% props label, value, variant = 'default' %}

<span class="price-badge price-badge--{{ variant }}">
  <span class="price-badge__label">{{ label }}</span>
  <span class="price-badge__value">{{ value }}</span>
</span>

{# Komponente an beliebiger Stelle einbinden #}
<twig:PriceBadge label="Sofort lieferbar" value="{{ product.calculatedPrice }}" variant="highlight" />

Der Vorteil gegenüber dem klassischen Block-System: Statt zentrale Templates global zu überschreiben und damit kollidierende Plugin-Anpassungen zu riskieren, kapseln Komponenten ihre Markup-, Style- und Verhaltenslogik. Das senkt den Wartungsaufwand und macht Updates planbarer. Wer häufig mit verschachtelten Shopping Experiences und Pagebuilder-Elementen arbeitet, profitiert besonders, weil sich wiederkehrende UI-Muster konsolidieren lassen.

• Kapselung statt globaler Overrides reduziert Seiteneffekte zwischen Plugins und Theme.
• Props machen Komponenten parametrisierbar und damit in vielen Kontexten wiederverwendbar.
• Eigene SCSS- und JS-Behandlung je Komponente, die über Vite kompiliert wird (Shopware Documentation).
• Schrittweise Einführung möglich: bestehende Templates bleiben, neue Bereiche entstehen als Komponenten.

Der wirtschaftliche Kern ist die Wartbarkeit über die Zeit. Wer ein Theme über Jahre pflegt, kennt das Problem kollidierender Block-Overrides: Ein Update der Standard-Storefront bricht eine alte Anpassung, und die Fehlersuche frisst Stunden. Komponenten mit klar definierten Props verschieben diese Last, weil ihre Schnittstelle stabil bleibt, während sich die Implementierung dahinter ändern darf. Das macht künftige Updates planbarer und reduziert das Risiko, dass sich technische Schulden im Frontend ansammeln.

Theme-Werte als native CSS-Custom-Properties

Bisher wurden Theme-Konfigurationen wie Markenfarben oder Abstände über SCSS-Variablen abgebildet und beim Build in feste Werte kompiliert. Änderungen erforderten stets einen Theme-Recompile. In 6.7.11 stehen dieselben Werte zusätzlich als native CSS-Custom-Properties bereit, mit identischen Namen (Shopware Documentation).

/* Bisher: SCSS-Variable, beim Build fest aufgelöst */
.product-box__price {
  color: $sw-color-brand-primary;
}

/* Neu: native CSS-Custom-Property, zur Laufzeit auflösbar */
.product-box__price {
  color: var(--sw-color-brand-primary);
}

CSS-Custom-Properties werden von allen modernen Browsern unterstützt und gelten als Baseline-Funktion (Can I Use). Laut HTTP Archive Web Almanac gehören sie längst zum Standard-Repertoire moderner Websites (HTTP Archive Web Almanac). Der praktische Gewinn für Shopware: Visuelle Einstellungen lassen sich flexibler und unabhängiger von der SCSS-Kompilierung verwenden, etwa für Laufzeit-Themes, Dark-Mode-Varianten oder kontextabhängige Akzentfarben, ohne dass ein voller Theme-Build nötig wird.

window.Shopware: das globale Event-System

Das vierte große Feature ist ein globales JavaScript-Event-System über das zentrale window.Shopware-Objekt. Bisher war die Plugin-Kommunikation stark an die jeweilige Plugin-Instanz gebunden. Das neue System nutzt ein natives Event-Emitter-Muster mit zusätzlichen Fähigkeiten wie abfangbaren Events und erleichtert so die Kommunikation zwischen Storefront-Komponenten (Shopware Documentation).

// Auf ein globales Storefront-Event hoeren
window.Shopware.on('checkout.line-item-updated', (payload) => {
  console.log('Warenkorb aktualisiert', payload);
});

// Eigenes Event auslösen
window.Shopware.emit('mini-cart.opened', { itemCount: 3 });

Ergänzend erlaubt eine neue Methode window.PluginManager.callPluginMethod(pluginName, methodName, ...args), eine bestimmte Methode auf allen Instanzen eines Plugins aufzurufen (Shopware Documentation). Das ist nützlich, wenn etwa ein globaler Zustandswechsel mehrere Plugin-Instanzen auf einer Seite betrifft. Für komplexere, interaktive Storefronts entsteht damit eine sauberere Architektur als bisher, ohne dass dafür auf eine reine Headless-Architektur mit der Store API gewechselt werden müsste.

Komponenten, CSS-Variablen und ein globales Event-System ergeben zusammen ein Frontend, das sich anfühlt wie ein modernes Framework, aber serverseitig gerendert bleibt und damit SEO- und Performance-Vorteile behält.

XICTRON Entwicklungsteam

Einordnung in die Vite-Migration von Shopware

Die Storefront-Neuerungen sind Teil einer größeren Bewegung: Shopware löst seinen Build-Stack schrittweise von Webpack ab und setzt auf Vite. In der Administration ist dieser Wechsel bereits weit fortgeschritten. Vite baut die Core-Administration in rund 18 Sekunden, was eine Ersparnis von über 50 % (Shopware Documentation) bedeutet und lässt sich über das Feature-Flag ADMIN_VITE aktivieren.

Wichtig: Für die Storefront ist kein abrupter Big-Bang-Wechsel vorgesehen. Je mehr UI auf das Komponentensystem umgestellt wird, desto größer wird der von Vite kompilierte JS-Anteil. Der Übergang erfolgt also organisch, während Komponenten nach und nach klassische Templates ersetzen (Shopware Documentation). Plugin-Entwickler in der Administration migrieren ihre webpack.config.js perspektivisch zu einer vite.config.mts; Hot Module Replacement greift dort zunächst für Vue-Dateien, bis die Single-File-Component-Migration abgeschlossen ist (Shopware Documentation).

Damit der Übergang reibungslos verläuft, hat Shopware spezialisierte Vite-Plugins entwickelt. Ein override-component-Plugin registriert automatisch *.override.vue-Dateien, und ein vue-globals-Plugin verhindert mehrfache Vue-Instanzen, indem es aus Shopware.Vue destrukturiert (Shopware Documentation). Diese Details betreffen primär die Administration, zeigen aber das Muster: Shopware kapselt die Komplexität der Migration in Werkzeuge, statt sie auf jede einzelne Erweiterung abzuwälzen.

Neben den vier großen Frontend-Themen bringt 6.7.11 auch kleinere, aber nützliche Verbesserungen. So lösen Einzel-Treffer-Weiterleitungen in der Suche jetzt bei exakten Treffern auf den Feldern ean und manufacturerNumber aus, konfigurierbar über shopware.storefront.redirect_on_single_hit_fields (Shopware Documentation). Solche Detailverbesserungen summieren sich in der Praxis zu einer spürbar besseren Nutzerführung, etwa wenn Kunden gezielt nach Artikelnummern suchen.

Für Entwicklungsteams summieren sich die Neuerungen zu einem spürbar besseren Arbeitsalltag. Ein schneller Inner-Loop heißt: Eine Änderung am Code, ein Blick in den Browser, weiter. Das erhält den Fokus und verkürzt die Zeit zwischen Idee und sichtbarem Ergebnis. Komponenten mit stabilen Schnittstellen erleichtern zudem die Zusammenarbeit, weil mehrere Personen parallel an unterschiedlichen Bausteinen arbeiten können, ohne sich gegenseitig in zentrale Templates zu grätschen. Und CSS-Custom-Properties machen Design-Anpassungen nachvollziehbar, weil Werte an einer Stelle definiert und überall referenziert werden.

• Schnellerer Feedback-Zyklus durch den Vite-Devserver ohne Proxy
• Weniger Merge-Konflikte dank gekapselter Komponenten statt globaler Overrides
• Konsistente Gestaltung über zentral definierte Design-Tokens
• Sauberere Kommunikation zwischen Komponenten über das globale Event-System
• Zukunftssichere Basis für das angekündigte Content-System

Wie XICTRON Ihre Storefront modernisiert

Die Neuerungen sind kein Selbstzweck, sondern senken langfristig Wartungskosten und beschleunigen die Weiterentwicklung. Als Shopware-Agentur begleiten wir den Umstieg in klar abgegrenzten Schritten, damit Ihr Shop durchgehend stabil bleibt.

1. Bestandsaufnahme: Wir analysieren Theme, Block-Overrides, Custom-JS und vorhandene Webpack-Anpassungen und identifizieren Modernisierungskandidaten.
2. Devserver-Umstellung: Wir richten storefront:dev-server ein und passen lokale sowie CI-Workflows an, um den Inner-Loop zu beschleunigen.
3. Komponentenextraktion: Wiederkehrende UI-Muster werden behutsam in Twig-UX-Komponenten überführt, ohne bestehende Templates auf einen Schlag zu ersetzen.
4. Token-Migration: Häufig geänderte Design-Tokens werden auf CSS-Custom-Properties umgestellt, SCSS bleibt parallel nutzbar.
5. Event-Architektur: Plugin-Kommunikation wird wo sinnvoll auf das globale window.Shopware-Event-System umgestellt.
6. Qualitätssicherung: Visuelle Regressionstests und ein sauberer Wartungs- und Update-Prozess sichern den Stand ab.

Wenn Sie Performance ganzheitlich denken wollen, ergänzen wir die Frontend-Modernisierung um serverseitige Maßnahmen wie Caching-Strategien und Edge-Delivery sowie einen Blick auf die Core-Web-Vitals und Lighthouse-Scores. So entsteht ein Frontend, das nicht nur in der Entwicklung schneller ist, sondern auch für Ihre Kundinnen und Kunden.