Plugins — und die Lizenzfrage, die Projekte aufhält.

Woher Plugins kommen.

Zeile vier verdient besondere Aufmerksamkeit: Zahlungs-Plugins kommen oft direkt vom Zahlungsanbieter und folgen dessen Veröffentlichungszyklus. Wenn der Anbieter eine Fassung für eine neue Shopware-Version später liefert, hängt der ganze Shop daran (Update).

Die Lizenzfrage.

Der Punkt, der bei Shopware anders ist als bei vielen anderen Systemen — und der Projekte aufhält.

Kostenpflichtige Plugins sind an eine Lizenz gebunden, die an den Shop und meist an einen Zeitraum geknüpft ist. Läuft sie aus, funktioniert das Plugin in der Regel weiter, bekommt aber keine Updates mehr.

Die Folge ist unangenehm: Bei einem Versionssprung braucht jedes Plugin eine passende Fassung. Ohne gültige Lizenz gibt es diese Fassung nicht — und damit blockiert ein einzelnes Plugin den gesamten Sprung.

1. Liste aller kostenpflichtigen Plugins mit Lizenzstatus und Verlängerungsdatum.
2. Vor jedem Versionssprung prüfen, welche Lizenzen aktiv sind.
3. Verlängerungen bündeln, damit sie nicht über das Jahr verstreut ablaufen.
4. Bei abgelaufener Lizenz entscheiden: verlängern, ersetzen oder Funktion streichen.
5. Kosten einplanen — das sind laufende Kosten, keine einmaligen.

Punkt fünf wird bei der Kalkulation eines Shops regelmäßig vergessen und summiert sich. Mach einmal eine Liste mit Jahresbeträgen — das Ergebnis überrascht oft.

Installieren und entfernen.

Bei Shopware sind es drei Zustände, nicht zwei: Ein Plugin kann vorhanden, installiert oder aktiviert sein. Das verwirrt Umsteiger und ist nützlich, wenn man es kennt.

1. Vorher sichern.
2. In der Testumgebung beginnen, nicht im laufenden Shop.
3. Plugin bereitstellen — über Store oder Abhängigkeitsverwaltung.
4. Installieren — dabei legt es seine Datenbankstrukturen an.
5. Aktivieren.
6. Cache leeren und Theme bauen, wenn es Gestaltung mitbringt (Cache und Build).
7. Prüfen, ob Shop und Verwaltung normal laufen.

Beim Entfernen ist die Reihenfolge wichtig: deaktivieren, deinstallieren, dann entfernen. Beim Deinstallieren fragt Shopware, ob die Daten des Plugins gelöscht werden sollen — diese Frage ernst nehmen. Wer sie bejaht, verliert die Daten; wer sie verneint, behält sie für eine spätere Neuinstallation.

Store oder Composer.

Beides funktioniert, und für einen produktiven Shop würde ich die Abhängigkeitsverwaltung empfehlen.

Gründe: Der Zustand ist über die Sperrdatei festgehalten und auf jeder Umgebung reproduzierbar. Updates lassen sich gemeinsam mit dem Kern ziehen. Und bei einem Wiederaufbau — nach einem Vorfall oder beim Aufsetzen einer Testumgebung — ist alles automatisch da.

Der Store ist bequemer für einzelne Plugins und für Shops ohne Kommandozeilenzugriff. Was man dabei verliert, ist die Nachvollziehbarkeit: Welche Fassung lief wann, und warum ist auf der Testumgebung etwas anderes installiert?

Mischen ist möglich und sollte eine bewusste Entscheidung sein, keine Gewohnheit.

Fehlerquelle eingrenzen.

1. Protokoll lesen — der Dateipfad verrät meist das Plugin (Protokoll finden).
2. In der Testumgebung arbeiten, nicht im Verkauf.
3. Verdächtiges Plugin deaktivieren, einzeln.
4. Cache leeren und prüfen.
5. Bei Erfolg: Fassung prüfen, Hersteller kontaktieren, Ersatz erwägen.
6. Bei Misserfolg: nächstes Plugin.

Welche Plugins zuerst? Bei Shopware verdächtige ich diese Reihenfolge: Plugins, die in den Seitenaufbau eingreifen; Plugins mit eigener Verwaltungsoberfläche; Zahlungs- und Versand-Plugins; dann der Rest. Die ersten drei Gruppen wirken an vielen Stellen gleichzeitig.

Ohne Backend geht das Deaktivieren über die Kommandozeile — ein weiterer Grund für diesen Zugriff.

Der vergessene Schritt.

Ein eigener Abschnitt, weil es so oft passiert: Nach der Installation eines Plugins mit Gestaltung oder eigener Verwaltungsoberfläche müssen Theme beziehungsweise Verwaltung neu gebaut werden.

Ohne diesen Schritt ist das Plugin installiert und aktiv — aber sein Element erscheint ohne Gestaltung, oder seine Einstellungsseite fehlt in der Verwaltung. Das sieht nach einem Fehler aus und ist keiner.

Die Faustregel: Nach jeder Plugin-Änderung Cache leeren, bei Gestaltung zusätzlich Theme bauen, bei eigener Oberfläche zusätzlich Verwaltung bauen. Im Zweifel alle drei (Die Schritte im Überblick).

Beim Versionssprung.

Hier entscheiden Plugins über Machbarkeit und Zeitplan. Vor jedem Sprung gehört eine Liste erstellt:

Zeile fünf ist die kritischste: Ein Shop ohne funktionierende Zahlungsart verkauft nicht. Die Verfügbarkeit der Zahlungs-Plugins gehört deshalb ganz an den Anfang der Planung — und nicht ans Ende.

Zeile sieben ist die angenehmste: Bei fast jedem gewachsenen Shop lässt sich ein Teil der Plugins ersatzlos streichen, weil die Funktion seit Jahren niemand nutzt.

Was Shopware selbst kann.

Vor der Suche nach einem Plugin lohnt der Blick, ob Shopware 6 die Funktion inzwischen mitbringt. Einiges, wofür früher Plugins nötig waren, ist heute im Standard:

• Regelbasierte Versand- und Zahlungsarten mit frei definierbaren Bedingungen.
• Erlebniswelten für gestaltete Kategorie- und Landingseiten.
• Kundenspezifische Preise und Kundengruppen.
• Mehrere Verkaufskanäle aus einer Installation.
• Schnittstelle für Anbindungen (Warenwirtschaft).
• Flow-Builder für automatische Abläufe bei Ereignissen.

Der letzte Punkt wird unterschätzt: Vieles, wofür man früher ein Plugin für Benachrichtigungen oder Statusänderungen brauchte, lässt sich damit zusammenklicken. Das spart ein Plugin und damit dauerhaften Pflegeaufwand.

Eigene Erweiterungen.

Wenn es nichts Passendes gibt, ist eine eigene Erweiterung der saubere Weg — deutlich besser als Anpassungen am Kern oder an fremden Plugins, die beim nächsten Update verschwinden.

Shopware 6 bietet dafür zwei Wege: ein klassisches Plugin, das im System läuft, oder eine App, die über die Schnittstelle angebunden ist und außerhalb läuft. Die App-Variante ist aufwendiger, aber entkoppelt — sie überlebt Versionssprünge leichter und ist für den Cloud-Betrieb die einzige Möglichkeit.

Für einen selbst gehosteten Shop mit überschaubarer Anpassung ist das Plugin meist richtig. Wichtig in beiden Fällen: die vorgesehenen Erweiterungspunkte nutzen statt Kernverhalten zu überschreiben — das entscheidet darüber, ob der nächste Sprung glatt läuft.

Auswahlkriterien.

1. Geht es auch ohne? Die wichtigste Frage.
2. Kann Shopware das inzwischen selbst?
3. Welche Shopware-Versionen werden unterstützt?
4. Wie oft erscheinen Aktualisierungen?
5. Was kostet die Lizenz im Jahr?
6. Wie reagiert der Hersteller auf Meldungen?
7. Greift es tief ein? Je tiefer, desto größer das Risiko beim Sprung.
8. Gibt es eine Testmöglichkeit?

Punkt fünf gehört bei Shopware ausdrücklich in die Entscheidung: Zehn Plugins mit je einem moderaten Jahresbeitrag summieren sich zu einem Posten, der in der Kalkulation auftauchen sollte.

Punkt sieben betrifft besonders Plugins, die Kasse, Preisfindung oder Adressstruktur verändern. Die sind oft nützlich und machen bei jedem Versionssprung Arbeit.

Aufräumen.

Einmal im Jahr, am besten vor einem geplanten Versionssprung:

• Pluginliste durchgehen — was wird genutzt, was ist aktiv ohne Zweck?
• Lizenzen prüfen und Jahreskosten zusammenrechnen.
• Prüfen, was Shopware inzwischen selbst kann.
• Nicht genutzte Plugins deinstallieren und entfernen, nicht nur deaktivieren.
• Daten entfernter Plugins in der Datenbank prüfen.
• Testplugins aus Evaluierungen entfernen.
• Eigene Erweiterungen auf veraltete Schnittstellen prüfen.

Punkt vier mit Nachdruck: Ein deaktiviertes Plugin, dessen Dateien noch auf dem Server liegen, ist weiterhin vorhanden — es kann angreifbar sein und blockiert beim nächsten Sprung die Abhängigkeitsauflösung. Was nicht gebraucht wird, gehört weg (Wartung).

Punkt zwei zahlt direkt ein: Wer dabei drei ungenutzte kostenpflichtige Plugins findet, spart deren Jahresbeiträge und hat beim nächsten Versionssprung drei Prüfpunkte weniger.

Wenn du nicht weiterkommst.

Wenn ein Plugin Ärger macht oder du vor einem Sprung wissen musst, was mit deinen Plugins passiert. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Wenn gerade keine Bestellungen durchgehen, hilft der Notfall-Support, dauerhaft begleitet die Shopware-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management- und Shopsysteme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme von innen: Datenmodell, Rechtekonzept, Templating, Plugin-Architektur, Caching, Betrieb.

Bei Shopware 6 zahlt sich das besonders aus, weil es auf demselben professionellen Unterbau aufsetzt wie andere ausgewachsene Systeme: Abhängigkeitsverwaltung, Dienste-Container, eine getrennte Verwaltungsoberfläche und eine Schnittstelle für alles. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo ein Shop gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob dein Shop weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.