Ein Plugin-Audit in Shopware ist die systematische Analyse aller installierten Extensions nach Funktion, Risiko und Notwendigkeit. Ohne diesen Ansatz wird das „Aufräumen“ schnell zum Risiko. Abhängigkeiten bleiben unentdeckt, Funktionen fallen unbemerkt aus, Schnittstellen brechen.
Plugin-Bloat entsteht über Monate und Jahre. Marketing installiert ein Tool für eine Kampagne, die Entwicklung ergänzt eine Extension, der Vertrieb benötigt eine ERP-Anbindung. Jedes Plugin für sich sinnvoll. Häufig fehlt jedoch Dokumentation, Redundanzen werden nicht geprüft, alte Tools bleiben nach Projektende aktiv. Das Ergebnis sind 15 bis 22 aktive Extensions – und ein Teil davon wird nicht mehr genutzt oder ist durch Core-Funktionen inzwischen überflüssig.
„Updates sind blockiert“ wird dann zum Standardproblem. Mehrere Plugins sind nicht kompatibel, einzelne werden nicht mehr gepflegt, andere kollidieren. Updates werden verschoben, Sicherheitslücken bleiben offen, Performance-Plugins laufen auf veralteten Abhängigkeiten. Ein strukturiertes Plugin-Audit verhindert das, bevor Updates praktisch unmöglich werden.
Warum Aufräumen ohne Plan gefährlich ist
Plugins ohne Analyse zu deaktivieren, erzeugt oft versteckte Fehler. Plugin A wird entfernt, Plugin B hängt aber davon ab – ohne dass es dokumentiert ist. Der Checkout funktioniert weiterhin, aber Versandetiketten werden nicht mehr erstellt, Rechnungen fehlen im ERP oder Cronjobs schlagen fehl. Solche Fehler zeigen sich oft erst Tage später.
Datenbank-Abhängigkeiten sind ein besonderes Risiko. Ein Plugin wird deaktiviert, Tabellen bleiben bestehen, Custom Fields werden jedoch entfernt. Andere Prozesse greifen darauf zu, erhalten Null-Werte und erzeugen Folgefehler. Im schlimmsten Fall schlägt später ein Shopware-Update fehl, weil Referenzen fehlen und Migrationen abbrechen.
Performance-Plugins greifen häufig in Core-Mechanismen ein. Sie verändern Caching, Template-Rendering oder Datenbankabfragen. Wird ein solches Plugin ohne Tests entfernt, kann der Shop langsamer werden – oder andere Plugins brechen, weil sie auf die Änderungen angewiesen waren.
Wir sehen häufig Fälle, in denen ein Plugin „nicht mehr genutzt“ wirkte. Monate später stellt sich heraus, dass eine Schnittstelle nicht mehr läuft, Newsletter nicht versendet werden oder Importe fehlschlagen. Das Plugin wird reaktiviert, aber verlorene Daten lassen sich nicht immer wiederherstellen.
Der Audit-Ansatz: kritisch, nützlich, redundant
Ein strukturiertes Plugin-Audit ordnet jedes Plugin nach drei Kriterien ein: Geschäftskritikalität, tatsächliche Nutzung und technisches Risiko.
Kritische Plugins
- Payment-Provider wie PayPal, Klarna, Stripe (ohne sie kein Checkout)
- ERP-Anbindungen (Bestellungen, Lager, Kundendaten)
- Versanddienstleister-Integrationen (DHL, UPS, Hermes)
- Rechtlich notwendige Extensions (Cookie-Consent, DSGVO-Funktionen)
- Business-Process-Plugins (Workflows, Rechnungserstellung, Mahnwesen)
Diese Plugins sollten nur deaktiviert werden, wenn ein funktionsfähiger Ersatz vorhanden ist.
Nützliche Plugins
- Marketing-Extensions (Newsletter, Empfehlungen, Remarketing)
- SEO-Plugins (Meta-Tags, Redirects, strukturierte Daten, Sitemaps)
- Performance-Plugins mit messbarem Effekt
- Analytics-Tools (Hotjar, Clarity, erweiterte GA-Funktionen)
- UX-Erweiterungen (Filter, Vergleich, Wunschliste)
Diese Plugins können bleiben, sollten aber regelmäßig geprüft und ggf. ersetzt werden.
Redundante Plugins
- Kampagnen-Tools, die nach Projektende weiterlaufen
- Überlappende Funktionen (zwei Plugins machen faktisch dasselbe)
- Plugins, die durch Shopware-Core-Updates überflüssig wurden
- Test-Plugins ohne produktive Nutzung
- Extensions ohne messbaren Nutzen bei messbarem Ressourcenverbrauch
Diese Plugins lassen sich nach Abhängigkeitsprüfung meist deaktivieren.
Ein Audit bedeutet pro Plugin: dokumentieren, wer es nutzt, wofür, wie oft, welche Abhängigkeiten bestehen, welche Datenbankänderungen es mitbringt, ob Alternativen existieren und was bei Deaktivierung passiert.
Update-Reihenfolge und Risiko-Zonen
Blockierte Updates entstehen häufig durch falsche Reihenfolge oder durch Plugin-Kombinationen, die erst zusammen problematisch werden.
Beispiel: Der Core wird aktualisiert, Plugin A und B laufen, Plugin C kollidiert mit der neuen Kombination. Rollback ist nötig, aber Plugin A hat bereits Migrationen durchgeführt, die nicht sauber rückgängig zu machen sind. Der Shop bleibt instabil, bis Versionen und Abhängigkeiten manuell bereinigt sind.
Risiko-Zonen erkennen
- Plugins, die Core-Funktionen überschreiben (Checkout, Payment, Import)
- Extensions mit vielen Abhängigkeiten (Composer-Packages, andere Plugins)
- Performance-Plugins, die Caching, Rendering oder Queries verändern
- Plugins ohne aktiven Hersteller-Support oder ohne Updates seit über 6 Monaten
- Custom-Code, der an eine bestimmte Plugin-Version gebunden ist
Wir sehen oft Shops auf 6.4.15, während 6.5.8 aktuell ist. Ursache sind wenige Plugins, die 6.5 blockieren – darunter häufig mindestens ein geschäftskritisches.
Ein Plugin-Audit identifiziert solche Blocker vor dem Updateversuch: Was muss vor dem Core-Update aktualisiert werden, was danach, wo braucht es Ersatz, was muss in Staging validiert werden.
Kurztest: Welche Plugins sind kritisch?
Für jedes Plugin sollten diese Fragen eindeutig beantwortet werden können:
- Ist dokumentiert, welche Funktion das Plugin erfüllt?
- Wird es mindestens wöchentlich genutzt?
- Sind Abhängigkeiten zu anderen Plugins bekannt?
- Gibt es eine verantwortliche Person im Team?
- Wurde es in den letzten 6 Monaten aktualisiert?
- Ist die Kompatibilität zur aktuellen Shopware-Version bestätigt?
- Gibt es eine dokumentierte Alternative für Ausfall-Szenarien?
- Ist bekannt, ob und welche Core-Funktionen überschrieben werden?
Auswertung pro Plugin:
0–2 Nein: Gut dokumentiert, geringes Risiko.
3–5 Nein: Unvollständig dokumentiert, mittleres Risiko.
6–8 Nein: Hohes Risiko, im Audit priorisieren.
Plugin-Kategorie, Risiko, Audit-Check
| Plugin-Kategorie | Typisches Risiko | Was im Audit geprüft werden sollte |
|---|---|---|
| Payment-Provider | Checkout nicht nutzbar bei Deaktivierung | Abhängigkeiten, Alternative, Update-Kompatibilität |
| ERP-Anbindung | Bestellungen/Lager nicht synchronisiert | API-Stabilität, Cronjob-Logs, Fehlerrate, Backup-/Fallback-Prozess |
| Versanddienstleister | Etiketten/Tracking fehlen | Funktion nach Update, Alternative, gültige API-Tokens |
| Performance-Plugins | Core-Caching überschrieben, Instabilität nach Updates | Messbarer Effekt vor/nach Deaktivierung, Core-Overrides, Tests in Staging |
| Marketing-Tools | Läuft nach Kampagnenende weiter, Ressourcenverbrauch | Nutzungsfrequenz, Datenbankänderungen, sichere Deaktivierung |
| SEO-Extensions | Redirects/Meta-Daten gehen verloren | Datenbank-Abhängigkeiten, Exportmöglichkeit, Alternative |
| Analytics/Tracking | Performance-Bremse ohne klaren Nutzen | Script-Last messen, tatsächliche Nutzung, geschäftliche Notwendigkeit |
| Temporäre Tools | Nach Projektende vergessen, blockiert Updates | Letzte Nutzung, Datenbank-Reste, Deaktivierung getestet |
Plugin-Stack systematisch prüfen
Wir analysieren Abhängigkeiten, bewerten Risiken, identifizieren redundante Extensions und liefern eine priorisierte Roadmap zur Stabilisierung.
Stabilisierung-Audit anfragen (2.500 €)
10 Werktage Laufzeit, vollständige Analyse, konkrete Handlungsempfehlungen.
Roadmap statt Löschaktion
Plugin-Bloat beheben gelingt über eine Roadmap in fünf Phasen.
Phase 1 – Inventar und Kategorisierung (1–2 Tage)
Vollständige Liste erstellen (Name, Version, Hersteller, Installationsdatum). Kategorisieren (kritisch/nützlich/redundant). Nutzung und Prozesse dokumentieren. Abhängigkeiten per Code- und Composer-Analyse erfassen. Custom-Code identifizieren.
Phase 2 – Risikobewertung (2–3 Tage)
Kompatibilität mit aktueller und nächster Shopware-Version prüfen. Update-Status und Hersteller-Support bewerten. Datenbankänderungen dokumentieren (Custom Fields, Tabellen, Keys). Performance-Plugins in Staging per Vorher/Nachher messen. Core-Overrides per Code-Review erfassen.
Phase 3 – Alternativen und Ersatz (3–5 Tage)
Alternativen für redundante oder veraltete Plugins prüfen. Bei überlappenden Funktionen entscheiden, was bleibt. Custom-Code bei Bedarf in eigene Plugins auslagern. Kosten/Nutzen für kommerzielle Alternativen bewerten.
Phase 4 – Test und Deaktivierung (3–5 Tage)
Staging-Umgebung wie Produktion aufsetzen. Redundante Plugins einzeln deaktivieren und nach jedem Schritt kritische Funktionen testen (Checkout, Payment, Versand, ERP, Cronjobs). Fehler dokumentieren, Rollback-Plan erstellen. Nach Tests produktiv deaktivieren und 1–2 Wochen überwachen.
Phase 5 – Dokumentation und Wartung (laufend)
Änderungen nachvollziehbar dokumentieren. Update-Plan inkl. Reihenfolge definieren. Halbjährliche Reviews einplanen. Prozess für neue Plugins festlegen (Dokumentation, Risiko, Verantwortung).
Audit als Entscheidungsvorlage
Ein Plugin-Audit zeigt nicht nur, welche Plugins aktiv sind, sondern welche Risiken sie erzeugen, welche Abhängigkeiten bestehen und welche Update-Blocker vorhanden sind.
Unser Shopware 6 Stabilisierung- und Migrations-Audit umfasst: Kompatibilitätscheck, Analyse von Core-Overrides, Konflikt- und Dependency-Prüfung, Messung der Performance-Plugins in Staging, Dokumentation von Datenbankänderungen und eine sichere Update-Reihenfolge.
Kosten: 2.500 €
Dauer: 10 Werktage
Ergebnis: priorisierte Roadmap mit Aufwandsschätzung
Wenn Updates blockiert sind oder Plugin-Bloat Performance und Stabilität kostet, ist das der nächste Schritt.
Jetzt Stabilisierung-Audit anfragen
Wir prüfen Abhängigkeiten und Update-Fähigkeit und liefern eine Roadmap zur Stabilisierung Ihres Plugin-Stacks. Konkrete Handlungsempfehlungen, keine Theorie.
Stabilisierung-Audit anfragen (2.500 €)
Sie erhalten:
- Analyse der Plugin-Abhängigkeiten
- Update-Kompatibilitäts-Check
- Identifikation von Core-Overrides
- Performance-Messungen in Staging
- Risiko-Bewertung
- Priorisierte Roadmap
Aufwandsschätzung
