Veraltete und aufgegebene WordPress-Plugins erkennen und ersetzen

Viele Unternehmenswebsites laufen mit Plugins, die jemand vor Jahren installiert hat und die seitdem niemand mehr angesehen hat. Ein Teil davon wird vom Entwickler nicht mehr gepflegt, manche wurden im Plugin-Verzeichnis von wordpress.org sogar wegen einer Sicherheitslücke geschlossen. WordPress meldet das im Backend nicht von selbst: Ein geschlossenes Plugin bekommt keine Updates mehr und fällt deshalb in der Update-Übersicht gerade nicht auf. Diese Anleitung zeigt, wie Sie veraltete und aufgegebene Plugins systematisch finden, das Risiko einschätzen und sie sauber durch eine gepflegte Alternative ersetzen.

Voraussetzungen

• WordPress 7.1 (getestet mit 7.1.2) auf PHP 8.x
• Benutzerkonto mit der Rolle Administrator
• Für die Befehle: SSH-Zugang mit WP-CLI 2.12.0 oder neuer; ohne SSH funktionieren alle Schritte auch über das Backend und die Plugin-Seiten auf wordpress.org
• Ein aktuelles Backup von Dateien und Datenbank, bevor Sie Plugins entfernen oder ersetzen
• Idealerweise eine Staging-Kopie der Website zum Testen des Ersatz-Plugins
• Etwa eine Stunde für die erste Bestandsaufnahme, danach wenige Minuten pro Monat

Schritt 1: Bestandsaufnahme aller Plugins

Beginnen Sie mit einer vollständigen Liste, auch der inaktiven Plugins. Inaktive Plugins werden zwar nicht geladen, ihre Dateien liegen aber weiter auf dem Server und sind damit direkt aufrufbar. Der Website-Zustand von WordPress stuft sie deshalb als Risiko ein. Im Test lautete die Meldung unter Werkzeuge → Website-Zustand: „Inaktive Plugins sollten entfernt werden“ mit dem Zusatz, inaktive Plugins seien „verlockende Ziele für Angreifer“.

Im Backend finden Sie die Liste unter Plugins → Installierte Plugins. Auf der Kommandozeile liefert WP-CLI mehr Informationen auf einmal:

wp plugin list --fields=name,status,version,update_version,wporg_status,tested_up_to,requires_php

Die Ausgabe im Labor mit einigen Testkandidaten:

name            status    version  update_version  wporg_status  tested_up_to  requires_php
akismet         inactive  5.7.2                    active        7.1           7.2
classic-editor  inactive  1.6.3    1.7.0           active        6.2           5.2.4
wp-db-backup    active    2.5.3                    active        6.9
hello           inactive  1.7.2                    closed
hello-dolly     active    1.7.2                    active        6.9

Die Spalte tested_up_to stammt aus dem Kopf der installierten Plugin-Version. Das erklärt den Wert 6.2 bei classic-editor: Installiert war die ältere Version 1.6.3, die aktuelle Version 1.7.0 ist laut wordpress.org bis WordPress 7.0.6 getestet. Werten Sie diese Spalte also erst aus, nachdem Sie verfügbare Updates eingespielt haben.

Speichern Sie die Liste als Datei. So sehen Sie beim nächsten Durchgang, was sich verändert hat:

wp plugin list --fields=name,version,wporg_status,tested_up_to --format=csv > plugins-$(date +%F).csv

Verifizieren: Die Anzahl der Zeilen entspricht der Anzahl unter Plugins → Installierte Plugins im Backend, und jede Zeile hat einen Wert in wporg_status.

Schritt 2: Status auf wordpress.org richtig lesen

WP-CLI fragt für wporg_status die Plugin-Schnittstelle von wordpress.org ab. Der Wert active heißt: Das Plugin ist im Verzeichnis verfügbar. Der Wert closed ist mehrdeutig, denn WP-CLI vergibt ihn in zwei Fällen:

• Das Plugin stand im Verzeichnis und wurde geschlossen.
• Das Plugin stand nie im Verzeichnis, etwa ein Premium-Plugin oder eine Eigenentwicklung. Im Test erhielt ein selbst angelegtes Plugin „Firma Eigenes“ ebenfalls closed, genauso das mit WordPress ausgelieferte „Hello Dolly“ im Ordner hello, das im Verzeichnis unter dem Namen hello-dolly geführt wird.

Öffnen Sie deshalb für jedes Plugin mit closed die Seite https://wordpress.org/plugins/NAME/. Bei einem geschlossenen Plugin steht dort ein Hinweis mit Datum und Grund. Das Beispiel „Display Widgets“ zeigt: „This plugin has been closed as of January 30, 2021 and is not available for download. This closure is permanent. Reason: Security Issue.“ Ein Installationsversuch per WP-CLI endet mit „Warning: display-widgets: closed“.

Die Gründe laut Plugin-Handbuch von wordpress.org reichen von der Bitte des Autors über Verstöße gegen die Richtlinien bis zu Sicherheitsproblemen. Details veröffentlicht das Team nicht. Eine Schließung heißt also nicht automatisch, dass eine Lücke besteht, aber in jedem Fall: Es kommen keine Updates mehr über WordPress.

Für Plugins, die nie auf wordpress.org lagen, prüfen Sie die Website des Herstellers: Gibt es ein Änderungsprotokoll mit Einträgen aus den letzten Monaten, und läuft Ihre Lizenz noch?

Verifizieren: Jedes Plugin mit closed ist einer von drei Gruppen zugeordnet: geschlossen (mit Grund), kommerziell mit aktivem Hersteller oder Eigenentwicklung mit bekanntem Verantwortlichen.

Schritt 3: Risiko bewerten und Reihenfolge festlegen

Nicht jedes ältere Plugin muss sofort weg. Die folgende Einteilung hilft bei der Reihenfolge:

Den Hinweis auf nicht getestete Plugins zeigt wordpress.org oben auf der Plugin-Seite, wenn ein Plugin die letzten drei Hauptversionen nicht unterstützt. Im Beispiel „WordPress Importer“ (Tested up to 6.8.10) lautete er: „This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported“. Laut Plugin-Handbuch beruht diese Warnung seit 2018 auf der Angabe „Tested up to“, nicht mehr auf dem Datum der letzten Aktualisierung. Das Beispiel zeigt auch die Grenze der Warnung: Das Plugin wurde laut Seite vor einem Monat aktualisiert, nur der Wert „Tested up to“ blieb alt. Sehen Sie sich deshalb zusätzlich „Last updated“ und die Antworten im Support-Forum des Plugins an.

Wichtig für Ihre Bewertung ist außerdem, was das Plugin tut. Ein aufgegebenes Plugin, das Formulare verarbeitet, Dateien hochlädt oder Benutzer verwaltet, ist kritischer als eines, das nur eine Schriftart einbindet.

Verifizieren: Sie haben eine kurze Liste mit Plugin, Befund, Funktion auf der Website und geplanter Handlung, sortiert nach Dringlichkeit.

Schritt 4: Ersatz auswählen

Bevor Sie einen Ersatz suchen, klären Sie, ob die Funktion überhaupt noch gebraucht wird. Manche Aufgaben erledigt WordPress inzwischen selbst, und jedes Plugin weniger ist eine Aktualisierung weniger.

Wird die Funktion gebraucht, prüfen Sie Kandidaten auf wordpress.org anhand der Angaben im Bereich „Meta“ der Plugin-Seite:

• Tested up to nahe an Ihrer WordPress-Version
• Last updated innerhalb der letzten Monate
• PHP version passend zu Ihrem Server
• Support-Forum: Werden Fragen beantwortet?
• Import-Funktion für Daten aus dem alten Plugin, falls das alte Plugin eigene Daten gespeichert hat

Dieselben Angaben liefert WP-CLI für ein noch nicht installiertes Plugin:

wp plugin search kontaktformular --fields=name,slug,version,tested,requires_php,last_updated,active_installs --per-page=5

Hohe Installationszahlen sind kein Qualitätsbeweis, zeigen aber, dass Fehler schnell auffallen. Wie Sie Änderungsprotokolle vor dem Einsatz lesen, beschreibt die Anleitung WordPress-Updates vor dem Einspielen prüfen.

Verifizieren: Für jedes zu ersetzende Plugin ist ein Kandidat notiert, dessen „Tested up to“ und PHP-Anforderung zu Ihrer Installation passen.

Schritt 5: Wechsel auf der Staging-Kopie testen

Der Wechsel eines Plugins verändert oft Inhalte: Shortcodes des alten Plugins erscheinen nach dem Entfernen als Klartext auf der Seite, Formulare verschwinden, Weiterleitungen fehlen. Testen Sie deshalb zuerst auf einer Kopie. Wie Sie eine Staging-Umgebung aufbauen, zeigt die Anleitung Staging-Umgebung für WordPress einrichten.

Suchen Sie vor dem Entfernen, wo das alte Plugin in Inhalten verwendet wird. Die Shortcode-Namen stehen in der Dokumentation des Plugins. Als Beispiel mit einem Shortcode [alt_formular]:

wp post list --post_type=page,post --s='[alt_formular' --fields=ID,post_title,post_type

Installieren Sie dann auf der Kopie das neue Plugin, übertragen Sie die Einstellungen und ersetzen Sie die Einbindungen in den betroffenen Seiten. Erst danach deaktivieren Sie das alte Plugin und prüfen jede gefundene Seite.

Verifizieren: Auf der Staging-Kopie funktioniert die Funktion mit dem neuen Plugin, die Suche nach dem alten Shortcode liefert keine Treffer mehr, und nach dem Deaktivieren des alten Plugins erscheinen keine Fehler im Debug-Log.

Schritt 6: Altes Plugin auf der Live-Website entfernen

Legen Sie direkt vor dem Eingriff ein Backup an. Die Datenbank sichern Sie per WP-CLI mit einem Befehl, die Dateien über Ihr Backup-Werkzeug oder den Hoster:

wp db export vor-plugin-wechsel.sql

WP-CLI bestätigt mit „Success: Exported to …“. Wiederholen Sie dann die auf der Kopie getesteten Schritte. Für das Entfernen gibt es zwei Befehle mit unterschiedlicher Wirkung:

• wp plugin delete NAME löscht nur die Dateien. Einträge des Plugins in der Datenbank, etwa Optionen und eigene Tabellen, bleiben erhalten.
• wp plugin uninstall NAME führt zusätzlich die Deinstallationsroutine des Plugins aus, die dessen Daten aufräumt, sofern der Entwickler eine vorgesehen hat. Das entspricht dem Löschen im Backend.

Ein aktives Plugin lässt sich nicht direkt deinstallieren. Im Test brach WP-CLI mit „Warning: The 'wp-db-backup' plugin is active.“ und „Error: No plugins uninstalled.“ ab. Mit der Option --deactivate gelingt es in einem Schritt:

wp plugin uninstall wp-db-backup --deactivate

Deactivating 'wp-db-backup'...
Plugin 'wp-db-backup' deactivated.
Uninstalled and deleted 'wp-db-backup' plugin.
Success: Uninstalled 1 of 1 plugins.

Die Deinstallation löscht Daten endgültig. Behalten Sie das Backup mindestens so lange, bis Sie sicher sind, dass keine Einstellungen oder Inhalte des alten Plugins mehr gebraucht werden. Im Backend erreichen Sie dasselbe unter Plugins → Installierte Plugins mit „Deaktivieren“ und anschließend „Löschen“.

Verifizieren: wp plugin list führt das alte Plugin nicht mehr auf, die betroffenen Seiten funktionieren, und unter Werkzeuge → Website-Zustand verschwindet der Hinweis auf inaktive Plugins, sobald keine mehr vorhanden sind.

Schritt 7: Prüfung regelmäßig wiederholen

Plugins werden laufend geschlossen oder aufgegeben, eine einmalige Bereinigung reicht deshalb nicht. Wiederholen Sie Schritt 1 und 2 monatlich und vergleichen Sie die Ergebnisse mit der gespeicherten Liste. Auf Servern mit SSH lässt sich die Abfrage per Cronjob automatisieren; die Ausgabe schicken Sie an eine Adresse, die jemand liest.

Diese Kontrolle gehört zu den Aufgaben, die bei laufender Pflege einer Website jede Woche oder jeden Monat anstehen, zusammen mit Updates und Backups. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Wartung der Firewall.

Verifizieren: Im Kalender oder Ticketsystem steht ein wiederkehrender Termin für die Plugin-Prüfung, und die gespeicherten CSV-Dateien zeigen die Entwicklung über die Monate.

Typische Fehler

Häufige Fragen

Zeigt WordPress im Backend an, dass ein Plugin geschlossen wurde?

In WordPress 7.1.2 nicht. Die Liste unter Plugins → Installierte Plugins zeigt verfügbare Updates, aber keinen Hinweis auf Schließungen. Die Information finden Sie nur auf wordpress.org oder über wp plugin list --fields=name,wporg_status.

Reicht es, ein unsicheres Plugin nur zu deaktivieren?

Nein. Die Dateien bleiben auf dem Server und können direkt aufgerufen werden. Entfernen Sie Plugins, die Sie nicht mehr brauchen, vollständig.

Kann ich ein geschlossenes Plugin selbst weiterpflegen?

Technisch ja, bei freien Plugins unter GPL auch rechtlich. Sie übernehmen damit aber die Verantwortung für Sicherheitskorrekturen. Für kleine Unternehmen ist ein gepflegter Ersatz fast immer die bessere Wahl.

Testumfang

Wir haben alles in einer lokalen Testinstallation mit WordPress 7.1.2 durchgespielt. Im Mittelpunkt stand wp plugin list, mit dem wir geschlossene, nie gelistete und veraltete Plugins geprüft haben. Auch das Löschen und Deinstallieren von Plugins sowie die Datenbanksicherung haben wir ausprobiert.

Nicht getestet haben wir den Umzug von Daten zwischen konkreten Plugins. Probieren Sie einen solchen Wechsel daher zuerst auf einer Kopie Ihrer Website aus.

Fazit

Aufgegebene Plugins fallen nicht von selbst auf, weil sie keine Updates mehr melden. Eine Liste mit wporg_status und tested_up_to, ergänzt um einen Blick auf die Plugin-Seiten, macht sie in wenigen Minuten sichtbar. Ersetzen Sie Plugins mit Sicherheitsbefund sofort, testen Sie den Wechsel auf einer Kopie und entfernen Sie Überflüssiges vollständig. Wenn Sie die regelmäßige Kontrolle und die Updates in feste Hände geben möchten, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Updates vor dem Einspielen prüfen: Changelogs lesen und Risiken einschätzen
• Staging-Umgebung für WordPress einrichten
• WordPress-Updates per WP-CLI
• WP-CLI-Handbuch: wp plugin list
• WP-CLI-Handbuch: wp plugin uninstall
• Plugin-Handbuch: Alerts and Warnings