WordPress-Plugins
Jedes WordPress-Plugin ist fremder PHP-Code, der mit denselben Rechten läuft wie der Core. Dreißig Plugins sind deshalb keine Ordnungsfrage, sondern dreißig Vertrauensentscheidungen, die einmal getroffen und danach nie wieder überprüft wurden. Die Sharpness Solutions GmbH in Oldenburg erhebt das Plugin-Inventar bestehender WordPress-Installationen, bewertet jede Erweiterung einzeln und sagt, was bleibt, was ersetzt wird und was besser selbst gebaut ist. Aktuell ist WordPress 7.0.3 vom 6. August 2026; 7.1 erscheint am 19. August 2026 und bringt drei Änderungen mit, die genau selbstgebaute Erweiterungen treffen. Stand: 17. August 2026. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr.
Anfragen zu Plugins kommen in zwei Varianten. Entweder ist die Liste unter Plugins → Installierte Plugins so lang geworden, dass niemand mehr für jeden Eintrag sagen kann, was er tut und ob er noch gebraucht wird. Oder es fehlt genau eine Funktion, und die vier Plugins, die sie angeblich liefern, tun jeweils das Falsche. Zur Größenordnung: Der Patchstack-Bericht „State of WordPress Security in 2026“ zählt für das Jahr 2025 11.334 neu gemeldete Schwachstellen im WordPress-Ökosystem, 42 Prozent mehr als die 7.966 des Vorjahres. 91 Prozent davon lagen in Plugins, 9 Prozent in Themes, sechs im Core selbst — alle sechs niedrig eingestuft. 1.966 Meldungen, 17 Prozent, waren hoch eingestuft. Und 46 Prozent hatten zum Zeitpunkt der Veröffentlichung noch keinen Patch des Herstellers. Das Risiko liegt nicht in WordPress. Es liegt in dem, was Sie dazu installiert haben.
Die Liste ist über Jahre entstanden: eine Erweiterung für einen Kampagnenlauf 2019, zwei für dasselbe Caching-Problem, eine, die eine ehemalige Kollegin ausprobiert hat. Aktiviert sind sie alle. Welche Funktion im Frontend an welchem Plugin hängt, weiß niemand mehr — und genau deshalb wird nichts entfernt.
Wird ein Plugin auf wordpress.org geschlossen, zeigt WordPress es in der Verwaltung weiter als aktuell an, weil es keine Aktualisierung mehr gibt. Weder das Plugin-Übersichtsfenster noch die Website-Zustandsprüfung weisen auf die Schließung hin. Das Ausbleiben einer Meldung fühlt sich wie ein guter Zustand an und ist keiner.
Gesucht wird eine Preisstaffel nach Kundengruppe, eine Anbindung an die eigene Warenwirtschaft, ein Freigabeworkflow für Redaktionsinhalte. Was der Markt anbietet, deckt jeweils einen Teil davon ab und bringt zusätzlich vieles mit, das niemand braucht. Drei Plugins plus Klebe-Code sind dann teurer als ein sauber gebautes eigenes.
Eine Metabox, ein eigener Block, eine zusätzliche Spalte in einer Listenansicht: gebaut vor drei Jahren, seither unangetastet, funktioniert. WordPress 7.1 ändert am 19. August 2026 drei Dinge, die genau solchen Code treffen. Ob Ihre Erweiterung dabei ist, sieht man nicht von außen, sondern nur auf einem Testsystem.
WordPress kennt keine Rechtetrennung zwischen Plugins. Jede aktivierte Erweiterung läuft im selben PHP-Prozess wie der Core, mit denselben Datenbankrechten, denselben Dateisystemrechten und Zugriff auf jeden Hook, den WordPress anbietet. Es gibt keine Sandbox, keine Capability-Grenze zwischen zwei Plugins und keine Deklaration, welche Daten eine Erweiterung anfassen darf. Ein Plugin, das nur Kontaktformulare rendern soll, kann Bestellungen lesen, Benutzerkonten anlegen und Dateien schreiben. Das ist keine Nachlässigkeit im Kern, das ist das Erweiterungsmodell von WordPress, und es ist einer der Gründe für seine Verbreitung. Die betriebliche Folge ist unbequem: Das Sicherheitsniveau einer Installation ist nicht der Durchschnitt aller Plugins, sondern das Niveau des schwächsten. Dreißig Plugins sind deshalb dreißig Vertrauensentscheidungen.
Zwei Zahlen aus dem Patchstack-Bericht für 2025 gehören in jede Entscheidungsvorlage. Erstens: 46 Prozent der gemeldeten Schwachstellen hatten zum Zeitpunkt der öffentlichen Veröffentlichung keinen Patch des Herstellers. Wer Sicherheit als „wir aktualisieren zeitnah“ definiert, hat für knapp die Hälfte der Fälle keine Antwort, weil es nichts zu aktualisieren gibt. Zweitens die Geschwindigkeit: Der nach beobachteter Angriffsintensität gewichtete Median bis zum ersten Ausnutzungsversuch liegt bei fünf Stunden. Unter den stark ausgenutzten Lücken wurden 20 Prozent innerhalb von sechs Stunden angegriffen, 45 Prozent innerhalb von 24 Stunden, 70 Prozent innerhalb von sieben Tagen. Ein monatliches Update-Fenster ist gegen automatisierte Massenscans kein Schutzkonzept. Deshalb ist die erste Maßnahme nicht schnelleres Aktualisieren, sondern eine kürzere Liste.
Deaktivieren räumt nicht auf. Ein deaktiviertes Plugin ist weiterhin Code im Verzeichnis wp-content/plugins, und ob eine seiner Dateien direkt über die URL erreichbar und ausführbar ist, hängt allein daran, ob der Autor sie gegen den direkten Aufruf abgesichert hat. Die übliche Prüfung auf ABSPATH am Dateianfang ist Konvention, keine Pflicht. Deaktivierte Plugins bekommen außerdem weiter Updates angeboten, was die Liste im Update-Fenster verlängert, ohne dass jemand etwas davon hat. Wenn eine Erweiterung nicht gebraucht wird, wird sie gelöscht. Dabei bleibt allerdings meistens etwas zurück: Nur wer eine Deinstallationsroutine über uninstall.php oder register_uninstall_hook mitliefert, räumt seine Optionen, Tabellen und Metadaten wirklich weg. Der Rest hinterlässt Datenreste, die niemand mehr zuordnen kann.
Die dritte Kostenstelle ist die Überschneidung. Zwei Caching-Plugins, die sich gegenseitig die Header überschreiben. Ein SEO-Plugin, das Meta-Angaben setzt, und ein Theme, das dieselben Angaben ein zweites Mal ausgibt. Drei Erweiterungen, die je einen Teil des Cookie-Banners übernehmen. Solche Paare kosten nichts an Lizenz und viel an Fehlersuche, weil das Verhalten von der Ladereihenfolge abhängt und sich nach jedem Update ändern kann. Dazu kommt der laufende Aufwand: Jedes Plugin ist ein Update-Kandidat, ein Kompatibilitätsrisiko bei jedem Major-Release und ein Eintrag, den bei einer Störung jemand ausschließen muss. Zwölf Plugins lassen sich in einem Vormittag einzeln durchschalten. Vierzig nicht.
Das Inventar ist eine Tabelle, nicht ein Gefühl. Erhoben wird pro Erweiterung: Name und Slug, Herkunft (Verzeichnis auf wordpress.org, kommerzieller Anbieter, selbst gebaut, unbekannt), installierte und verfügbare Version, Datum der letzten Aktualisierung durch den Autor, Größenordnung der aktiven Installationen, der Wert aus dem Feld „Tested up to“, offene Sicherheitsmeldungen, Lizenz- und Laufzeitstatus bei kommerziellen Plugins, und in einem Satz der Zweck: welche Funktion im Frontend oder in der Redaktion an dieser Erweiterung hängt. Dazu die Frage, die am häufigsten unbeantwortet bleibt: Wird sie überhaupt noch aufgerufen? Die Grunddaten holen wir über WP-CLI, den Rest über das Verzeichnis, die Änderungshistorie des Anbieters und einen Blick in den Code. Der Vergleich der Dateien gegen die Fassung im Verzeichnis über wp plugin verify-checksums zeigt zusätzlich, ob jemand in einem fremden Plugin herumgeschrieben hat.
Bei der Bewertung des Pflegezustands ist der Warnhinweis im Verzeichnis ein schwaches Signal in beide Richtungen. Der gelbe Kasten „This plugin hasn’t been tested with the latest 3 major releases of WordPress“ erscheint, wenn im Feld „Tested up to“ der readme.txt keine der letzten drei Hauptversionen steht. Er sagt nichts über Fehler aus, und er lässt sich durch eine geänderte Zeile in der readme.txt ausräumen, ohne dass eine Zeile Code angefasst wird. Umgekehrt heißt ein fehlender Hinweis nicht, dass jemand hinsieht. Belastbarer sind vier andere Dinge: Datum und Inhalt der letzten tatsächlichen Code-Änderung, wie viele Support-Anfragen unbeantwortet stehen, wie der Autor auf die letzte gemeldete Lücke reagiert hat, und ob es überhaupt eine benannte Person oder Firma dahinter gibt. Bei kommerziellen Plugins kommt hinzu, ob die Lizenz noch läuft — eine abgelaufene Laufzeit heißt bei den meisten Anbietern: keine Updates, auch keine sicherheitsrelevanten.
Aus dem Inventar wird eine Entscheidung je Zeile, mit vier möglichen Ausgängen. Behalten: Die Erweiterung ist gepflegt, wird gebraucht, hat keinen Doppelgänger. Ersetzen: Die Funktion wird gebraucht, aber der Anbieter ist der schwächere Teil der Konstruktion, oder zwei Plugins tun dasselbe und eines genügt. Ausbauen: Die Funktion wird nicht mehr gebraucht, oder der Core kann sie inzwischen selbst — das kommt häufiger vor, als die Liste ahnen lässt. Selbst bauen: Die Funktion ist geschäftskritisch, und es gibt keinen Anbieter, dem man sie anvertrauen möchte. Jede Zeile bekommt eine Begründung und einen Aufwand, damit die Liste ohne uns weiterverwendbar ist. Und eine Erwartung räumen wir vorher ab: Aufräumen heißt in der Regel nicht halbieren. Die meisten Plugins bleiben. Der Gewinn liegt darin, dass Sie danach für jedes einzelne sagen können, warum.
Ein verwaistes Plugin kündigt sich nicht an. Wird eine Erweiterung auf wordpress.org geschlossen, steht auf der Verzeichnisseite nur noch der Hinweis „This plugin has been closed as of [Datum] and is not available for download“, aber in Ihrer Installation ändert sich nichts: Es gibt keine Aktualisierung, also zeigt WordPress das Plugin als aktuell. Der Grund der Schließung wird erst nach 60 Tagen offengelegt, und auch dann nur als grobe Kategorie — Einzelheiten nennt wordpress.org nicht. Die Kategorie entscheidet über die Dringlichkeit. „Author Request“ heißt: Zeit für einen geordneten Ersatz. „Merged Into Core“ heißt: Das Plugin kann weg, die Funktion ist jetzt in WordPress selbst. „Guideline Violation“ oder „Licensing/Trademark Violation“ heißt: prüfen, was da eigentlich läuft. „Security Issue“ heißt: heute handeln. Weil in der Verwaltung nichts davon auftaucht, gehört der Abgleich der installierten Slugs gegen das Verzeichnis in den Wartungsrhythmus — sonst merkt man es erst, wenn jemand die Lücke gefunden hat.
Bei einem verwaisten Plugin gibt es vier Wege, und keiner davon ist Abwarten. Ersatz durch eine gepflegte Alternative ist der Regelfall, kostet aber Datenmigration, wenn die alte Erweiterung eigene Tabellen oder Metafelder benutzt hat. Weiterpflege im eigenen Verantwortungsbereich ist bei GPL-lizenzierten Plugins erlaubt und manchmal sinnvoll, verschiebt aber die Verantwortung vollständig zu Ihnen: Ein Fork, den niemand pflegt, ist nur ein umbenanntes verwaistes Plugin. Übernahme des Plugins im Verzeichnis ist der geordnete Weg, wenn der Autor mitspielt — er kann die Rechte selbst übertragen, und wer ein Plugin abgeben will, kennzeichnet es mit dem Schlagwort adopt-me. Antwortet er nicht, läuft ein Verfahren über plugins@wordpress.org: überarbeiteten Code einreichen, das Plugin-Team schreibt den Autor an, nach 30 Tagen ohne Reaktion kann die Übergabe erfolgen. Bei einem bereits geschlossenen Plugin ist dieser Weg deutlich schwieriger. Bleibt Neuentwicklung der Funktion, wenn sie zu wichtig ist, um an fremdem Code zu hängen. Was der günstigste Weg ist, entscheidet der Funktionsumfang, nicht die Gewohnheit.
Der Sonderfall sind Page-Builder, weil dort nicht nur Funktion, sondern Inhalt am Plugin hängt. Elementor speichert die Seitenstruktur als JSON im Postmeta-Feld _elementor_data; im Feld _elementor_css liegt nicht Inhalt, sondern das daraus erzeugte CSS. Das Feld post_content bleibt dabei oft leer oder rudimentär. Die globalen Einstellungen liegen ebenfalls nicht als Option, sondern in einem eigenen Beitrag — dem Kit —, auf den die Option elementor_active_kit in wp_options nur verweist. WPBakery legt seine Struktur als Shortcodes im post_content ab, was ohne das Plugin sichtbaren Shortcode-Text hinterlässt statt Inhalt. Das Blockmarkup des Core-Editors steht dagegen als HTML mit Kommentaren im post_content und bleibt auch ohne alles lesbares Markup. Der Unterschied ist keine Geschmacksfrage, sondern eine Kostenrechnung für den Tag, an dem der Builder gewechselt oder eingestellt wird: Beim Blockeditor migriert man Markup, bei einem JSON-Builder baut man Seiten neu auf, seitenweise, mit redaktioneller Abnahme.
Deshalb bewerten wir einen laufenden Page-Builder, statt ihn zu verurteilen. Wenn Elementor oder WPBakery seit Jahren funktioniert, die Redaktion damit arbeitet und der Anbieter aktiv ist, gibt es keinen Grund, das Ganze in einem Wartungsprojekt herauszureißen — der Aufwand steht in keinem Verhältnis. Sinnvoll ist der Ausstieg zu genau zwei Anlässen: wenn das Design ohnehin ersetzt wird und die Inhalte in einem Relaunch neu strukturiert werden, oder wenn der Builder selbst zum Risiko wird, weil er ein Major-Update blockiert. Was wir vorher liefern, ist die Zahl, die dabei fehlt: wie viele Seiten tatsächlich im Builder-Format liegen, wie viele davon reine Textseiten sind, die sich mit vertretbarem Aufwand übertragen lassen, und welche Vorlagen von Hand nachgebaut werden müssen.
Ein eigenes Plugin ist die richtige Antwort, wenn die Funktion Ihr Geschäft betrifft und nicht das Internet allgemein. Vier Fälle kommen dabei regelmäßig vor. Erstens Regeln, die nur bei Ihnen gelten: Preisstaffeln nach Kundengruppe, Freigabeprozesse, Rabattlogik, Konfigurationsregeln für erklärungsbedürftige Produkte. Zweitens Schnittstellen zu Ihren Systemen — Warenwirtschaft, ERP, PIM, CRM —, weil dort das Datenmodell der Gegenseite entscheidet und nicht das eines Plugin-Anbieters. Drittens Funktionen, die datenschutzrechtlich sauber sein müssen und bei denen niemand erklären kann, wohin ein fertiges Plugin die Daten schickt. Viertens der Fall, in dem drei Erweiterungen plus Klebe-Code nötig sind, um zu erreichen, was ein überschaubares eigenes Plugin direkt tut: Dann ist die Eigenentwicklung nicht die teure, sondern die günstige Variante — und die wartbare.
Bei Standardaufgaben ist die Antwort Nein, auch wenn das gegen den Auftrag geht. Formulare, Backups, Caching, Bildkomprimierung, Metadaten für Suchmaschinen, Weiterleitungen, Zwei-Faktor-Anmeldung, Cookie-Einwilligung: Dort hat ein gepflegtes Plugin über Jahre Randfälle eingesammelt, die Sie nicht kennen und wir auf Anhieb auch nicht — Zeichensatzprobleme in Anhängen, Mailserver, die anders antworten als dokumentiert, Browser, die Dateifelder eigenwillig behandeln. Wer uns bittet, ein Kontaktformular zu entwickeln, bekommt von uns keinen Kostenvoranschlag, sondern zwei Plugin-Namen. Das gilt auch andersherum: Wenn eine Eigenentwicklung sich über die erwartete Nutzungsdauer nicht rechnet, sagen wir das vor dem Angebot und nicht in der zweiten Projektphase. Ein Plugin, das eine Funktion abdeckt, die es fertig gibt, ist auf Dauer Wartungslast ohne Gegenwert.
Was wir bauen, wird so gebaut, dass Updates weiter funktionieren. Das heißt konkret: keine Änderungen im Core, keine Änderungen in fremden Plugin- oder Theme-Verzeichnissen, keine Patches, die beim nächsten Update überschrieben werden. Erweitert wird über Hooks und Filter — add_action und add_filter — und über die dafür vorgesehenen Registrierungen für Blocks, REST-Routen, Custom Post Types und Metafelder. Alles Eigene liegt in einem eigenen Plugin mit eigenem Präfix, damit Funktions- und Optionsnamen nicht mit fremdem Code kollidieren; Theme-Anpassungen gehören in ein Child-Theme, nicht ins Original. Dazu die Pflichtteile, die man von außen nicht sieht: Capability-Prüfungen und Nonces bei jeder schreibenden Aktion, vorbereitete Statements für alles, was in die Datenbank geht, Abhängigkeiten über den seit WordPress 6.5 vorhandenen Header „Requires Plugins“ statt über eine Prüfung im Code, ein Durchlauf mit dem Plugin Check vor der Abnahme, eine Deinstallationsroutine, und der Quellcode in Ihrem Repository. Ein Plugin, das ein WordPress-Update blockiert, ist ein Konstruktionsfehler und kein Feature.
WordPress 7.1 erscheint am 19. August 2026, parallel zur WordCamp US in Phoenix. Vorher eine Klarstellung, weil sie in vielen Prüflisten falsch steht: React 19 kommt nicht mit 7.1. Das Upgrade wurde zurückgenommen, nachdem Inkompatibilitäten zwischen alter und neuer React-Fassung sowie in der Art, wie Plugins React einbinden, aufgetreten waren. 7.1 bleibt auf React 18.3; Gutenberg bietet ein experimentelles Flag, um React 19 zu testen. Wer seine Prüfliste um React-Migrationen herum baut, prüft das Falsche. Die relevanten Bruchstellen liegen an drei anderen Stellen, und sie treffen ausgerechnet den Code, den niemand im Blick hat: eigene Metaboxen, eigene Blöcke, eigene Spalten in Listenansichten, kleine Verwaltungsseiten aus früheren Projekten.
Die erste und wichtigste Änderung: Der Beitragseditor ist ab 7.1 immer in einem iframe — unabhängig vom Theme-Typ, unabhängig von der Block-API-Version der registrierten Blöcke und unabhängig von der der Blöcke im Inhalt. Bis dahin galt die Ausnahme: In 7.0 entschied die Block-API-Version der tatsächlich eingesetzten Blöcke darüber, ob der Editor iframed war, davor die der registrierten Blöcke; Blockthemes erzwangen das iframe ohnehin. Deshalb haben viele Installationen die Änderung nie zu sehen bekommen. Ab 7.1 gibt es keine Ausnahme mehr. Was bricht, ist jeder Code, der im Editor auf das globale document oder window zugreift — also der Großteil dessen, was per jQuery in den Editorbereich hineingreift, MutationObserver auf Editorinhalten, Skripte von Drittanbietern, die im Editor eingehängt werden, und CSS, das über einen globalen Selektor Inhalte im Canvas gestalten soll. Der Weg führt über ein Element im Canvas und dessen Eigenschaften ownerDocument und defaultView statt über die globalen Objekte; Ereignis-Listener am Canvas hängt man über useRefEffect ein und räumt sie dort auch wieder ab. Styles müssen über die dafür vorgesehenen Registrierungen in das iframe gebracht werden; global eingebundenes CSS erreicht den Inhalt nicht mehr.
Die zweite Änderung betrifft die Listentabellen der Beiträge — und damit auch Seiten und eigene Custom Post Types. Das führende th mit scope="row" ist von der Checkbox- in die Titelspalte gewandert: Die Checkbox-Zelle ist jetzt ein td, die Titelzelle ein th, das den Titel als aria-label trägt. Für Screenreader ist das ein Gewinn, für Erweiterungen eine Bruchstelle in Markup, das seit 2010 im Wesentlichen unverändert war. Wer über die CSS-Klasse check-column selektiert, um eine eigene Spalte zu positionieren, eine Zeile zu markieren oder ein Aktionsmenü einzuhängen, greift ins Leere; ebenso bricht Code, der Titel und Row Actions in einem td erwartet. Betroffen sind eigene Spalten in der Beitrags- und Seitenübersicht, Listenansichten eigener Custom Post Types, JavaScript für Sammelaktionen und alles CSS, das auf die alte Spaltenstruktur gerechnet ist; wer beide Fassungen bedienen muss, selektiert übergangsweise td und th zusammen. Die dritte Änderung ist kleiner und fällt trotzdem auf: Die Eigenschaft __next40pxDefaultSize ist wirkungslos geworden, Formularelemente rendern unbedingt mit 40 Pixel Höhe. Wer eigene Panels, Seitenleisten oder Metaboxen auf den früheren Standard von 36 Pixel ausgelegt hat — oder mit size="__unstable-large" gearbeitet hat —, bekommt verschobene Layouts.
Geprüft wird das auf einer Kopie, nicht im Livesystem, und in dieser Reihenfolge: Editor öffnen und die Browser-Konsole mitlesen, jeden eigenen Block und jede eigene Metabox einmal benutzen statt nur ansehen, jede Verwaltungsseite mit Listentabelle durchklicken, WP_DEBUG mit Protokollierung einschalten und danach das Log lesen, eigene Plugins durch den Plugin Check schicken. Der beruhigende Teil daran ist der Zeitpunkt: Minor-Releases spielt WordPress seit Version 3.7 selbstständig ein, Plugins und Themes seit 5.5 auf Wunsch — 7.0.2 vom 17. Juli 2026 kam mit kritischen Sicherheitsfixes sogar als erzwungenes Update. Ein Hauptversionssprung wie 7.1 kommt dagegen nicht von allein. Sie bestimmen den Termin. Das heißt aber auch: Wer ihn nicht bestimmt, verschiebt ihn nur — und prüft dann unter Zeitdruck gegen 7.2, die nach dem am 12. August 2026 veröffentlichten Zeitplan am 9. Dezember 2026 erscheinen soll.
Ablauf
Ein Screenshot der Seite Plugins → Installierte Plugins genügt für den Anfang; mit Administratorzugang wird die Einschätzung genauer. Sie bekommen eine schriftliche Bewertung je Erweiterung — behalten, ersetzen, ausbauen, selbst bauen — mit Begründung und Aufwand, auch dann, wenn Sie danach woanders beauftragen. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, info@sharpness.de.
Wir brauchen einen Administratorzugang, SSH- oder SFTP-Zugang zum Server, Zugriff auf die Datenbank und, falls vorhanden, das Repository. Erhoben wird lesend: Liste aller Plugins mit Version, Status und Herkunft, Theme und etwaiges Child-Theme, WordPress- und PHP-Version, Dateiabgleich gegen die Fassungen im Verzeichnis. Am Livesystem wird dabei nichts verändert.
Jede Zeile wird einzeln bewertet: Zweck und tatsächliche Nutzung, Pflegezustand des Anbieters, offene Sicherheitsmeldungen, Lizenz- und Laufzeitstatus, Überschneidungen mit anderen Plugins, Aufwand im Request-Pfad. Für kommerzielle Erweiterungen klären wir, auf wen die Lizenz ausgestellt ist — nicht selten auf die frühere Agentur.
Sie bekommen die Tabelle mit einer Empfehlung je Zeile — behalten, ersetzen, ausbauen, selbst bauen —, jeweils mit Begründung und Aufwandsschätzung, und getrennt danach, was ohne Risiko sofort geht und was auf ein Testsystem gehört. Die Vorlage ist ohne uns weiterverwendbar, auch wenn Sie danach woanders beauftragen.
Gearbeitet wird auf einem Staging-System. Entfernt und ersetzt wird einzeln und in kleinen Schritten mit Funktionstest dazwischen, weil bei gleichzeitigen Änderungen niemand mehr sagen kann, welche das Problem verursacht hat. Datenreste räumen wir mit auf, Weiterleitungen richten wir ein, wenn URLs betroffen sind. Der Rückweg ist vor dem ersten Schritt dokumentiert.
Zuerst eine Spezifikation in Prosa, die Ihre Fachabteilung lesen kann, dann der Code: eigenes Plugin mit eigenem Präfix, Erweiterung über Hooks und Filter, Capability-Prüfungen und Nonces, Abhängigkeiten über den Header „Requires Plugins“, Durchlauf mit dem Plugin Check, Deinstallationsroutine, Dokumentation. Der Quellcode liegt in Ihrem Repository, nicht in unserem.
Danach die Frage, wer die Liste künftig pflegt: Update-Fenster, Abgleich der installierten Slugs gegen das Verzeichnis, Prüfung eigener Erweiterungen vor jedem Major — beginnend mit 7.1. Reaktionszeiten regelt eine Service-Level-Stufe: BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden. Ohne Vereinbarung bearbeiten wir in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Es gibt keine Obergrenze, und jede genannte Zahl ist geraten. Entscheidend ist nicht die Menge, sondern ob Sie für jedes einzelne Plugin sagen können, welche Funktion daran hängt und wer es pflegt. Eine Installation mit vierzig gepflegten, benannten Erweiterungen ist unproblematischer als eine mit zwölf, von denen vier seit Jahren keinen Autor mehr haben. Praktisch relevant wird die Zahl an zwei Stellen: bei der Fehlersuche, weil jedes Plugin einzeln ausgeschlossen werden muss, und bei jedem Hauptversionssprung, weil jedes einzeln geprüft werden will.
Der gelbe Hinweis im Verzeichnis, dass ein Plugin nicht mit den letzten drei Hauptversionen getestet wurde, ist nur ein erstes Signal — er hängt am Feld „Tested up to“ der readme.txt und lässt sich durch eine geänderte Zeile ausräumen, ohne dass Code angefasst wird. Belastbarer sind vier Dinge: Datum und Inhalt der letzten echten Code-Änderung, wie viele Support-Anfragen unbeantwortet stehen, wie der Autor auf die letzte gemeldete Sicherheitslücke reagiert hat, und ob überhaupt eine benannte Person oder Firma dahintersteht. Bei kommerziellen Plugins zählt zusätzlich, ob die Lizenz noch läuft.
Zuerst den Grund klären: Schließungen werden erst nach 60 Tagen mit Grund ausgewiesen, und auch dann nur als grobe Kategorie. „Merged Into Core“ heißt, das Plugin kann weg. „Author Request“ erlaubt einen geordneten Ersatz. „Security Issue“ heißt handeln, heute. Auf die Offenlegung zu warten ist dabei keine Strategie, sondern nur der Fall, in dem sonst keine Information vorliegt. Wichtig ist der Betriebsteil: WordPress zeigt ein geschlossenes Plugin weiter als aktuell an, weil es keine Aktualisierung mehr gibt, und auch die Website-Zustandsprüfung schweigt. Der Abgleich der installierten Slugs gegen das Verzeichnis gehört deshalb in die Wartung.
Nein. Ein deaktiviertes Plugin liegt weiter als Code auf dem Server, und ob eine seiner Dateien direkt über die URL erreichbar und ausführbar ist, hängt allein daran, ob der Autor sie gegen den direkten Aufruf abgesichert hat — die verbreitete Prüfung auf ABSPATH ist Konvention, keine Pflicht. Außerdem erscheint die Erweiterung weiter im Update-Fenster und verlängert die Liste ohne Gegenwert. Wenn eine Funktion nicht gebraucht wird, wird das Plugin gelöscht, und die Datenreste in Optionen, Metafeldern und eigenen Tabellen werden mit aufgeräumt.
Wenn die Funktion Ihr Geschäft betrifft und nicht das Internet allgemein: Regeln, die nur bei Ihnen gelten, Schnittstellen zu Ihrer Warenwirtschaft oder Ihrem ERP, Anforderungen aus dem Datenschutz, bei denen niemand erklären kann, wohin ein fertiges Plugin Daten schickt. Und in dem Fall, in dem drei Plugins plus Klebe-Code nötig sind für das, was eine überschaubare Eigenentwicklung direkt tut. Bei Standardaufgaben — Formulare, Backups, Caching, Weiterleitungen, Cookie-Einwilligung — ist die Antwort Nein, weil dort ein gepflegtes Plugin jahrelang Randfälle eingesammelt hat.
Nach Aufwand, und der hängt an vier Größen, die vor dem Angebot geklärt werden: Umfang der Fachlogik, Zahl und Art der beteiligten Schnittstellen, ob eine Bedienoberfläche in der Verwaltung dazugehört, und wie streng die Anforderungen an Mehrsprachigkeit und Barrierefreiheit sind. Eine kleine Erweiterung, die eine Regel in einem bestehenden Prozess ändert, ist etwas anderes als eine Anbindung an ein ERP mit eigenem Datenmodell. Eine Preisliste gibt es nicht. Wenn sich die Eigenentwicklung über die erwartete Nutzungsdauer nicht rechnet, sagen wir das vor dem Angebot.
Weil beides beim nächsten Update überschrieben wird und Sie damit vor der Wahl stehen, das Update zu unterlassen oder die Anpassung erneut einzubauen. Beides ist teuer. Erweitert wird deshalb ausschließlich über die vorgesehenen Wege: Hooks und Filter, die Registrierungen für Blocks, REST-Routen, Custom Post Types und Metafelder, und ein Child-Theme für Theme-Anpassungen. Was wir bauen, liegt in einem eigenen Plugin mit eigenem Präfix. Ein Plugin, das ein WordPress-Update blockiert, ist ein Konstruktionsfehler und kein Feature.
Möglich, und es trifft ausgerechnet Eigenentwicklungen. Drei Punkte sind zu prüfen. Erstens ist der Beitragseditor ab 7.1 immer in einem iframe — unabhängig vom Theme-Typ und unabhängig von der Block-API-Version: Code, der im Editor auf das globale document oder window zugreift, bricht; der Weg führt über ownerDocument und defaultView an einem Element im Canvas. Zweitens ist in den Beitragslistentabellen das führende th mit scope="row" von der Checkbox- in die Titelspalte gewandert; Erweiterungen, die auf die Klasse check-column selektieren, greifen ins Leere. Drittens ist __next40pxDefaultSize wirkungslos, Formularelemente rendern unbedingt mit 40 Pixel statt der früheren 36.
Nein. Das Upgrade auf React 19 wurde zurückgenommen, nachdem Inkompatibilitäten zwischen alter und neuer React-Fassung sowie in der Art, wie Plugins React einbinden, aufgetreten waren. WordPress 7.1 bleibt auf React 18.3. Gutenberg bietet ein experimentelles Flag, mit dem sich React 19 testen lässt — für die Vorbereitung eigener Erweiterungen ist das interessant, für die Prüfliste zum Release nicht. Wer seine 7.1-Prüfung um React-Migrationen herum plant, prüft das Falsche und lässt die drei tatsächlichen Bruchstellen offen.
Das hängt daran, wo die Inhalte liegen. Elementor speichert die Seitenstruktur als JSON im Postmeta-Feld _elementor_data; _elementor_css enthält das daraus erzeugte CSS, nicht Inhalt. post_content bleibt dabei oft leer. Die globalen Einstellungen stecken in einem eigenen Beitrag, dem Kit, auf den die Option elementor_active_kit nur verweist. WPBakery legt Shortcodes im post_content ab, die ohne das Plugin als sichtbarer Text übrig bleiben. Blockmarkup des Core-Editors steht dagegen als HTML mit Kommentaren im post_content und bleibt lesbar. Praktisch heißt das: Beim Blockeditor migriert man Markup, bei einem JSON-Builder baut man Seiten neu auf. Wir zählen vorher, wie viele Seiten wirklich betroffen sind, statt zu schätzen.
Ja. Der Quellcode liegt in Ihrem Repository, die Nutzungsrechte werden im Vertrag geregelt, und die Dokumentation gehört zur Lieferung. Das ist ausdrücklich so gemeint: Sie sollen die Betreuung beenden können, ohne dass eine Funktion mitgeht. Dazu passt der zweite Teil — Lizenzen für kommerzielle Erweiterungen werden auf Ihr Unternehmen ausgestellt, nicht auf uns, und wenn wir eine bestehende Installation übernehmen, prüfen wir zuerst, ob das bislang der Fall war. Abhängigkeit ist ein schlechtes Geschäftsmodell.
Ja, das ist der häufigste Anlass. Wir sehen den Code vorher an und geben eine schriftliche Einschätzung ab: Wie ist erweitert worden, gibt es Änderungen am Core oder in fremden Plugins, sind Capability-Prüfungen und Nonces vorhanden, wie steht es um SQL und Datenhaltung, ist die Erweiterung 7.1-fest. Erst danach reden wir über Betreuung. In seltenen Fällen sagen wir ab, etwa wenn zentrale Teile nur als verschlüsselter Code vorliegen — für einen Zustand, den man nicht einsehen kann, lässt sich keine Verantwortung übernehmen.
Das hängt an der vereinbarten Service-Level-Stufe: BASIC 24 Stunden, STANDARD 8 Stunden, ADVANCED 4 Stunden, PREMIUM 2 Stunden Reaktionszeit, abgerechnet als Monatspauschale je Projekt. Reaktionszeit heißt: wann jemand mit der Bearbeitung beginnt. Ohne Vereinbarung gilt die Grundzusage der Support-Seite — Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu unseren Geschäftszeiten Mo–Fr 9:00–16:00 Uhr. Eine Abdeckung außerhalb dieser Zeiten setzt eine ausdrücklich vereinbarte Rufbereitschaft voraus; ohne diese gibt es sie nicht.
Ja, der technische Teil ist mit WP-CLI schnell erledigt: wp plugin list liefert Slug, Status, Version und verfügbare Aktualisierung, wp plugin verify-checksums zeigt, ob jemand in einem Plugin aus dem Verzeichnis herumgeschrieben hat. Die Arbeit steckt in den beiden Spalten, die keine Maschine füllt: Welche Funktion im Frontend oder in der Redaktion hängt an dieser Erweiterung, und wird sie überhaupt noch benutzt? Wenn Sie diese Liste haben, schicken Sie sie mit — dann fangen wir bei der Bewertung an und nicht bei der Erhebung.
Anfrage
Wenn die Antwort für mehr als zwei Einträge „keine Ahnung“ lautet, ist das der Normalfall und der Anlass. Schicken Sie uns die Liste oder einen Zugang. Wir bewerten jede Erweiterung einzeln und sagen, was bleibt, was ersetzt wird und was besser selbst gebaut ist — vor jedem Angebot.