Plugin-Konflikte in WordPress finden: systematische Fehlersuche ohne Ausfall

Ein Kontaktformular sendet plötzlich nicht mehr, ein Shortcode zeigt den falschen Inhalt oder ein Button im Editor reagiert nicht. Es gibt keine Fehlermeldung, die Website läuft sonst normal. Solche Fehler entstehen oft nicht durch ein einzelnes defektes Plugin, sondern durch zwei Plugins, die sich in die Quere kommen, oder durch ein Plugin, das nicht zum Theme passt. Diese Anleitung zeigt eine systematische Fehlersuche, mit der Sie den Verursacher sicher finden, ohne die Live-Website für Besucher abzuschalten. Den Weg über den Troubleshooting-Modus und über WP-CLI haben wir im Labor mit WordPress 7.1.2 und zwei absichtlich kollidierenden Test-Plugins durchgespielt.

Voraussetzungen

• WordPress: aktuelle Version, hier 7.1.2.
• PHP: mindestens 7.4 laut WordPress-API, empfohlen ist eine aktuelle, unterstützte Version wie PHP 8.4.
• Rolle: Administrator, denn nur diese Rolle darf Plugins aktivieren und deaktivieren.
• Zugriff: das Backend genügt für den Troubleshooting-Modus. Für den WP-CLI-Weg brauchen Sie SSH, als Notfallzugang FTP.
• Testumgebung: idealerweise eine Staging-Kopie der Website. Ohne Staging nutzen Sie den Troubleshooting-Modus, der Besucher nicht beeinflusst.
• Backup: eine aktuelle Sicherung von Dateien und Datenbank vor jeder Fehlersuche. Beim Deaktivieren löschen manche Plugins Daten oder Einstellungen, das hängt vom Plugin ab.

Schritt 1: Fehler reproduzierbar beschreiben

Eine Fehlersuche ohne sauberen Prüftest endet in Rätselraten. Beschreiben Sie den Fehler so, dass Sie nach jeder Änderung in einer Minute prüfen können, ob er noch da ist:

• Wo: welche Seite, welcher Bereich im Backend, welcher Block im Editor
• Was: was genau passiert und was erwartet wird, etwa „Seite /kontakt/ zeigt Button statt Formular“
• Wer: nur angemeldet, nur Besucher, nur eine bestimmte Rolle
• Womit: alle Browser oder nur einer, Desktop oder Mobilgerät
• Seit wann: welches Update, welches neue Plugin, welche Einstellung ging dem Fehler voraus

Die letzte Frage ist oft die wertvollste. Viele Konflikte zeigen sich direkt nach einem Update. Ein Blick in die Änderungsprotokolle oder in ein Aktivitätsprotokoll grenzt den Zeitraum ein. Prüfen Sie außerdem, ob der Fehler auch in einem privaten Browserfenster auftritt. So schließen Sie den Browser-Cache aus. Leeren Sie auch den Cache eines Caching-Plugins oder des Hosters, sonst testen Sie womöglich eine alte Version der Seite.

Verifizieren: Sie haben eine Prüfanweisung in einem Satz, die das Problem zuverlässig zeigt, und kennen den ungefähren Zeitpunkt, seit dem es auftritt.

Schritt 2: Hinweise sammeln, bevor Sie etwas abschalten

Konflikte ohne sichtbare Fehlermeldung hinterlassen oft trotzdem Spuren. Zwei Quellen lohnen sich vor jeder Abschaltrunde:

Browser-Konsole: Viele Konflikte im Frontend und im Editor sind JavaScript-Fehler. Öffnen Sie mit F12 die Entwicklerwerkzeuge und wechseln Sie zur Konsole. Laden Sie die Seite neu und lösen Sie den Fehler aus. Rote Meldungen nennen meist eine Datei, deren Pfad unter wp-content/plugins/NAME/ den Plugin-Namen verrät. Das ist nicht zwingend der Verursacher, aber ein Startpunkt.

PHP-Protokoll: Aktivieren Sie auf der Staging-Kopie die Fehlerprotokollierung in der wp-config.php, oberhalb der Zeile „That’s all, stop editing!“:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WordPress schreibt Warnungen und Hinweise dann in wp-content/debug.log, ohne sie Besuchern anzuzeigen. Die Konstanten sind in der Debugging-Dokumentation von WordPress beschrieben. Auf der Live-Website sollten Sie das Protokoll nur kurz einschalten, weil die Datei öffentlich abrufbar sein kann und schnell wächst.

Verifizieren: Sie haben entweder eine konkrete Fehlermeldung mit Dateipfad oder wissen sicher, dass Konsole und Protokoll beim Auslösen des Fehlers nichts melden.

Schritt 3: Troubleshooting-Modus einschalten

Der klassische Rat „Alle Plugins deaktivieren und auf ein Standard-Theme wechseln“ trifft auf der Live-Website alle Besucher. Das Plugin Health Check & Troubleshooting vom WordPress-Support-Team umgeht das: Im Troubleshooting-Modus erscheinen alle Plugins nur für Ihre eigene Sitzung als deaktiviert und ein Standard-Theme ist aktiv. Alle anderen sehen die Website unverändert.

Installieren Sie das Plugin unter „Plugins > Plugin hinzufügen“. Unter „Werkzeuge > Website-Zustand“ erscheint ein zusätzlicher Reiter „Troubleshooting“ mit dem Button „Enable Troubleshooting Mode“. Das Plugin ist in Teilen nicht übersetzt, im Labor waren diese Beschriftungen englisch. Beim Einschalten legt es ein Must-Use-Plugin an und setzt ein Cookie im Browser. Im Labor sahen wir danach als Administrator die Seite /kontakt/ mit dem Theme Twenty Twenty-Four und ohne Plugin-Ausgabe, während ein nicht angemeldeter Besucher gleichzeitig die unveränderte Seite erhielt.

Ein ehrlicher Hinweis: Laut Plugin-Seite auf wordpress.org (Stand September 2026) liegt das letzte Update in Version 1.7.1 etwa zwei Jahre zurück, getestet ist es bis WordPress 6.6.9. Im Labor funktionierte der Troubleshooting-Modus mit WordPress 7.1.2 dennoch. Die Plugin-Seite selbst kündigt an, den Modus künftig als eigenes Plugin anzubieten. Must-Use-Plugins schaltet der Modus nicht ab, das steht auch auf der Troubleshooting-Seite.

Verifizieren: Die Werkzeugleiste oben zeigt den Menüpunkt „Troubleshooting Mode“. Tritt der Fehler jetzt nicht mehr auf, liegt er an einem Plugin oder am Theme. Bleibt er, liegt die Ursache woanders, etwa im Server, in einem Must-Use-Plugin oder im Core.

Schritt 4: Verursacher durch Halbieren eingrenzen

Bei 20 Plugins bedeutet einzelnes Durchschalten im ungünstigsten Fall 20 Prüfrunden. Halbieren braucht höchstens fünf: Sie aktivieren die Hälfte der Plugins und prüfen. Tritt der Fehler auf, steckt der Verursacher in dieser Hälfte. Wenn nicht, in der anderen. Dann halbieren Sie die verdächtige Gruppe erneut.

Bei einem Konflikt zwischen zwei Plugins gibt es eine Besonderheit: Der Fehler tritt nur auf, wenn beide aktiv sind. Findet sich in keiner Hälfte allein ein Fehler, liegen die beiden Beteiligten in verschiedenen Hälften. Halten Sie dann eine Hälfte komplett aktiv und halbieren Sie die andere weiter, bis Sie den ersten Beteiligten gefunden haben. Anschließend verfahren Sie umgekehrt.

Im Troubleshooting-Modus aktivieren Sie Plugins über das Menü „Troubleshooting Mode > Plugins“ in der Werkzeugleiste. Im Labor waren zwei Test-Plugins aktiv, die beide den Shortcode [kontakt] registrierten. Besucher sahen „Button Beta“ statt des Formulars. Mit nur „Test Alpha Kontakt“ im Troubleshooting-Modus erschien das Formular korrekt, sobald zusätzlich „Test Beta Buttons“ aktiv war, kam der Fehler zurück. Damit war das Paar eindeutig bestimmt, ohne dass Besucher etwas davon bemerkten.

Denken Sie an das Theme: Tritt der Fehler erst mit Ihrem eigentlichen Theme auf, wechseln Sie unter „Troubleshooting Mode > Themes“ zurück und prüfen Sie Plugins in Kombination mit diesem Theme.

Verifizieren: Sie können den Fehler gezielt ein- und ausschalten, indem Sie genau ein Plugin oder das Theme hinzunehmen oder weglassen.

Schritt 5: Mit WP-CLI ohne Änderungen testen

Haben Sie SSH-Zugang, prüfen Sie viele Konflikte, ohne überhaupt ein Plugin zu deaktivieren. Der globale Parameter --skip-plugins lädt die genannten Plugins für genau diesen einen WP-CLI-Aufruf nicht. Die Website bleibt für alle anderen unverändert. Im Labor zeigte der Test des Shortcodes das Konfliktpaar so:

wp eval 'echo do_shortcode("[kontakt]");'
# <p class=beta>Button Beta</p>
wp eval 'echo do_shortcode("[kontakt]");' --skip-plugins=test-beta
# <p class=alpha>Kontaktformular Alpha</p>

Das funktioniert für alles, was sich in PHP abfragen lässt: Shortcodes, Filter, Cron-Aufgaben, REST-Antworten. Für Darstellungsfehler im Browser und JavaScript-Konflikte brauchen Sie den Troubleshooting-Modus oder eine Staging-Kopie.

Müssen Sie auf der Staging-Kopie doch alle Plugins abschalten, sichern Sie vorher die Liste der aktiven Plugins, damit Sie den Ausgangszustand exakt wiederherstellen können:

wp plugin list --status=active --field=name > aktive-plugins.txt
wp plugin deactivate --all
wp plugin activate $(cat aktive-plugins.txt)

Im Labor meldete wp plugin deactivate --all „Success: Deactivated 5 of 7 plugins.“ und die dritte Zeile stellte alle fünf wieder her. Nutzen Sie diesen Weg nicht auf der Live-Website.

Verifizieren: wp plugin list --status=active zeigt nach der Wiederherstellung dieselben Plugins wie in aktive-plugins.txt.

Schritt 6: Konflikt lösen und dokumentieren

Mit dem gefundenen Paar haben Sie mehrere Möglichkeiten, in dieser Reihenfolge:

1. Updates prüfen: Oft ist der Konflikt bereits bekannt und in einer neueren Version behoben. Lesen Sie die Änderungsprotokolle beider Plugins.
2. Einstellungen prüfen: Viele Plugins bieten Optionen, eigene Funktionen abzuschalten, etwa eigene Shortcodes, Skript-Optimierung oder Lazy Loading. Doppelte Funktionen sind eine häufige Konfliktquelle.
3. Entwickler informieren: Schreiben Sie im Support-Forum der Plugins auf wordpress.org oder beim Hersteller. Nennen Sie Ihre Prüfanweisung aus Schritt 1, die Versionen von WordPress, PHP und beiden Plugins und das Ergebnis Ihres Tests.
4. Ersetzen: Braucht eines der Plugins nur eine Nebenfunktion, ist ein Ersatz oft der sauberste Weg.

Beenden Sie den Troubleshooting-Modus über „Troubleshooting Mode > Disable Troubleshooting Mode“ und deaktivieren Sie das Plugin danach, wenn Sie es nicht regelmäßig brauchen. Schalten Sie WP_DEBUG wieder aus und löschen Sie die debug.log. Notieren Sie das Konfliktpaar in Ihrer Website-Dokumentation, damit bei künftigen Updates beide gezielt geprüft werden.

Genau diese Prüfung nach Updates ist der Teil, der im Alltag gern liegen bleibt. Wer sie nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher.

Verifizieren: Der Fehler tritt mit Ihrer normalen Plugin-Auswahl nicht mehr auf, der Troubleshooting-Modus ist beendet und wp-content/debug.log existiert nicht mehr.

Typische Fehler

• Fehler verschwindet im Troubleshooting-Modus nicht: Ursache liegt außerhalb der normalen Plugins. Prüfen Sie Must-Use-Plugins unter „Plugins > Must-Use“, den Server-Cache und die Serverkonfiguration.
• Nach dem Test ist der Fehler sofort wieder da, obwohl nichts geändert wurde: Sie sehen eine zwischengespeicherte Seite. Leeren Sie den Cache von Plugin, Hoster und Browser vor jeder Prüfung.
• Im Troubleshooting-Modus festgesteckt: Laut Plugin-Seite genügt es, die Cookies der Website zu löschen oder alle Browserfenster zu schließen. Im Labor zeigte die Seite ohne das Cookie wp-health-check-disable-plugins wieder den Normalzustand.
• Einstellungen nach dem Deaktivieren verloren: Manche Plugins löschen beim Deaktivieren oder Löschen Daten. Deshalb vorher sichern und auf Staging testen.
• Nur ein Beteiligter gefunden: Beim Halbieren wurde übersehen, dass ein Konflikt zwei Plugins braucht. Vorgehen aus Schritt 4 für Paare anwenden.

Häufige Fragen

Kann ich einfach alle Plugins auf der Live-Website deaktivieren?

Technisch ja, aber Formulare, Shop und Sicherheitsfunktionen fallen dann für alle Besucher aus. Der Troubleshooting-Modus oder eine Staging-Kopie vermeiden das.

Wie unterscheide ich einen Konflikt von einem Fehler in einem einzelnen Plugin?

Tritt der Fehler auch auf, wenn nur ein einziges Plugin mit einem Standard-Theme aktiv ist, liegt er in diesem Plugin. Braucht er zwei Beteiligte, ist es ein Konflikt.

Was ist, wenn die Website gar nicht mehr lädt?

Dann handelt es sich meist um einen PHP-Fehler. Der Weg dafür ist ein anderer, siehe Kritischer Fehler in WordPress: Wiederherstellungsmodus nutzen.

Hilft der Troubleshooting-Modus auch bei Performance-Problemen?

Nur grob. Für langsame Plugins liefert Query Monitor genauere Messwerte, siehe Langsame Plugins finden mit Query Monitor.

Testumfang

Im Labor mit WordPress 7.1.2 (deutsch), PHP 8.4.26, WP-CLI 2.12.0 und Health Check & Troubleshooting 1.7.1 durchgespielt: zwei Test-Plugins mit kollidierendem Shortcode, Troubleshooting-Modus mit Must-Use-Plugin und Cookie, unterschiedliche Ausgabe für Administrator und Besucher, schrittweises Aktivieren einzelner Plugins im Modus, Rückkehr zum Normalzustand ohne Cookie, --skip-plugins für einzelne Plugins, Sichern und Wiederherstellen der aktiven Plugins per Liste. Nicht getestet: JavaScript-Konflikte im Browser, Konflikte mit kommerziellen Plugins und Page-Buildern.

Fazit

Plugin-Konflikte wirken rätselhaft, lassen sich aber mit Methode schnell finden: Fehler reproduzierbar beschreiben, Hinweise aus Konsole und Protokoll sammeln, im Troubleshooting-Modus oder auf Staging halbieren statt einzeln durchschalten und Verdächtige per WP-CLI ohne Eingriff prüfen. So bleibt die Website für Besucher die ganze Zeit nutzbar. Wer die regelmäßigen Updates mit Kompatibilitätsprüfung abgeben möchte, findet sie bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Kritischer Fehler in WordPress: Wiederherstellungsmodus nutzen
• Langsame Plugins finden mit Query Monitor
• Staging-Umgebung für WordPress einrichten
• Health Check & Troubleshooting auf wordpress.org
• WordPress-Dokumentation: Debugging in WordPress
• WP-CLI-Handbuch: globale Parameter wie --skip-plugins
• WP-CLI: wp plugin deactivate