Shopware-Plugins
Zwei Anlässe führen auf diese Seite. Entweder fehlt Ihrem Shopware-6-Shop eine Funktion, die der Standard nicht mitbringt — oder eine vorhandene Erweiterung blockiert das Update. Beides ist Entwicklungsarbeit, kein Betriebsthema. Die Sharpness Solutions GmbH aus Oldenburg entwickelt Shopware-Plugins und Apps, passt Store-Erweiterungen an, portiert eigenen Code von 6.6 auf 6.7 und übernimmt fremde Erweiterungen, wenn der Hersteller nicht mehr liefert. Aktuell ist Shopware 6.7, Shopware 6.8 wird für 2027 erwartet. Stand dieser Seite: 17. August 2026. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr.
Anfragen zu Shopware-Erweiterungen kommen selten mit einer Spezifikation. Sie kommen mit einem Satz wie „das muss doch irgendwie gehen" oder mit der Fehlermeldung aus einem abgebrochenen Update-Versuch. Die vier Fälle unten decken den größten Teil ab. Gemeinsam haben sie, dass die eigentliche Entscheidung vor der ersten Zeile Code fällt: kaufen, anpassen oder selbst bauen — und ob das Ergebnis ein Plugin oder eine App wird. Wer diese Entscheidung überspringt, bezahlt sie beim nächsten Major-Release nach.
Sie haben den Shopware Store durchsucht und drei Erweiterungen gefunden, die je ein Drittel Ihrer Anforderung abdecken. Alle drei zu installieren ist teurer als eine eigene Lösung und deutlich schwerer zu pflegen, weil dann drei Hersteller-Roadmaps in Ihrem Deployment hängen. Bevor wir etwas bauen, prüfen wir, ob eine der drei mit einer Anpassung reicht. Das ist der kleinere Auftrag und oft der richtige.
Entweder lässt der Composer-Constraint der Erweiterung shopware/core in Version 6.7 nicht zu, oder das Update läuft durch und die Administration bleibt weiß. Shopware 6.7 hat die Vue-2-Kompatibilitätsschicht entfernt und baut die Administration mit Vite statt Webpack. Erweiterungen, die darauf aufsetzen, brauchen ein eigenes 6.7-Release mit neu gebauten Assets — nicht bloß einen gelockerten Constraint in der composer.json.
Das Plugin läuft, aber die letzte Version stammt aus der 6.5-Zeit, im Store steht keine 6.7-Fassung, und auf Anfragen antwortet niemand. Damit sitzt die Funktion in Ihrem Shop, die Entscheidung darüber aber bei jemand anderem. Der Ausweg ist Ersatz, Fork oder Neuentwicklung. Welcher davon offensteht, entscheidet zuerst der Blick in die Lizenz und danach der Blick in den Code — nicht umgekehrt.
Irgendwann hat jemand eine Core-Datei geändert, ein Storefront-Template kopiert statt erweitert, eine Spalte per ALTER TABLE an eine Core-Tabelle gehängt oder eine als final markierte Klasse umgangen. Das funktioniert bis zum nächsten Major-Release und danach nicht mehr. Ein Plugin, das ein Update blockiert, ist ein Konstruktionsfehler, kein Schicksal. Reparieren lässt sich das, aber nicht nebenbei am Tag des Update-Termins.
Der erste Weg ist der Shopware Store, und er ist der richtige, wenn eine Erweiterung Ihre Anforderung im Wesentlichen trifft. Für Zahlarten, Versanddienstleister, Bewertungssysteme, Rechnungslayouts oder Marktplatz-Anbindungen gibt es gepflegte Standardlösungen, und eine Eigenentwicklung daneben wäre Verschwendung. Zwei Dinge gehören zur Kalkulation. Erstens: Seit dem 28. Dezember 2023 ist die Mietlizenz die einzige Möglichkeit, eine Erweiterungslizenz im Shopware Store zu erwerben. Endet die Mietzeit, endet das Nutzungsrecht an der Erweiterung — das ist eine laufende Position im Betriebsbudget, keine Einmalinvestition. Zweitens: Sie übernehmen die Roadmap des Herstellers. Ob es zum Release von Shopware 6.8 eine kompatible Fassung gibt, entscheidet er, nicht Sie. Wenn eine Store-Erweiterung Ihre Anforderung deckt, sagen wir das, obwohl wir daran nichts entwickeln.
Der zweite Weg ist die Anpassung einer vorhandenen Erweiterung, und er wird regelmäßig übersehen. Der Quellcode liegt dafür lesbar vor: PHP und Twig ohnehin, und die Qualitätsrichtlinien für den Shopware Store verlangen, dass die unkompilierte Fassung des JavaScript in einem eigenen Verzeichnis mitgeliefert wird. Anpassen heißt trotzdem nicht, im fremden Plugin zu editieren — dann ist beim nächsten Hersteller-Update alles wieder weg. Wir bauen ein zweites, kleines Plugin daneben: es dekoriert die Services der Fremd-Erweiterung, hängt sich an ihre Events, erweitert ihre Twig-Templates über sw_extends und überschreibt im Admin nur die Komponenten, die es ändern muss. Beide Erweiterungen bleiben getrennt aktualisierbar. Die Grenze dieses Weges ist scharf: Wenn die Fremd-Erweiterung keine Erweiterungspunkte anbietet, ihre Logik in finalen Klassen oder privaten Methoden versteckt und ihre Templates keine sinnvollen Blöcke setzt, endet der Weg. Das sehen wir vorher, nicht mitten im Projekt.
Der dritte Weg ist die Eigenentwicklung. Sie ist in der Anschaffung fast immer die teuerste und über die Laufzeit selten die falsche. Sie bekommen genau die Funktion, die Ihr Prozess braucht, keine Konfigurationsoberfläche für dreißig Fälle, die Sie nicht haben, und keine Fremdlogik im Request-Pfad des Checkouts. Kein Nutzungsrecht, das mit einer Kündigung endet. Dafür tragen Sie die Pflege selbst: Jeder Major-Sprung von Shopware kostet Anpassung, und diese Anpassung steht dann auf Ihrer Rechnung. Wir rechnen beide Wege gegeneinander, wenn Sie es verlangen, und die Zahl, die dabei zählt, ist nicht der Angebotspreis, sondern die Summe über die Jahre, die Sie das System betreiben wollen. Und manche Anforderung ist gar keine Plugin-Anforderung: Ein Plugin, das eine unklare Regel automatisiert, macht die Unklarheit schneller, nicht besser.
Ein Plugin ist PHP-Code, der im Shopware-Prozess selbst läuft. Technisch ist es ein Composer-Paket mit einer Plugin-Basisklasse und einem Lebenszyklus aus install, activate, update, deactivate und uninstall. Es hat Zugriff auf alles, was Shopware und Symfony hergeben: Event-Subscriber, Service-Dekoration über den Container, eigene EntityDefinition und Erweiterungen bestehender Entitäten, eigene Storefront- und Admin-Routen, Twig-Overrides, eigene Admin-Komponenten, Scheduled Tasks und Message-Handler. Der Preis dafür ist Bindung: Ein Plugin lässt sich nur in einer selbst gehosteten Installation betreiben, in Shopware Cloud nicht. Und es liegt im Request-Pfad. Was es dort an Zeit verbraucht, verbraucht der Shop bei jedem Aufruf mit.
Eine App bringt im Shop keinen ausführbaren Code mit, sondern eine manifest.xml. Die Logik läuft auf einem eigenen App-Server, der über Admin API, Store API und Webhooks mit dem Shop spricht — in einer Sprache Ihrer Wahl. Apps laufen in Shopware Cloud und in selbst gehosteten Installationen. Für Logik, die im Shop-Prozess passieren muss, gibt es App Scripts: Twig-Dateien, die seit Shopware 6.4.8.0 in einer Sandbox an definierten Hooks ausgeführt werden und dort nur die Services sehen, die der jeweilige Hook bereitstellt. Die Administration erweitert eine App über das Meteor Admin SDK; die Oberfläche kommt aus einem iframe und kommuniziert per postMessage. Eigene Datenstrukturen gehen über eine Resources/entities.xml; die Entitätsnamen tragen üblicherweise das Kürzel ce_, seit Shopware 6.4.15.0 möglich und empfohlen, weil die vollen Namen an den Längengrenzen der Datenbank scheitern. Danach tauchen sie als reguläre Entität in Admin API und Administration auf.
Die Entscheidung ist unspektakulär. App, wenn Shopware Cloud im Spiel ist, wenn die Logik ohnehin außerhalb lebt — eine Preisberechnung im ERP, ein Verfügbarkeitsdienst, eine Mittelschicht zu einem Drittsystem —, oder wenn Sie die Erweiterung an mehrere Shops ausliefern wollen. Plugin, wenn tief in Datenmodell, Storefront oder Checkout eingegriffen wird, wenn Latenz zählt oder wenn die Funktion ohne Netzverbindung nach draußen laufen muss. Beide Nachteile gehören ausgesprochen: Der App-Server ist ein zweites System, das Sie betreiben, überwachen und aktuell halten müssen — steht er, steht die Funktion. Das Plugin dagegen lebt im Deployment des Shops und braucht bei jedem Major-Release Ihre Aufmerksamkeit. Es gibt hier keine Variante ohne Folgekosten, nur zwei verschiedene.
Shopware sagt Erweiterungsentwicklern eine Rückwärtskompatibilität zu, und diese Zusage ist erfreulich konkret. Als öffentliche API gelten unter anderem öffentliche und protected Methoden, Eigenschaften und Konstanten, Interfaces und abstrakte Klassen, die Konstruktoren von DTOs wie CalculatedPrice oder QuantityPriceDefinition, Twig-Templates und -Blöcke der Storefront, die JavaScript-Plugins und -Services, die Props, Slots und Events der Admin-Komponenten sowie CSS-Selektoren mit struktureller Bedeutung. Breaking Changes sind nur in Major-Releases erlaubt; vorher wird der betroffene Code mit einer Annotation wie @deprecated tag:v6.8.0 markiert, die das Zielrelease und den Ersatz nennt. Wer diese Annotationen liest, weiß Monate vor dem Major, was zu tun ist. Zwei Ausnahmen muss man kennen. Erstens: Der Konstruktor eines Services, den der Container instanziiert, ist ausdrücklich keine öffentliche API und darf sich jederzeit ändern — wer einen solchen Service selbst per new erzeugt statt ihn zu dekorieren, baut sich die Blockade ein. Zweitens: Nicht zugesichert sind private Methoden, Eigenschaften und Konstanten sowie alles, was mit @internal oder @experimental markiert ist. Eine als final markierte Klasse gehört dagegen zur öffentlichen API — sie darf benutzt, nur nicht beerbt werden. An diesen Rändern sitzen die Plugins, die später Updates blockieren.
Praktisch heißt das eine kurze Liste. Keine Core-Datei anfassen — die Qualitätsrichtlinien für Store-Erweiterungen verbieten Änderungen an Core-Dateien und Core-Datenbanktabellen ohnehin. Event-Subscriber statt kopierter Logik. Service-Dekoration statt Klassenersatz. Entity-Extension statt ALTER TABLE. Twig-Erweiterung mit sw_extends und gezielten Block-Overrides statt eines kopierten Templates, das beim nächsten Storefront-Umbau still auseinanderfällt. Im Admin die vorgesehene Override-API statt Datei-Ersatz. Dazu die Dinge, die im Betrieb später auffallen: eine Deinstallation, die ihre Daten wieder mitnimmt, Snippets mit Fallback-Sprache, ordentliches Logging statt Ausgaben ins Nichts und Migrationen, die ein zweites Mal ohne Schaden durchlaufen.
Prüfen ist billiger als hoffen, und die Werkzeuge dafür liefert Shopware selbst mit. shopware-cli extension validate prüft in der Grundstufe Metadaten, Packaging, Verzeichnisstruktur, Snippets und PHP-Syntax; mit --full kommen PHPStan, ESLint, Stylelint sowie separate Prüfungen für Admin- und Storefront-Twig dazu, einzeln zuschaltbar über --only und --exclude. Mit --check-against lowest beziehungsweise highest läuft die Prüfung gegen die Ränder Ihres Versions-Constraints, und genau dort brechen Plugins. extension format und extension fix räumen auf, was maschinell aufräumbar ist; darunter arbeiten PHP CS Fixer, Prettier, Rector für PHP und ESLint für JavaScript. Der frühere Extension Verifier, ein eigenes Docker-Image mit den Kommandos check, format und fix, ist im Mai 2025 in shopware-cli aufgegangen — sein Repository ist archiviert, seine Prüfungen stecken in den Kommandos oben. Es sind also nicht zwei Werkzeuge, sondern eines. Bei uns läuft es in der CI, nicht auf dem Laptop eines Einzelnen. Nur: Ein Linter findet keinen Denkfehler. Ein Plugin, das jede Regel einhält und das falsche Problem löst, ist trotzdem falsch.
Shopware 6.7 ist der größte technische Umbau seit dem Start von Shopware 6, und er trifft die Administration am härtesten. Vue 3 statt Vue 2 — die Kompatibilitätsschicht ist entfernt, nicht deprecated. Vite statt Webpack, damit wandert eine webpack.config.js in eine vite.config.js und die ausgelieferten Build-Artefakte sehen anders aus. Pinia statt Vuex: Die Core-Stores liegen unter Shopware.Store statt Shopware.State, und die alten Vuex-Helfer existieren nur umbenannt weiter — mapState heißt mapVuexState, mapMutations mapVuexMutations, mapGetters mapVuexGetters, mapActions mapVuexActions. Eigene Vuex-Stores lassen sich weiter anlegen; empfohlen ist es nicht. Dazu der Wechsel auf die Meteor Component Library, in dem aus sw-button ein mt-button wird und sich die v-model-Bindungen ändern. Für Sie heißt das: Ein 6.7-Release einer Erweiterung ist ein eigenes Paket mit eigenem Build, keine angepasste Versionsangabe.
Im PHP-Teil und in der Storefront sitzen die übrigen Kanten. Die Core-Klassen haben durchgehend native Typen an ihren Eigenschaften bekommen; jede Klasse, die davon erbt, muss die Typen nachziehen. Die Zahlungsabwicklung läuft über eine einheitliche AbstractPaymentHandler-Klasse, die fünf Interfaces ersetzt: AsyncPaymentHandlerInterface, SyncPaymentHandlerInterface, PreparedPaymentHandlerInterface, RefundPaymentHandlerInterface und RecurringPaymentHandlerInterface; ein Handler bekommt nur noch orderTransactionId, die Request-Daten, soweit sie anfallen, und den Context. Zahlungs- und Versandarten brauchen einen technicalName, verpflichtend in API und Datenbank — die Spalte technical_name wird in payment_method und shipping_method non-nullable. Custom-Field- und Fieldset-Namen dürfen keine Bindestriche und keine Punkte mehr enthalten, sie müssen gültige Twig-Variablennamen sein. Header und Footer laden per ESI über eigene Routen /header und /footer. Das Store-API-Route-Caching ist entfallen, mit ihm die Cached*Route-Klassen. Und für Plugins ist der Weg über eine Resources/config/entities.xml weg — Custom Entities per XML sind für Plugins entfernt; dort gehören jetzt eine eigene EntityDefinition oder attributbasierte Entitäten hin.
Wer eine Erweiterung für 6.6 und 6.7 gleichzeitig pflegt, pflegt zwei Linien: zwei Branches, zwei CI-Läufe, zwei Testmatrizen und im Store zwei Versionsstände unter einem Eintrag. Der Aufwand dafür entspricht eher einem Major-Sprung als einem Punkt-Release, und das ist kein Argument gegen 6.7, sondern eine Planungsgröße. Für den Bestand ist es seit Anfang 2026 deutlich entspannter: Die großen Store-Plugins haben kompatible Fassungen, anders als in den ersten Monaten nach dem Release. Wer nur einen eigenen Shop betreibt, braucht die zweite Linie ohnehin nicht — dann portieren wir einmal nach 6.7 und schließen 6.6 ab. Das Update-Projekt selbst, also Reihenfolge, Staging-Durchlauf und Rollback-Plan, steht auf einer eigenen Seite; hier geht es um den Code, der dabei mitziehen muss.
Wenn ein Hersteller nicht mehr liefert, gibt es drei Wege, und der erste Blick geht nicht in den Code, sondern in die Lizenz. Bei einer Mietlizenz aus dem Shopware Store endet das Nutzungsrecht mit der Mietzeit; ob Sie den Code danach forken, weiterentwickeln oder überhaupt weiterbetreiben dürfen, ist zuerst eine rechtliche und erst danach eine technische Frage. Das klärt Ihre Rechtsberatung, nicht Ihre Agentur. Steht die Erweiterung quelloffen auf Packagist oder GitHub, ist der Fork der kürzeste Weg: eigenes Repository, eigener Constraint, eigene Release-Verantwortung. Der zweite Weg ist Ersatz durch eine gepflegte Alternative, auch wenn dabei Konfiguration und Daten umgezogen werden müssen. Der dritte ist die Neuentwicklung — und die hat einen unterschätzten Vorteil: Die Spezifikation liegt vor, sie läuft seit Jahren in Ihrem Shop.
Vor einer Zusage zur Übernahme sehen wir uns denselben Satz Fragen an, jedes Mal. Was steht in der composer.json, insbesondere im Constraint gegen shopware/core und in den Abhängigkeiten? Gibt es eine reguläre Plugin-Basisklasse und einen sauberen Lebenszyklus, oder passiert die Installation in einer Migration? Was lässt die Deinstallation zurück? Wie viele Services werden dekoriert, und greift eine dieser Dekorationen auf Interna zu, die mit @internal markiert sind oder als privat gelten? Sind Storefront-Templates über sw_extends erweitert oder kopiert? Verwenden die überschriebenen Admin-Komponenten noch Vue-2-Muster oder Shopware.State? Existieren Tests, und laufen sie? Dazu ein Lauf von shopware-cli extension validate --full gegen die Ränder des Constraints und, wo es sich anbietet, extension format und extension fix. Das ist eine Arbeit von Stunden bis Tagen, nicht von Minuten, und sie ist ein abgegrenztes Erstprodukt mit eigenem Preis.
Am Ende steht ein Befundbericht: Portierungsaufwand nach Gewerken, Risikoliste mit Priorität und daneben die Alternative Neuentwicklung mit ihrer eigenen Zahl. Beide Zahlen stehen nebeneinander, auch wenn die Portierung der kleinere Auftrag ist. Und wir sagen ab, wenn ein Plugin so gebaut ist, dass wir für sein Verhalten nach dem nächsten Update nicht geradestehen können. Eine Erweiterung, die an fünf Stellen in undokumentierte Interna greift, ist kein Portierungsfall, sondern eine Neuentwicklung mit vorhandener Spezifikation — und dann ist es ehrlicher, das so zu nennen, als eine Portierung anzubieten, die beim nächsten Major-Release ein zweites Mal bezahlt werden muss. Eine Zusage ohne Blick in den Code wäre geraten, und Raten ist bei fremdem Code keine Methode.
Ablauf
Wenn eine Funktion fehlt, beschreiben Sie den Ablauf, den sie ersetzen soll. Wenn ein Plugin das Update blockiert, genügt die Ausgabe von composer show oder die Liste aus der Erweiterungsverwaltung. Sie bekommen eine schriftliche Einschätzung mit Weg, Aufwandsrahmen und der Alternative daneben — auch dann, wenn wir Ihnen eine Store-Erweiterung empfehlen und nichts entwickeln. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, info@sharpness.de.
Zuerst klären wir, was genau passieren soll und an welcher Stelle im Prozess — nicht, welche Technik zum Einsatz kommt. Wer löst heute das Problem manuell, und wie? Was ist die Regel, die automatisiert werden soll, und gilt sie ohne Ausnahme? Aus unklaren Regeln entstehen teure Plugins.
Wir sichten den Shopware Store und Packagist nach vorhandenen Lösungen und prüfen bei Kandidaten, ob sie Erweiterungspunkte anbieten oder ihre Logik verschließen. Parallel prüfen wir, welche Hooks, Events und Services Shopware für Ihre Anforderung überhaupt bereitstellt. Ergebnis ist eine kurze Liste realistischer Wege.
Kaufen, anpassen oder bauen — und Plugin oder App. Dazu der Schnitt: Was gehört in die Erweiterung, was in die Konfiguration, was bleibt Handarbeit im Tagesgeschäft. Sie bekommen eine Aufwandsschätzung nach Gewerken, einen Festpreis für klar abgegrenzte Teile und die benannte Liste dessen, was erst am Testsystem entschieden werden kann.
Gearbeitet wird in einem Git-Repository, das Ihnen gehört, gegen eine Staging-Installation, nicht im Livebetrieb. Event-Subscriber, Service-Dekoration, Entity-Extension und sw_extends statt Core-Eingriffen. In der CI läuft shopware-cli extension validate --full mit, bei jedem Commit, geprüft gegen beide Ränder des Constraints.
Vor der Abnahme läuft ein Update-Test: Installation, Aktivierung, Deinstallation und ein Patch-Sprung des Shops mit aktiver Erweiterung. Sie testen gegen eine Abnahmeliste. Das Deployment geht über den vereinbarten Weg mit Backup und dokumentiertem Rückweg, nicht über die Plugin-Verwaltung im Browser.
Danach die Frage, wer die Erweiterung bei kommenden Releases nachzieht. Wir beobachten die @deprecated-Markierungen mit Zielrelease und melden früh, was zu Shopware 6.8 fällig wird. Wer die Pflege abgibt, tut das über die Service-Level-Staffel: BASIC 24, STANDARD 8, ADVANCED 4, PREMIUM 2 Stunden Reaktionszeit, Monatspauschale netto je Shop.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Ein Shopware-Plugin wird nach Aufwand kalkuliert, und den Aufwand bestimmen vier Größen: an wie vielen Stellen im Shopware-Ablauf die Erweiterung eingreift, ob eigene Datenstrukturen dazukommen, ob die Administration erweitert wird und ob eine Schnittstelle nach außen dazugehört. Eine Erweiterung, die ein Event abfängt und ein Feld befüllt, ist ein anderer Posten als eine, die Checkout und Preisfindung berührt. Eine belastbare Zahl steht nach der Anforderungsklärung, nicht im ersten Telefonat. Für klar abgegrenzte Teile arbeiten wir zum Festpreis.
Wenn eine Store-Erweiterung Ihre Anforderung im Wesentlichen trifft, ist der Kauf günstiger — auch wenn wir dabei nichts entwickeln. Zwei Punkte gehören in den Vergleich. Seit dem 28. Dezember 2023 ist die Mietlizenz die einzige Möglichkeit, eine Erweiterungslizenz im Shopware Store zu erwerben; endet die Mietzeit, endet das Nutzungsrecht. Und die Kompatibilität zu kommenden Major-Versionen entscheidet der Hersteller. Eine Eigenentwicklung kostet in der Anschaffung mehr und verlagert die Pflege zu Ihnen. Verglichen wird deshalb über die Laufzeit, nicht über den Angebotspreis.
Ein Plugin ist PHP-Code, der im Shopware-Prozess selbst läuft: ein Composer-Paket mit Plugin-Basisklasse und Lebenszyklus, mit Zugriff auf Events, Services, Datenmodell, Templates und Administration. Es setzt eine selbst gehostete Installation voraus. Eine App bringt im Shop nur eine manifest.xml mit; ihre Logik läuft auf einem eigenen Server und spricht über Admin API, Store API und Webhooks mit dem Shop. Apps laufen auch in Shopware Cloud. Für Logik im Shop-Prozess kennen Apps App Scripts: Twig in einer Sandbox, an definierten Hooks, seit Shopware 6.4.8.0.
Nein. Klassische Plugins setzen eine selbst gehostete Installation voraus, weil sie PHP-Code im Shopware-Prozess ausführen. In Shopware Cloud geht ausschließlich das App-System: manifest.xml, ein eigener App-Server, Admin API und Store API, Webhooks, App Scripts und Admin-Oberflächen über das Meteor Admin SDK. Das ist kein Rückschritt, aber ein anderer Schnitt: Was tief im Datenmodell oder im Checkout passieren muss, braucht entweder einen Hook mit App Script oder es geht nicht. Welche Variante Sie betreiben, klären wir vor der Aufwandsschätzung.
Meist aus einem von zwei Gründen. Entweder lässt der Constraint der Erweiterung gegen shopware/core die 6.7er-Linie nicht zu — dann bricht Composer das Update ab, was der freundliche Fall ist. Oder das Update läuft durch und die Administration bleibt weiß, weil die Erweiterung auf Vue-2-Muster, auf Shopware.State oder auf einen Webpack-Build setzt. Shopware 6.7 hat die Vue-2-Kompatibilitätsschicht entfernt und baut mit Vite; die Core-Stores liegen in Pinia unter Shopware.Store, und die alten Vuex-Helfer heißen jetzt mapVuexState, mapVuexMutations, mapVuexGetters und mapVuexActions. Ein gelockerter Constraint hilft dann nicht: Es braucht ein eigenes 6.7-Release mit neu gebauten Assets.
Ja, wenn die Erweiterung in beiden Linien laufen soll. Die Administration wird in 6.7 mit Vite gebaut, in 6.6 mit Webpack; die ausgelieferten Build-Artefakte sind nicht dieselben. Damit brauchen Sie zwei Branches, zwei Builds, zwei Testmatrizen und im Store zwei Versionsstände unter einem Eintrag. Der Aufwand entspricht eher einem Major-Sprung als einem Punkt-Release. Wenn Sie die Erweiterung nur in Ihrem eigenen Shop betreiben, ist die zweite Linie unnötig: Dann portieren wir einmal nach 6.7 und schließen 6.6 ab.
In der Administration: Vue-3-Syntax, die Core-Stores über Shopware.Store statt Shopware.State — die alten Vuex-Helfer heißen jetzt mapVuexState, mapVuexMutations, mapVuexGetters und mapVuexActions —, eine vite.config.js statt webpack.config.js und der Wechsel auf die Meteor Component Library, in dem aus sw-button ein mt-button wird. Im PHP-Teil: native Typen an geerbten Eigenschaften, Zahlungsabwicklung über AbstractPaymentHandler statt der fünf alten Handler-Interfaces, ein technicalName an Zahlungs- und Versandarten, Custom-Field-Namen ohne Bindestrich und Punkt, Ersatz der entfallenen Cached*Route-Klassen, und für Custom Entities eine eigene EntityDefinition statt der entfernten entities.xml. In der Storefront: Header und Footer laden per ESI über eigene Routen.
Ja, aber nicht durch Editieren im fremden Plugin — das wäre beim nächsten Hersteller-Update verloren. Wir bauen eine eigene, kleine Erweiterung daneben, die die Services der Store-Erweiterung dekoriert, sich an ihre Events hängt und ihre Templates über sw_extends erweitert. Beide bleiben getrennt aktualisierbar. Die Grenze prüfen wir vorher: Wenn die Store-Erweiterung keine Erweiterungspunkte anbietet, ihre Logik in finalen Klassen hält und keine sinnvollen Twig-Blöcke setzt, sagen wir das, bevor Sie beauftragen.
Es gibt drei Wege: Ersatz durch eine gepflegte Alternative, Übernahme des Codes als Fork, oder Neuentwicklung der Funktion. Der erste Blick geht in die Lizenz, nicht in den Code: Bei einer Mietlizenz endet das Nutzungsrecht mit der Mietzeit, und ob ein Fork zulässig ist, klärt Ihre Rechtsberatung. Steht die Erweiterung quelloffen bereit, ist der Fork der kürzeste Weg — eigenes Repository, eigener Constraint, eigene Release-Verantwortung. Die Neuentwicklung hat einen Vorteil, der oft übersehen wird: Die Spezifikation läuft seit Jahren in Ihrem Shop.
Ja, aber erst nach einem Blick in den Code. Wir sehen uns composer.json und Constraint an, den Lebenszyklus, die Migrationen und das, was die Deinstallation zurücklässt, die Service-Dekorationen samt Zugriffen auf Interna, ob Templates über sw_extends erweitert oder kopiert sind, ob überschriebene Admin-Komponenten noch Vue-2-Muster nutzen, und ob Tests existieren und laufen. Dazu ein Lauf von shopware-cli extension validate --full gegen beide Ränder des Constraints. Ergebnis ist ein Befundbericht mit Portierungsaufwand und der Alternative Neuentwicklung daneben. Manchmal sagen wir ab — das ist ehrlicher als eine Portierung, die zweimal bezahlt wird.
Indem wir uns auf das beschränken, was Shopware als öffentliche API zusagt: öffentliche und protected Methoden und Eigenschaften, Interfaces und abstrakte Klassen, die Konstruktoren von DTOs, Twig-Blöcke der Storefront, JavaScript-Plugins, Props und Events der Admin-Komponenten. Nicht zugesichert sind private Methoden und alles, was mit @internal oder @experimental markiert ist — dort entstehen die Blockaden. Der Konstruktor eines Container-Services gehört ebenfalls nicht dazu: Er darf sich jederzeit ändern, weshalb ein Service dekoriert und nicht selbst instanziiert wird. Eine finale Klasse ist dagegen öffentliche API, nur nicht zum Beerben gedacht. Dazu die Werkzeuge: in der CI shopware-cli extension validate --full, geprüft gegen die Ränder des Constraints, dazu extension format und extension fix, in denen die Prüfungen des früheren Extension Verifier stecken. Und wir lesen die @deprecated-Markierungen, die das Zielrelease nennen.
Nur wenn Sie sie verkaufen oder mehreren Shops bereitstellen wollen. Für eine Erweiterung, die genau einen Shop bedient, ist der Store zusätzlicher Aufwand ohne Gegenwert: Es kommen Qualitätsrichtlinien dazu, eine automatische Code-Review mit PHPStan und SonarQube, die unkompilierte Fassung des JavaScript in einem eigenen Verzeichnis, Snippet-Übersetzungen mit Fallback, eine Deinstallation, die ihre Daten aufräumt, ein Produktions-Build innerhalb der Größenbeschränkung des Stores und nachvollziehbare Abhängigkeiten. Für ein Produkt lohnt das. Für Ihr internes Plugin liegt der Code besser in Ihrem eigenen Repository, versionierbar und ohne Freigabezyklus.
Das entscheiden Sie, und wir halten es schriftlich fest. Der Code liegt in Ihrem Repository, die Dokumentation gehört zur Lieferung — eine Übergabe an Ihr eigenes Team ist damit jederzeit möglich. Wenn wir die Pflege übernehmen, läuft sie über die Service-Level-Staffel: BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden Reaktionszeit, als Monatspauschale netto je Shop. Ohne solche Vereinbarung gilt bei uns die Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr.
Anfrage
Beschreiben Sie kurz, was die Erweiterung tun soll, oder welche vorhandene Ihnen im Weg steht. Wenn Sie unsicher sind, ob es dafür schon etwas im Store gibt: Das prüfen wir mit, und wenn es so ist, sagen wir es.