Shopware 6 Debugging – Shopware Fehler finden und verschwinden lassen

von Der Atilla | Juli 30, 2025 | Alle, Shopware 6, Shopware Entwicklung, Shopware Monitoring & Analyse, Shopware Plugins | 0 Kommentare

Übersicht: Shopware 6 Debugging – Die wichtigsten Schritte & Tools

1. Einleitung: Shopware 6 Debugging – Warum und wann?
2. Debug- und Developer-Modus in Shopware 6 aktivieren
3. Die Symfony Developer Toolbar – Das Schweizer Taschenmesser fürs Debugging
4. Logfiles und Event-Logs richtig nutzen
5. Cache-Management und Debugging
6. SQL-Queries debuggen in Shopware 6
7. API Debugging und Schnittstellen-Analyse
8. Top Plugins & Tools für effizientes Debugging
9. Theme- und Template-Debugging
10. Performance-Analyse und Bottleneck-Findung
11. Nicht standardmäßig vorhandene Erweiterungen & Plugins schnell deaktivieren
12. Debugging-Checklisten & FAQ
13. Fazit: Shopware 6 Debugging erfolgreich meistern
14. Elasticsearch Debugging
15. Quellen & Weiterführende Links

Zurück zur Übersicht

1. Einleitung: Shopware 6 Debugging – Warum und wann?

Spoiler: Der kürzeste Weg, um einen Fehler zu beheben, ist – wenn du Glück hast – ein veralteter Cache (siehe Punkt 5), der geleert werden muss, ein Theme, das kompiliert werden muss (gehe zu in den Bereich Inhalte > Themes > wähle dein Theme aus > klicke Speichern) , oder aber ein Verkaufskanal, der nur wieder aktiviert werden muss. In allen anderen Fällen können dir die folgenden Tipps hoffentlich weiterhelfen, deine Bugs zu beheben. Ich wünsche dir viel Erfolg, Geduld und eine PlayStation zu Weihnachten.

Shopware 6 Debugging ist ein zentrales Thema für Entwickler, Agenturen und Shopbetreiber. Fehler können an unterschiedlichsten Stellen auftreten – von fehlerhaften Plugins bis zu Problemen im Core oder individuellen Anpassungen. Wer systematisch debuggt, spart nicht nur Zeit, sondern sorgt auch für einen stabil laufenden Shop und zufriedene Kunden. In diesem Beitrag erfährst du, wie du mit Shopware 6 Debugging effizient Fehlerquellen aufdeckst, analysierst und behebst. Und vor allem: Mit System vorgehst ohne jedes Mal von neuem zu überlegen, was du als nächstes machen wirst.

Debugging ist nicht nur Fehlerbehebung, sondern auch ein Prozess zur Qualitätssicherung und Optimierung. Moderne Shopsysteme wie Shopware 6 sind hochkomplex, da sie auf dem Symfony-Framework aufbauen, zahlreiche Schnittstellen und APIs bieten und individuell erweiterbar sind. Gerade deshalb ist ein strukturiertes Debugging-Konzept essenziell, um Fehlerquellen schnell zu identifizieren und nachhaltig zu beheben.

Zurück zur Übersicht

2. Debug- und Developer-Modus in Shopware 6 aktivieren

Shopware 6 unterscheidet strikt zwischen Produktivmodus (APP_ENV=prod) und Entwicklungsmodus (APP_ENV=dev). Im Produktivmodus werden Fehler in der Regel nur sehr allgemein ausgegeben. Für detaillierte Fehlermeldungen und vollständige Stacktraces ist der Developer- bzw. Debug-Modus notwendig.

Debug-Modus aktivieren – Schritt für Schritt

.env.local-Datei öffnen (empfohlen, da Updates an .env diese überschreiben können). Falls nicht vorhanden, einfach anlegen. Alternativ kannst du auch die .env-Datei im Hauptverzeichnis deiner Shopware 6 Installation öffnen – diese Datei ist oft versteckt, ggf. musst du versteckte Dateien anzeigen lassen.
Ändere die Zeile APP_ENV=prod auf APP_ENV=dev.
Optional: Setze APP_DEBUG=1, um die Debug Toolbar explizit zu aktivieren.
Speichere die Datei.
Leere den Cache mit php bin/console cache:clear.

Nach dem Aktivieren erscheint im Backend und Frontend die Symfony Debug Toolbar, die zahlreiche nützliche Infos liefert. Achtung: Der Debug-Modus sollte niemals dauerhaft im Livebetrieb aktiv sein, da sensible Daten sichtbar werden und die Performance leidet. Nutze ihn gezielt auf Staging- oder lokalen Systemen.

Tipp: Nutze immer .env.local für lokale Anpassungen, da diese Datei beim Update erhalten bleibt und individuelle Einstellungen überschreibt. Insbesondere ab Version 6.5.0.0 sollte man die Finger von der .env-Datei lassen. Nach Abschluss des Debuggings immer wieder auf APP_ENV=prod zurückstellen!

Im Dev-Modus werden deutlich mehr Details geloggt, u. a. vollständige Stacktraces und Performance-Daten.
Im Prod-Modus werden nur kritische Fehler protokolliert – ideal für den Livebetrieb.
Mit APP_DEBUG=1 kannst du die Debug Toolbar gezielt ein- und ausschalten.
Die Variable APP_URL sollte im Dev-Modus korrekt gesetzt sein, um Probleme mit CORS und API-Zugriffen zu vermeiden.

Gut zu wissen: Sobald wir den Developer-Modus aktivieren, wird in unserem Ordner var/log eine Datei namens dev.log angelegt. Diese wird nicht für jeden Tag neu erstellt, sondern sammelt alle Einträge, die über die Zeit entstehen, in einer einzigen Datei. Das kann gefährlich werden, wenn die Datei auf astronomische Größen anwächst und die Grundfunktion des Shops eingeschränkt wird. Daher sollte man die Datei im besten Fall nach jedem Debugging wieder löschen oder die Bereinigung bzw. das Löschen der Datei automatisieren.

Erklärung: Stacktrace

Ein Stacktrace zeigt die Aufrufreihenfolge im Code bis zum Fehler. So können Entwickler Fehlerquellen gezielt nachvollziehen und beheben.

Zurück zur Übersicht

Die Symfony Developer Toolbar erscheint im Debug-Modus am unteren Rand des Backends und Frontends. Sie ist ein zentrales Werkzeug für Entwickler und bietet eine Vielzahl nützlicher Informationen auf einen Blick:

Performance: Übersicht über Ladezeiten, CPU- und Speicherverbrauch pro Request
Requests: Detaillierte Analyse aller HTTP-Anfragen
Datenbank (Doctrine): Anzeige aller SQL-Queries, deren Ausführungsdauer und eventueller Fehler
Templates: Auflistung aller geladenen Twig-Templates und deren Variablen
Fehler & Warnungen: Echtzeit-Anzeige von Fehlern und Warnungen
Events: Welche Events wurden ausgelöst und welche Listener haben reagiert?
Routing: Welcher Controller wurde angesprochen?
Security: Welche User sind eingeloggt? Welche Berechtigungen wurden geprüft?
Services: Übersicht aller geladenen Services und deren Parameter
HTTP-Analyse: Analyse von HTTP-Headern, Cookies und Sessions

Mit der Toolbar kannst du direkt nachvollziehen, welche Events getriggert wurden, welche Controller angesprochen wurden und wie lange einzelne Prozesse gedauert haben. Das spart enorm viel Zeit bei der Fehlersuche und Optimierung.

Zurück zur Übersicht

4. Logfiles und Event-Logs richtig nutzen

Shopware 6 speichert alle Systemmeldungen, Fehler und Warnungen in Logdateien im Verzeichnis /var/log/. Je nach Modus werden die Dateien prod.log oder dev.log beschrieben. Zusätzlich findest du im Backend unter Einstellungen > System > Event-Logs eine Übersicht über alle Ereignisse und Fehlermeldungen, die im Shop aufgetreten sind:

So nutzt du Logs effektiv:

Regelmäßige Kontrolle der Logs – am besten täglich oder wöchentlich.
Logrotation einrichten, um alte Logs zu archivieren oder automatisch zu löschen.
Kritische Fehler sollten automatisiert eskaliert werden, z. B. per E-Mail oder Slack-Alert.
Eigene Logs für individuelle Plugins nutzen und dokumentieren.
Log-Level sinnvoll wählen: debug für Entwicklung, error für produktive Umgebung.
Logfiles können mit Tools wie less, tail -f oder speziellen Log-Viewern analysiert werden.

Hinweis: Auch viele Shopware-Plugins (z. B. Zahlungsanbieter wie PayPal) legen eigene Logdateien im selben Verzeichnis an. Nicht jedes Plugin erstellt automatisch Logs – im Zweifel beim Hersteller nachfragen. Neben den Shopware-Logs können auch Server-Access-Logs oder PHP-Logs bei komplexen Fehlern hilfreich sein.

Log-Analyse: Fehler schnell identifizieren

Die wichtigsten Felder in den Logfiles sind:

Feld	Bedeutung
Timestamp	Wann ist der Fehler aufgetreten?
Level	(debug, info, warning, error, critical)
Channel	Aus welchem Bereich stammt der Fehler? (z. B. system, plugin, doctrine)
Message	Die eigentliche Fehlermeldung
Stacktrace	Gibt Aufschluss über die Fehlerursache und den Ablauf bis zum Fehler

Tipp: Wer das kostenlose Tools-Plugin von Frosh installiert, kann die Log-Dateien im Admin-Bereich einsehen und spart sich den Weg über ein FTP-Programm.

Zurück zur Übersicht

5. Cache-Management und Debugging

Shopware 6 nutzt verschiedene Caching-Mechanismen, um die Performance zu steigern. Fehlerhafte oder veraltete Caches führen jedoch oft zu Problemen, z. B. werden Änderungen nicht angezeigt oder alte Daten ausgeliefert.

HTTP-Cache: Zwischenspeicherung von Seiten und API-Responses
Template-Cache: Zwischenspeicherung von Twig-Templates
Doctrine-Cache: Zwischenspeicherung von Datenbankabfragen

Cache leeren und gezielt debuggen

Cache im Backend unter Einstellungen > System > Caches & Indizes leeren
Per CLI: php bin/console cache:clear
Für einzelne Bereiche gezielt Caches löschen (z. B. HTTP-Cache, Theme-Cache)
Nach Änderungen an Plugins, Themes oder Konfigurationen immer Cache leeren

Wenn das normale Cache löschen nicht zum Ziel führt gibt es noch einige Befehle, die man mit dem Terminal nutzen kann:

composer dump-autoload
bin/console cache:clear
bin/console plugin:refresh
bin/console theme:refresh
bin/console theme:compile

Cache porentief bereinigen

Fun-Fact: Während ich diesen Beitrag geschrieben habe, habe ich zwischendurch ein Plugin erstellt, mit dem man aus dem Admin-Bereich die .env.local-Datei anpassen kann, um zwischen Live- und Developer-Modus umzuschalten.

Es hätte eine Sache von 1–2 Stunden sein können, um ein funktionales Grundgerüst zu erstellen. Zuerst waren Dateien in falschen Ordnern und danach hat der Cache mir stundenlang ein Bein gestellt.

Obwohl ich nach jeder Änderung den obigen Befehl ausgeführt und das Plugin de- und reaktiviert habe, wollte sich partout nichts tun. Bis ich per Zufall wieder über den zweiten Befehl gestolpert bin, den man am besten wie folgt mit dem ersten kombiniert, um den Cache wirklich porentief zu bereinigen:

bin/console cache:clear
rm -rf var/cache/*

Wenn ich etwas an den Einstellungen eines Plugins ändere, dann ist das (siehe unten) aktuell meine Kombination, die ich auf einmal als Befehl absende, um zuerst den Cache zu löschen, das Plugin hart zu deinstallieren und neu zu installieren und anschließend erneut den Cache zu leeren.

In diesem Fall am Beispiel des Bug Buster – Debugging like a Pro Plugins, mit dem man den Developer Mode ein- und ausschalten kann, ohne die .env.local-Datei öffnen und bearbeiten zu müssen:

bin/console cache:clear
rm -rf var/cache/*
bin/console plugin:uninstall GreatSwitchToDev
bin/console plugin:install --activate GreatSwitchToDev
bin/console cache:clear
rm -rf var/cache/*

Den Pluginnamen müsst ihr logischerweise anpassen.

Tipp: Im Debug-Modus werden viele Caches automatisch deaktiviert oder schneller invalidiert, was die Entwicklung erleichtert.

Zurück zur Übersicht

6. SQL-Queries debuggen in Shopware 6

Viele Fehler in Shopware 6 hängen mit fehlerhaften oder zu langsamen Datenbankabfragen zusammen. Mit der Symfony Toolbar und Plugins wie dem FroshProfiler kannst du alle ausgeführten SQL-Queries einsehen und analysieren. Das hilft dir, fehlerhafte Queries zu identifizieren, Performance-Engpässe zu erkennen und gezielt zu optimieren.

Typische SQL-Probleme und deren Analyse

Langsame Abfragen: Mit EXPLAIN-Statements in der Datenbank analysieren
Fehlende Indizes: Prüfen, ob alle relevanten Felder indiziert sind
Fehlerhafte JOINs: Komplexe JOINs können zu unerwarteten Ergebnissen führen
ORM-Probleme: Doctrine generiert manchmal ineffiziente Queries – hier hilft das Logging

SQL-Debugging Schritt für Schritt

Um SQL-Probleme in Shopware 6 gezielt zu finden und zu beheben, empfiehlt es sich, systematisch vorzugehen:

Debug-Modus aktivieren und Seite mit Fehler aufrufen
In der Toolbar unter „Doctrine“ alle Queries prüfen
Verdächtige Abfragen in der Datenbank mit EXPLAIN analysieren
Optimierungen (z. B. Index hinzufügen) testen
Ergebnis erneut prüfen und ggf. weitere Optimierungen vornehmen

Schau dir die Queries genau an und achte besonders auf diejenigen, die ungewöhnlich lange dauern oder ungewöhnlich aussehen. Solche verdächtigen Abfragen kannst du anschließend direkt in deiner Datenbank mit dem Befehl EXPLAIN analysieren. Das hilft dir zu verstehen, wie die Abfrage von der Datenbank verarbeitet wird und ob zum Beispiel Indexe fehlen.

Wie funktioniert EXPLAIN?

Kopiere die auffällige SQL-Query und schreibe EXPLAIN davor, zum Beispiel:

EXPLAIN SELECT * FROM customers WHERE city = 'Berlin';

Die Datenbank liefert dir dann eine Analyse, wie sie diese Abfrage intern verarbeitet. Besonders interessant sind dabei folgende Spalten:

table: Welche Tabelle wird abgefragt?
type: Wie wird gesucht? (ALL = kompletter Tabellenscan, was langsam ist; ref/const = schneller, weil ein Index benutzt wird)
key: Welcher Index wird tatsächlich verwendet?
rows: Wie viele Zeilen muss die Datenbank ungefähr durchsuchen?
Extra: Zusätzliche Hinweise, z. B. ob ein temporärer Zwischenspeicher nötig ist oder ein Index genutzt wird.

Wenn du siehst, dass deine Abfrage keinen Index nutzt und stattdessen einen vollständigen Tabellenscan macht (type: ALL), solltest du prüfen, ob ein Index auf die betroffene Spalte fehlt. In dem Fall kannst du einen passenden Index anlegen oder die Query so anpassen, dass sie effizienter wird.

Teste nach jeder Optimierung die Abfrage erneut mit EXPLAIN und prüfe, ob sich die Performance verbessert hat. Wiederhole diese Schritte bei Bedarf, bis die Seite wieder schnell und fehlerfrei läuft. Mit dieser Methode kannst du SQL-Probleme strukturiert und effizient beheben.

6.1 Praxisbeispiel: Langsame Seiten und AJAX-Requests analysieren

Die Theorie ist das eine – aber wie sieht das Ganze in der Praxis aus? Hier ein typischer Debugging-Workflow am Beispiel einer B2B-Schnellbestellungs-Seite, die quälend langsam lädt.

Schritt 1: AJAX-Requests in der Toolbar identifizieren

Nicht immer ist die Seite selbst das Problem. Oft sind es AJAX-Requests, die im Hintergrund laufen und die Seite ausbremsen. Die Symfony Toolbar zeigt dir alle AJAX-Requests inklusive Ladezeiten. Klicke in der Toolbar auf den kleinen Bereich, der die Anzahl der AJAX-Requests anzeigt:

AJAX-Requests in der Symfony Toolbar analysieren

In diesem Beispiel siehst du vier AJAX-Requests. Der Übeltäter ist sofort erkennbar: remoteListFastOrder mit einer Ladezeit von mehreren Sekunden – in extremen Fällen sogar über 50 Sekunden! Klicke auf den Profiler-Token (z. B. d0ae8c), um die Details zu diesem Request zu öffnen.

Schritt 2: Den richtigen Profiler-Token finden

Manchmal ist nicht ein einzelner AJAX-Request das Problem, sondern die gesamte Seite lädt langsam. In diesem Fall findest du den Profiler-Token für den Seitenaufruf selbst ganz rechts in der Symfony Toolbar. Fahre mit der Maus über das Symfony-Logo und du siehst den aktuellen Token:

Shopware 6 Debugging: Profiler-Token in der Symfony Toolbar finden

Hier siehst du auch auf einen Blick, in welcher Umgebung du dich befindest (dev), welche PHP-Version läuft (z. B. 8.2.29) und welche Extensions aktiv sind (Xdebug, APCu, OPcache). Das ist besonders hilfreich, wenn du prüfen willst, ob die richtigen Caching-Mechanismen aktiv sind.

Schritt 3: Doctrine-Queries im Profiler analysieren

Klicke auf den Profiler-Token und wähle im linken Menü Doctrine. Hier wird es spannend:

Shopware 6 Debugging: Doctrine-Queries im Symfony Profiler analysieren

Die Query Metrics zeigen dir sofort das Ausmaß des Problems:

Database Queries: 2755 – das sind verdächtig viele!
Different statements: 309 – so viele verschiedene Query-Typen
Query time: 1340.38 ms – allein die Datenbank braucht über eine Sekunde

Zwei wichtige Funktionen, die du kennen solltest:

„Group similar statements“ – Klicke darauf, um ähnliche Queries zusammenzufassen. Manchmal sind nicht einzelne langsame Queries das Problem, sondern dieselbe Query wird hunderte Male ausgeführt (N+1-Problem).
Sortierung nach „Time“ – Klicke auf die Spaltenüberschrift, um die langsamsten Queries nach oben zu sortieren. So findest du die größten Zeitfresser sofort.

Für jede Query hast du mehrere Optionen:

View formatted query – Lesbare Darstellung der Query
View runnable query – Query mit eingesetzten Parametern, direkt kopierbar für die Datenbank
Explain query – Führt EXPLAIN direkt im Profiler aus
View query backtrace – Zeigt dir, welcher Code die Query ausgelöst hat – Gold wert beim Debugging!

Typische Erkenntnisse aus diesem Workflow

Zu viele Queries: Über 2000 Queries für einen einzelnen Request deuten auf ein N+1-Problem hin. Hier hilft oft Eager Loading oder das Caching von Ergebnissen.
Langsame Einzelqueries: Queries mit über 100ms solltest du mit EXPLAIN analysieren – meist fehlt ein Index.
Wiederholte identische Queries: Wenn dieselbe Query 50x ausgeführt wird, sollte das Ergebnis gecacht werden.

Tipp: Speichere dir den Profiler-Token, wenn du ein Problem dokumentieren oder später analysieren möchtest. Der Profiler speichert die letzten Requests und du kannst sie unter /_profiler/ jederzeit wieder aufrufen.

Zurück zur Übersicht

8. Top Plugins & Tools für effizientes Debugging

Neben den Bordmitteln von Shopware 6 gibt es zahlreiche Plugins, die das Debugging erleichtern. Besonders beliebt ist der FroshProfiler:

Erweitert die Symfony Toolbar um zusätzliche Debugging-Informationen
Zeigt alle registrierten und ausgelösten Events
Stellt Datenbankabfragen und deren Ergebnisse übersichtlich dar
Liefert detaillierte Template-Informationen
Zeigt alle geladenen Plugins und deren Hooks
Visualisiert HTTP-Requests und API-Calls

Weitere nützliche Tools:

Xdebug: Ermöglicht das Step-by-Step-Debugging von PHP-Code direkt in deiner IDE (z. B. PhpStorm, VS Code).
Doctrine Debug Helper: Zum sicheren Ausgeben und Loggen komplexer Objekte.
Log-Viewer-Plugins: Für eine komfortable Durchsicht großer Logdateien direkt im Backend.
PHPStan & Psalm: Statische Code-Analyse zur frühzeitigen Erkennung von Fehlern und Typ-Problemen.
Blackfire & Tideways: Performance-Profiling und Bottleneck-Analyse.

Empfohlene Plugin-Konfiguration

FroshProfiler nur auf Entwicklungs- oder Staging-Systemen aktivieren
Regelmäßig Updates einspielen, um Kompatibilität zu gewährleisten
Individuelle Log-Levels und Filter für Log-Viewer-Plugins nutzen

Weitere hilfreiche Plugins:

Debug für Produktivsysteme
Mail Debug Helfer
Debugger für Google Search Console
SMTP Connection Checker
Mail-Archiv, CC/BCC-Empfänger, Debugging & mehr
Shopware Cache Helper

Zurück zur Übersicht

9. Theme- und Template-Debugging

Individuelle Themes und Templates sind häufige Fehlerquellen. Fehlerhafte Twig-Syntax, falsche Vererbung oder fehlende Blöcke führen zu Darstellungsfehlern oder sogar zu White Screens.

Typische Probleme und Lösungen

Syntaxfehler: Twig-Fehler werden im Debug-Modus detailliert angezeigt
Vererbungsprobleme: Prüfen, ob Blöcke korrekt überschrieben werden
Asset-Probleme: JS- und CSS-Dateien werden nicht geladen – Pfade und Cache prüfen
Template-Cache: Nach Änderungen immer Cache leeren

Tools für Theme-Debugging

Symfony Toolbar: Zeigt alle geladenen Templates und Blöcke
FroshProfiler: Detaillierte Template- und Block-Übersicht
Browser Developer Tools: Fehler in der Console und im Netzwerk-Tab analysieren

Zurück zur Übersicht

10. Performance-Analyse und Bottleneck-Findung

Performance-Probleme sind oft schwer zu lokalisieren. Shopware 6 bietet verschiedene Möglichkeiten zur Performance-Analyse:

Symfony Toolbar: Zeigt Ladezeiten, Datenbankabfragen und Speicherverbrauch pro Request
Blackfire & Tideways: Externe Tools zur detaillierten Profilierung
Server-Monitoring: CPU, RAM und I/O-Auslastung überwachen

Typische Performance-Bottlenecks

Langsame SQL-Queries (siehe oben)
Unnötige oder doppelte API-Requests
Zu große oder nicht optimierte Bilder und Assets
Fehlerhafte oder zu viele Plugins
Nicht aktivierte Caches

Performance-Optimierung Schritt für Schritt

Mit der Toolbar Engpässe identifizieren (z. B. lange Ladezeiten, viele Queries)
Größte Zeitfresser gezielt analysieren (Datenbank, API, Theme)
Optimierungen umsetzen und erneut messen
Langfristig: Regelmäßige Code-Reviews und Updates

Zurück zur Übersicht

11. Nicht standardmäßig vorhandene Erweiterungen & Plugins schnell deaktivieren

Ein häufiger Grund für Fehler in Shopware 6 sind inkompatible oder fehlerhafte Plugins und Erweiterungen. Gerade beim Debugging ist es essenziell, den Einfluss aller nicht-standardmäßigen Plugins und Apps auszuschließen. Shopware bietet dafür eine effiziente Möglichkeit, alle Erweiterungen per SQL-Befehl oder Kommandozeile temporär zu deaktivieren und später wieder zu aktivieren – ohne mühsames Klicken im Backend.

11.1 Plugins und Apps per SQL-Query deaktivieren

Die Shopware 6 Datenbank speichert alle installierten Plugins und Apps in den Tabellen plugin und app. Mit den folgenden Schritten kannst du alle nicht von Shopware stammenden Erweiterungen auf einmal deaktivieren und später wiederherstellen. Das ist besonders hilfreich, um Fehlerquellen schnell einzugrenzen.

Backup der aktuellen Plugin- und App-Zustände anlegen:

CREATE TABLE plugin_tmp LIKE plugin;
INSERT INTO plugin_tmp SELECT * FROM plugin;
CREATE TABLE app_tmp LIKE app;
INSERT INTO app_tmp SELECT * FROM app;

Alle nicht-standardmäßigen Plugins deaktivieren:

UPDATE plugin SET active = 0 WHERE (author <> 'shopware AG' AND author <> 'Shopware') OR (author IS NULL);

Alle Apps deaktivieren:
```
UPDATE app SET active = 0;
```

Ursprünglichen Zustand wiederherstellen:

UPDATE plugin AS p JOIN plugin_tmp AS pt ON p.id = pt.id SET p.active = pt.active;
UPDATE app AS a JOIN app_tmp AS at ON a.id = at.id SET a.active = at.active;

Temporäre Sicherungstabellen löschen:

DROP TABLE plugin_tmp;
DROP TABLE app_tmp;

Wichtiger Hinweis: Wenn du ein eigenes Theme verwendest, das als Plugin eingebunden ist, stelle sicher, dass es keinem Verkaufskanal zugewiesen ist, bevor du es deaktivierst. Sonst kann es zu Problemen beim Aufruf der Verkaufskanäle kommen.

Diese Methode ist besonders bei Shops mit vielen Erweiterungen extrem zeitsparend und hilft, Fehlerquellen systematisch auszuschließen.

Quelle: Shopware Doku: SQL Tipps & Tricks

11.2 Plugins per CLI schnell aktivieren und deaktivieren

Alternativ kannst du Plugins auch per Kommandozeile (CLI) verwalten. Das ist besonders praktisch, wenn du gezielt einzelne Plugins oder Gruppen von Plugins aktivieren oder deaktivieren möchtest, ohne direkt auf die Datenbank zuzugreifen.

php bin/console plugin:list – Zeigt alle installierten Plugins und deren Status.
php bin/console plugin:deactivate PluginName1 PluginName2 – Deaktiviert gezielt einzelne Plugins.
php bin/console plugin:activate PluginName1 PluginName2 – Aktiviert gezielt einzelne Plugins.

Die Namen der Plugins findest du entweder über das CLI-Listing oder direkt in der Datenbank-Tabelle plugin (Spalte name). Für viele Plugins empfiehlt es sich, die Namen vorab als Liste vorzubereiten und in einem Befehl zu übergeben, um Zeit zu sparen.

Tipp: Speichere dir häufig genutzte Plugin-Listen für wiederkehrende Debugging-Sessions.

Best Practice: Nach jedem größeren Update oder vor dem Livegang empfiehlt es sich, alle Drittanbieter-Plugins einmal zu deaktivieren und den Shop zu testen, um Konflikte frühzeitig zu erkennen.

Weitere Details und Schritt-für-Schritt-Anleitungen:
Shopware Doku: SQL Tipps & Tricks

Zurück zur Übersicht

12. Debugging-Checklisten & FAQ

Je nachdem, wer du bist und was für ein Problem vorliegt, sieht der Debugging-Prozess anders aus. Hier findest du drei praxiserprobte Checklisten – vom schnellen Fix bis zum Deep Dive.

Wie behebe ich Shopware 6 Fehler als Shopbetreiber ohne Programmierkenntnisse?

Kein Terminal, kein Code – diese 5 Schritte lösen die häufigsten Probleme:

Cache leeren – Gehe zu Einstellungen > System > Caches und klicke auf „Alle Caches leeren“.
Theme neu kompilieren – Gehe zu Inhalte > Themes > wähle dein Theme > klicke auf Speichern.
Verkaufskanal prüfen – Ist der Verkaufskanal aktiv? Ist die richtige Domain zugewiesen?
Plugins einzeln deaktivieren – Unter Erweiterungen > Meine Erweiterungen kannst du Plugins einzeln deaktivieren, um den Übeltäter zu finden.
Entwickler kontaktieren – Wenn nichts hilft, wende dich an deine Agentur oder einen Shopware-Experten.

Wie debugge ich Theme- und Frontend-Fehler in Shopware 6?

Für alle, die mit Twig, CSS und JavaScript arbeiten:

Browser Developer Tools öffnen (F12) – Console auf JavaScript-Fehler prüfen.
Developer-Modus aktivieren – APP_ENV=dev in der .env.local setzen.
Symfony Toolbar checken – Unter „Templates“ siehst du alle geladenen Twig-Dateien und deren Variablen.
Template-Vererbung prüfen – Wird der richtige Block überschrieben? Stimmt der Pfad?
Assets neu kompilieren – bin/console theme:compile ausführen und Cache leeren.
Netzwerk-Tab prüfen – Werden CSS/JS-Dateien geladen? Gibt es 404-Fehler?
Storefront-Watcher nutzen – Für Live-Reload bei Änderungen: bin/watch-storefront.sh

Wie debugge ich Backend- und Plugin-Fehler in Shopware 6?

Für PHP-Entwickler, die tief ins System eintauchen:

Developer-Modus aktivieren + Cache killen – bin/console cache:clear && rm -rf var/cache/*
Logs live beobachten – tail -f var/log/dev.log im Terminal laufen lassen.
Symfony Toolbar nutzen – Doctrine (SQL-Queries), Events (ausgelöste Events), Routing (welcher Controller?).
Xdebug einrichten – Breakpoints setzen für Step-by-Step-Debugging in PhpStorm oder VS Code.
Plugin-Status prüfen – bin/console plugin:list zeigt alle Plugins und deren Status.
Doctrine-Queries analysieren – Verdächtige Queries mit EXPLAIN in der Datenbank prüfen.
Statische Code-Analyse – PHPStan oder Psalm laufen lassen, um Typ-Fehler zu finden.
Event-Subscriber debuggen – Werden deine Events überhaupt getriggert? Toolbar > Events checken.

Welcher Fehler tritt auf und wo fange ich an?

Beantworte diese Fragen, um den Fehler systematisch einzugrenzen:

Was genau passiert? – Weiße Seite, Fehlermeldung, falsches Verhalten?
Wo tritt der Fehler auf? – Frontend, Backend, API, Checkout, bestimmte Seite?
Wann hat es angefangen? – Nach einem Update, Plugin-Installation, Code-Änderung?
Ist der Fehler reproduzierbar? – Immer, manchmal, nur bei bestimmten Usern/Produkten?
Was sagen die Logs? – Schau in var/log/dev.log oder prod.log.

Wann sollte ich den Developer-Modus NICHT aktivieren?

Der Developer-Modus sollte niemals auf einem Live-System aktiviert werden, weil:

Sensible Daten (Pfade, Konfiguration, SQL-Queries) werden öffentlich sichtbar.
Die Performance sinkt drastisch, da Caching deaktiviert wird.
Die dev.log-Datei wächst schnell auf mehrere Gigabyte an.

Nutze den Developer-Modus nur auf lokalen Systemen oder passwortgeschützten Staging-Umgebungen.

Allgemeine Best Practices

Debug-Modus nur gezielt und zeitlich begrenzt aktivieren.
Logs regelmäßig prüfen und dokumentieren.
Eigene Fehler- und Debug-Logs für individuelle Plugins anlegen.
Fehler reproduzierbar machen: Zeitpunkt, User, Aktion notieren.
Bei komplexen Problemen auch Server- und PHP-Logs einbeziehen.
Code-Reviews und Pair Programming zur Fehlerprävention nutzen.
Automatisierte Tests (Unit, Integration, E2E) etablieren.
Regelmäßige Updates von Shopware, Plugins und Themes durchführen.

Typische Fehlerquellen und ihre Lösung

Fehlende oder fehlerhafte Plugins: Deaktiviere Plugins einzeln, um den Übeltäter zu finden.
Cache-Probleme: Cache leeren mit bin/console cache:clear && rm -rf var/cache/*
Datenbankfehler: Symfony Toolbar > Doctrine prüfen, dann EXPLAIN nutzen.
Fehlende Berechtigungen: Dateirechte prüfen: var/ und public/ müssen beschreibbar sein.
API-Probleme: Authentifizierung, Datenstruktur und Statuscodes prüfen.
Theme-Probleme: Twig-Syntax, Block-Vererbung und Asset-Pfade kontrollieren.

Zurück zur Übersicht

13. Fazit: Shopware 6 Debugging erfolgreich meistern

Mit den richtigen Tools und Methoden wird Shopware 6 Debugging zur Routine. Nutze den Debug-Modus gezielt, kontrolliere Logs regelmäßig und setze auf bewährte Plugins wie FroshProfiler. Analysiere SQL-Queries, prüfe API-Requests und optimiere Performance-Bottlenecks. So findest du Fehler schnell und kannst deinen Shop stabil und performant betreiben. Debugging ist ein kontinuierlicher Prozess – mit System, Know-how und den passenden Werkzeugen vermeidest du die meisten Probleme schon im Vorfeld.

Zurück zur Übersicht