Shopware 6.7.13: Neuerungen im August

Ein Feature-Release im monatlichen Takt

Shopware hat am 5. August 2026 die Version 6.7.13 veröffentlicht. Das ist ein reguläres Feature- und Bugfix-Update, wie es der 6.7-Zweig etwa im Monatsrhythmus bekommt. Der Sprung von 6.7.12 auf 6.7.13 ist deshalb kein großer Umbau, sondern ein Zwischenschritt mit vielen kleinen Verbesserungen. Der eigentliche Generationswechsel steht erst mit 6.8 an, und der ist als Main-Update eine andere Hausnummer.

Zum Nachlesen: die Release News von Shopware für die Händler-Sicht und das vollständige Original-Changelog auf GitHub für alle Code-Änderungen.

Was im Shop sichtbar wird

Gastkonten lassen sich in Kundenkonten umwandeln. Wer als Gast bestellt hat, kann sich nachträglich ein Konto anlegen, ohne die Bestellung zu verlieren; ebenso kann der Betreiber die Umwandlung in der Administration anstoßen. Die komplette Bestellhistorie bleibt dabei erhalten. Das schließt eine Lücke, die vorher oft in einem Support-Ticket endete.

Varianten in dynamischen Produktgruppen können einzeln erscheinen. Dynamische Produktgruppen sind automatisch befüllte Sortimente nach Regeln, etwa "alle roten Artikel unter 50 Euro". Bisher fasste Shopware passende Varianten immer unter dem Hauptprodukt zusammen. Jetzt lässt sich das abschalten, sodass jede Variante als eigene Kachel auftaucht. Ob das sinnvoll ist, hängt vom Sortiment ab, aber die Wahl gab es vorher nicht.

Die Kategoriepflege wird spürbar schneller. Beim Bearbeiten einer Kategorie aktualisiert Shopware nur noch die betroffene Kategorie samt ihren Unterkategorien statt des gesamten Baums. Bei großen Katalogen spart das Hintergrundlast und macht das Speichern zäher Kategoriestrukturen deutlich flüssiger.

Beim SEO gibt es Feinschliff an mehreren Stellen. Paginierte Kategorieseiten bekommen jetzt eindeutige kanonische URLs, also den korrekten Verweis auf die maßgebliche Seite, statt alle Unterseiten auf dieselbe Adresse zu zeigen. Verlinkte Kategorien erhalten wieder eigene SEO-URLs und leiten sauber auf ihr Ziel weiter, und die robots.txt erlaubt das Crawlen der Tracking-URLs des Produktfeeds, was für das Google Merchant Center relevant ist.

Dazu kommen viele kleinere Händler-Verbesserungen: der Rule Builder, mit dem sich Regeln für Preise, Versand oder Sichtbarkeiten zusammenklicken lassen, bekommt einen konfigurierbaren "alle / mindestens eine"-Umschalter und beim Einkaufspreis eine saubere Netto/Brutto-Unterscheidung. Beim erneuten Bezahlen einer Bestellung wird die Einstellung "Zahlart nach dem Checkout ändern" jetzt korrekt durchgesetzt, und ZUGFeRD-Korrekturbelege, das sind maschinenlesbare elektronische Rechnungen, übernehmen die Versandkosten-Behandlung aus den Belegdaten.

B2B: Angebote und Mitarbeiterkonten

Für die B2B Components bringt das Release zwei größere Bausteine. Das Quote Management, also die Angebotsverwaltung, wird ausgebaut: Kommentare lassen sich jetzt auf Produktebene setzen, die Angebots- und Nachrichtenhistorie wird vollständig geführt, Änderungen sind über Versionen nachvollziehbar, und Rabatte können pro Produkt vergeben werden. Damit wird die individuelle Preisverhandlung, das Kerngeschäft vieler B2B-Shops, deutlich handhabbarer.

Neu sind außerdem Multi-Kontext-Mitarbeiterkonten: Ein Mitarbeiter kann auf mehrere Organisationseinheiten zugreifen, ohne sich neu anzumelden, und Unter-Organisationseinheiten erlauben feiner abgestufte Hierarchien. Für Kunden mit verschachtelten Einkaufsstrukturen ist das ein spürbarer Komfortgewinn.

Für Entwickler

Die technisch wichtigste Änderung steht ganz oben im Changelog: Die Store API startet keine PHP-Sessions mehr. Die Store API ist der Schnittstellen-Zugang, über den die Storefront und Headless-Frontends mit dem Shop sprechen. Dass jede Anfrage bisher eine Session anlegte, war schlecht für das Caching und die Skalierung. Zustandslose Anfragen sind die Voraussetzung für wirklich schnelle, gut cachebare Frontends, gerade im Headless-Betrieb.

Bei den Custom Fields, also den frei definierbaren Zusatzfeldern an Produkten, Kunden oder Bestellungen, gibt es zwei Neuerungen. Erstens lassen sie sich jetzt deklarativ über eine custom-fields.xml anlegen, statt sie im Code zusammenzubauen. Eine solche Datei sieht zum Beispiel so aus:

<?xml version="1.0" encoding="utf-8"?>
<custom-fields xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/shopware/shopware/trunk/src/Core/System/CustomField/Schema/custom-fields-1.0.xsd">
    <custom-field-set>
        <name>my_plugin_fields</name>
        <label>My Fields</label>
        <label lang="de-DE">Meine Felder</label>
        <related-entities>
            <product/>
        </related-entities>
        <fields>
            <int name="my_plugin_weight">
                <label>Weight</label>
                <position>1</position>
            </int>
        </fields>
    </custom-field-set>
</custom-fields>

Zweitens lässt sich ein einzelnes Feld mit <include-in-search>true</include-in-search> als durchsuchbar markieren, ebenfalls ohne eigenen Code:

<custom-fields>
    <custom-field-set>
        <name>swag_example_set</name>
        <label>Example</label>
        <related-entities>
            <product/>
        </related-entities>
        <fields>
            <text name="swag_example_field">
                <label>Example field</label>
                <include-in-search>true</include-in-search>
            </text>
        </fields>
    </custom-field-set>
</custom-fields>

Beides macht Erweiterungen wartbarer.

Die Suche profitiert von einem besseren Phrase Matching in Elasticsearch, dem optionalen Suchserver für große Kataloge; zusammenhängende Wortgruppen werden präziser getroffen. Über die Admin API lassen sich nun Übersetzungen verwalten und Mediendateien herunterladen. Die Ausführung geplanter Aufgaben wandert in einen eigenen ScheduledTaskExecutor, ein Sales Channel kann eine eigene Geschäfts-Zeitzone bekommen, und für Produktions-Builds steuert die neue Umgebungsvariable GENERATE_SOURCEMAPS, ob Source Maps erzeugt werden.

Wie in jedem Minor-Release markiert Shopware auch diesmal ältere Schnittstellen als veraltet, darunter EntitySearchResult und das Einbetten von <custom-fields> direkt im manifest.xml. Veraltet heißt: funktioniert noch, sollte aber nicht mehr für Neues verwendet werden. Wer eigene Plugins pflegt, findet die vollständige Liste im Original-Changelog oben und sollte einen Blick hineinwerfen, bevor der Zweig irgendwann auf 6.8 wechselt.

Warum der monatliche Rhythmus zählt

Ein Minor-Update innerhalb desselben Zweigs, hier von 6.7.12 auf 6.7.13, ändert keine Datenbankstruktur im großen Stil und keine Template-Grundlagen. Das Risiko für bestehende Plugins und Themes ist entsprechend überschaubar. Trotzdem gilt das übliche Vorgehen: vorher ein vollständiges Backup von Datenbank und Dateien, danach Caches leeren und die wichtigsten Abläufe einmal durchklicken. Wer eigene Erweiterungen einsetzt, prüft sie kurz gegen die Deprecations.

Der eigentliche Wert dieser monatlichen Releases zeigt sich erst in der Summe. Einzeln wirkt jede Neuerung klein, aber wer ein halbes Jahr auslässt, steht am Ende vor einem größeren Sprung mit mehr Überraschungen. Genau darum gehört das Einspielen und Bewerten neuer Versionen in einen festen Rhythmus. Auf der Shopware-Seite gibt es dafür Wartungspakete mit regelmäßigem Update-Check, und wer noch auf einer älteren Shopware-Version steht und den Sprung auf einen aktuellen Zweig nicht allein gehen will, findet über die Wartung Unterstützung.