OSTRELLE · WEBSITES MIT KLAREM BLICK
WordPress-Plugin nicht mehr gepflegt: erkennen, ersetzen, absichern
WordPress Plugin nicht mehr gepflegt oder geschlossen? So erkennst du verwaiste Plugins, wählst Ersatz oder Entfernen und testest sicher auf Staging.
Autor: Ostrelle-Projektredaktion · Stand: 30. Oktober 2026. Herausgeber ist das Ostrelle-Projekt (Burak Basci), das ein eigenes CMS entwickelt. Dieser quellenbasierte Ratgeber ist keine unabhängige Produktempfehlung und kein eigener Vergleichstest.
Ein Plugin, das niemand mehr pflegt, fällt meist erst auf, wenn etwas kaputtgeht. Dieser Ratgeber zeigt, woran du verwaiste und geschlossene Plugins erkennst, wie du entscheidest, was damit passiert, und wie du Änderungen mit Sicherung, Staging-Test und Rückweg absicherst. Er stützt sich auf die Dokumentation von WordPress.org; Zahlen zu Angriffsstatistiken nennen wir nicht, weil wir keine Primärquelle ausgewertet haben.
1. Woran du ein verwaistes Plugin erkennst
Auf der Plugin-Seite im Verzeichnis von WordPress.org zeigt WordPress einen Warnhinweis, wenn ein Plugin lange nicht aktualisiert wurde. In einem Beitrag des WordPress-Supportteams von 2013 ist der Wortlaut beschrieben: Das Plugin „may no longer be maintained or supported and may have compatibility issues“. Ein Teammitglied erklärt dort, die Warnung solle bewusst abschrecken, weil ein Plugin ohne Kompatibilitätsupdate über zwei Jahre nicht verlässlich sei. Beachte das „may“: Der Hinweis ist ein Warnsignal, kein Nachweis einer Sicherheitslücke. Quelle: make.wordpress.org/support, Dezember 2013.
Prüfe zusätzlich selbst, was die Plugin-Seite und dein Dashboard hergeben:
- Wann gab es das letzte Update, und passt der Changelog zu aktuellen WordPress- und PHP-Versionen?
- Ist die Seite als geschlossen markiert, oder lässt sich das Plugin nicht mehr über das Dashboard installieren?
- Beantwortet der Entwickler noch Fragen, oder bleiben Supportanfragen unbeantwortet? (Das ist unsere Einordnung, keine offizielle Regel.)
- Zeigt Site Health oder die Plugin-Liste Fehler, Warnungen oder Hinweise zu veralteten PHP-Funktionen?
2. Was „geschlossen“ im Plugin-Verzeichnis bedeutet
Laut FAQ für Plugin-Entwickler werden Plugins wegen Richtlinienverstößen, Sicherheitsproblemen oder auf Wunsch des Autors geschlossen. Eine geschlossene Seite ist sichtbar markiert, es werden keine ZIP-Dateien mehr erzeugt, und Downloads sowie Installationen über das Dashboard sind nicht mehr möglich. Das SVN-Repository bleibt zugänglich. Nach 60 Tagen nennt die Meldung den Grund allgemein, etwa „Author Request“. Ohne Vorankündigung kann ein Plugin unter anderem geschlossen werden, wenn es über 6 Monate nie per SVN aktualisiert wurde, das SVN über 12 Monate defekt ist oder die Readme es als veraltet kennzeichnet. Quelle: Plugin Developer FAQ.
Bei Sicherheitsproblemen gilt: Die Verantwortung liegt beim Entwickler; ein Plugin mit Sicherheitsproblemen wird geschlossen, bis die Lage behoben ist. In extremen Fällen kann das WordPress-Sicherheitsteam das Plugin selbst aktualisieren. Das Verzeichnis darf Plugins außerdem aus Gründen entfernen, die nicht ausdrücklich in den Richtlinien stehen. Quelle: Detailed Plugin Guidelines.
Für dich heißt das: Ein bereits installiertes, geschlossenes Plugin läuft möglicherweise weiter, aber über das Verzeichnis ist dafür nichts Neues zu erwarten. Du trägst das Risiko dann selbst.
3. Das Risiko pro Plugin einschätzen
Nicht jedes verwaiste Plugin ist gleich gefährlich. Unsere Einordnung nach drei Fragen: Was kann das Plugin? Ein Plugin, das Formulareingaben speichert, Zahlungen abwickelt, Dateien hochlädt oder Benutzer verwaltet, verdient mehr Misstrauen als eines, das nur ein Icon ausgibt. Wie sichtbar ist es? Läuft es auf jeder Seite oder nur im Admin? Wie leicht ist es ersetzbar? Notiere für jedes betroffene Plugin die Funktion, die Seiten, auf denen sie vorkommt, und die Daten, die es speichert.
Diese Liste entscheidet über die Dringlichkeit. Ein verwaistes Formular-Plugin gehört zügig auf die Agenda, ein selten genutztes Hilfsplugin kann warten, solange du es im Blick behältst.
4. Die Entscheidungsliste: ersetzen, übernehmen, entfernen, auslagern
Zur Übernahme: FAQ, Abschnitt zum Übernehmen verwaister Plugins.
- Entfernen: Wird die Funktion nicht mehr gebraucht, ist Deaktivieren und Löschen die einfachste Lösung. Ein deaktiviertes Plugin bleibt als Datei auf dem Server, lösche es deshalb nach erfolgreichem Test.
- Ersetzen: Suche eine Alternative und prüfe deren Pflegestatus mit denselben Kriterien wie oben. Kläre vorher, ob sich Daten übernehmen lassen oder ob eine Migration nötig ist.
- Übernehmen oder forken: Das Plugin-Team erlaubt laut FAQ, Plugins zu übernehmen, die nicht mehr entwickelt werden. Der Weg: erst die ursprünglichen Entwickler kontaktieren, sonst das Plugin selbst instand setzen (Coding-Standards, Sicherheit) und das Team ansprechen. Eine Garantie gibt es nicht. Eigene Pflege lohnt nur, wenn jemand dauerhaft Sicherheitsverantwortung übernimmt; prüfe außerdem die Lizenz.
- Auslagern: Lässt sich die Funktion über einen externen Dienst oder eine kleine, gezielt geschriebene Erweiterung abdecken, sinkt die Abhängigkeit von einem großen Plugin. Dafür brauchst du jemanden, der den Code pflegt.
5. Sicherung und Staging-Test vor jeder Änderung
Die WordPress-Dokumentation nennt zwei Teile einer Sicherung: Datenbank und Dateien. Die Datenbank liegt außerhalb des WordPress-Verzeichnisses. Sie rät, die Datenbank regelmäßig und immer vor einem Update zu sichern, erst die Datenbank, dann die Dateien. Beim Wiederherstellen kommen zuerst die Dateien, dann die Datenbank. Automatische Backups sollte man gelegentlich manuell ergänzen, damit der Ablauf nachweislich funktioniert. Quelle: WordPress, Backups.
Probiere den Austausch auf einer Kopie der Website aus. WordPress kennt die Umgebungstypen local, development, staging und production; gesetzt werden sie über WP_ENVIRONMENT_TYPE, Standard ist production. Quelle: wp_get_environment_type(). Die Kopie sollte keine echten Mails, Bestellungen oder Zahlungen auslösen.
Teste dann in dieser Reihenfolge: die Seiten, auf denen das Plugin Inhalte ausgibt, die Funktion selbst (Formular absenden, Eintrag speichern), den Admin-Bereich und die Fehlerprotokolle. Schreibe auf, was du erwartet hast und was tatsächlich passiert ist.
6. Automatische Updates und Rollback: was sie leisten und was nicht
Laut WordPress-Dokumentation erhalten bestehende Installationen standardmäßig kleine Core-Updates. Neue Installationen ab WordPress 5.6 bekommen zusätzlich große Updates, sofern kein Versionskontroll-Checkout erkannt wird. Für Plugins und Themes laufen Hintergrund-Updates standardmäßig nur in Sonderfällen, die die WordPress.org-API bestimmt. Quelle: WordPress, Upgrading.
Seit WordPress 5.5 lassen sich automatische Updates im Admin für jedes Plugin und jedes Theme einzeln ein- oder ausschalten. Quelle: WordPress 5.5. WordPress 6.6 nennt Rollbacks bei fehlgeschlagenen automatischen Plugin-Updates. Quelle: WordPress 6.6. Im Merge-Vorschlag ist beschrieben: Nach einem Update prüft WordPress per Anfrage an die Startseite auf PHP-Fatal-Errors und stellt bei einem Fehler das vorherige Plugin wieder her; eine E-Mail geht an die Admin-Adresse. Quelle: Merge Proposal Rollback Auto-Update.
Zwei Grenzen folgen daraus. Erstens hilft ein automatisches Update nicht, wenn es für ein verwaistes Plugin gar keine neue Version gibt. Zweitens fängt dieser Mechanismus laut Beschreibung PHP-Fatal-Errors ab, nicht jede fachliche Störung, etwa ein Formular, das still nichts mehr sendet. Eine Sicherung vor dem Update und ein kurzer Funktionstest danach bleiben nötig.
7. Wo dieser Ratgeber endet
Alles oben gilt unabhängig vom eingesetzten System. Offenlegung: Der Herausgeber dieser Seite entwickelt das CMS Ostrelle. Ostrelle führt WordPress-Plugins nicht unverändert aus und ist heute kein Hosting-Angebot; ein WXR-/Gutenberg-Importer ist als geschlossenes Betreiberwerkzeug vorhanden, kein allgemeiner Umzug per Knopfdruck. Der Entwicklungsstand zeigt, was geprüft ist. Wenn du ohnehin den Wechsel erwägst, hilft die Umzugs-Checkliste; bei Geschwindigkeitsproblemen die Diagnose für langsame WordPress-Seiten. Das ist keine Rechtsberatung und keine Sicherheitsgarantie.
Häufige Fragen
Was heißt es, wenn ein WordPress-Plugin geschlossen ist?
Laut Plugin Developer FAQ sind Downloads und Installationen über das Dashboard dann nicht mehr möglich, und es werden keine ZIP-Dateien mehr erzeugt. Gründe können Richtlinienverstöße, Sicherheitsprobleme oder ein Wunsch des Autors sein.
Ist ein Plugin ohne Updates automatisch unsicher?
Nicht automatisch: Die Warnung im Verzeichnis sagt nur, dass das Plugin nicht mehr gepflegt sein und Kompatibilitätsprobleme haben kann. Ohne Pflege bekommst du aber auch keine Sicherheitskorrekturen mehr, deshalb solltest du das Risiko je Plugin prüfen.
Werden WordPress-Plugins automatisch aktualisiert?
Standardmäßig nur in Sonderfällen, die die WordPress.org-API bestimmt. Seit WordPress 5.5 kannst du automatische Updates im Admin für jedes Plugin einzeln aktivieren.
Kann ich ein verwaistes Plugin selbst übernehmen?
Das Plugin-Team erlaubt es laut FAQ, Plugins zu adoptieren, die nicht mehr entwickelt werden. Du solltest zuerst die Entwickler kontaktieren, den Code instand setzen und das Team ansprechen; ein Anspruch auf Übernahme besteht nicht.
Primärquellen und Quellenstand
Die folgenden Quellen wurden am 30. Oktober 2026 für diesen Ratgeber abgerufen. Einordnung und Empfehlungen sind unsere Auswertung; sie ersetzen keine Rechtsberatung und keinen Test deines konkreten Vorhabens.
- WordPress Support: Hinweis bei lange nicht aktualisierten Plugins (2013)
- WordPress Developer Resources: Plugin Developer FAQ (Schließung, Adoption)
- WordPress Developer Resources: Detailed Plugin Guidelines
- WordPress Developer Resources: Backup
- WordPress Developer Resources: Upgrading und automatische Hintergrund-Updates
- WordPress Developer Resources: wp_get_environment_type()
- WordPress.org: WordPress 5.5 Eckstine
- WordPress.org: WordPress 6.6 Dorsey
- Make WordPress Core: Merge Proposal Rollback Auto-Update
Weiterlesen
- WordPress zu langsam? Erst messen, dann ändern
- WordPress-Alternative Open Source: Hilfe nach Anwendungsfall
- Website selbst hosten: Heimserver, VPS oder Hoster – was passt?
Selbst betreiben statt gehostet: Ostrelle ist als Apache-2.0-Projekt angelegt. Wie das heute geht, steht unter Selbst hosten; was bei einem Ausfall zu tun ist, unter Hilfe bei Ausfällen. Ein öffentlicher Quellcode-Download ist geplant, aber noch nicht verfügbar.