Gastbeitrag von Jörg Kiefer, redbra.in. Bei größeren Projekten arbeiten wir im Team: Ich kümmere mich um Struktur, Content und SEO, die technische Umsetzung kommt von Jörg. Wenn ein Projekt eine Funktion braucht, die es als fertiges Plugin nicht gibt, landet die Frage bei ihm. Wie so eine Entscheidung abläuft und woran man später merkt, ob sie richtig war, beschreibt er hier aus seiner Werkstatt.
Das WordPress-Verzeichnis führt Zehntausende Plugins. Trotzdem endet in vielen größeren Projekten die Suche mit demselben Ergebnis: Es gibt vier Lösungen, die fast passen, und keine, die passt. An dieser Stelle fällt die Entscheidung über eine WordPress-Plugin-Eigenentwicklung — und die ist zuerst eine wirtschaftliche, erst danach eine technische.
Was dann folgt, hat mit dem Bild vom Entwickler, der sich hinsetzt und drauflostippt, wenig zu tun. Der Code ist der kürzeste Abschnitt der Strecke. Davor liegen Prüfungen und Festlegungen, die darüber entscheiden, ob das Ergebnis in drei Jahren noch läuft oder ob es am nächsten größeren Core-Update zerbricht. Der folgende Ablauf beschreibt den Weg so, wie er in der Praxis aussieht.
Die Vorfrage: braucht es überhaupt ein eigenes Plugin
Vor jedem Eigenbau steht eine ehrliche Bestandsprüfung. Vier Wege sind fast immer billiger als eine Neuentwicklung: ein vorhandenes Plugin, eine Theme-Funktion, ein kurzes Snippet im Child-Theme oder eine Automatisierung, die außerhalb der Website läuft und nur ein Ergebnis einliefert. Wer diese Prüfung überspringt, baut regelmäßig etwas nach, das es längst gibt.
Drei Gründe sprechen belastbar für den Eigenbau. Erstens: Die Anforderung ist fachlich einmalig, weil sie aus einem konkreten Betriebsablauf stammt und nirgends als Produkt existiert. Zweitens: Ein Fremdplugin liefert vierzig Funktionen, gebraucht wird eine — und die anderen neununddreißig bringen Ladezeit, Update-Zwang und Angriffsfläche mit. Drittens: Die Daten sind heikel, und ihre Verarbeitung soll nicht von der Roadmap eines fremden Anbieters abhängen.
Gegen den Eigenbau spricht ein Argument, das jeden dieser drei Gründe schlagen kann: Jede selbst gebaute Zeile ist eine dauerhafte Verpflichtung. Sie altert mit PHP, mit WordPress, mit dem Page-Builder. Wer ein Plugin baut, übernimmt dessen Wartung für die gesamte Lebensdauer der Website.
Faustregel: Gebaut wird, wenn die Anforderung länger lebt als das Projekt. Alles andere ist ein Snippet.
Die Zielumgebung prüfen, bevor die erste Zeile entsteht
Ein Plugin läuft nicht in WordPress, sondern in genau dieser Installation. Deshalb steht am Anfang eine Bestandsaufnahme, die schriftlich festgehalten wird — Versionsstände von WordPress, PHP, MySQL samt Kollation, Tabellenpräfix, Theme, Page-Builder, Caching-Schicht, Opcode-Cache.
Zwei Punkte aus dieser Liste werden regelmäßig unterschätzt.
Der erste ist der Zugang. Nicht jedes Hosting bietet SSH oder eine Kommandozeile. Fehlt beides, muss das Plugin als ZIP über den Upload im Backend installierbar sein, ohne Build-Schritt auf dem Server, ohne Composer, ohne Nachinstallation. Das ist keine Kleinigkeit, sondern eine Architekturvorgabe: Alles, was zum Betrieb nötig ist, liegt fertig im Paket.
Der zweite ist das Fehlerlog. Auf vielen Kundeninstallationen ist die Protokollierung abgeschaltet, und niemand wird sie für ein einzelnes Plugin einschalten. Ein Fehler, der dort ins Leere läuft, existiert praktisch nicht — bis sich Wochen später jemand über falsche Zahlen wundert. Die Konsequenz ist ein eigener Diagnosebereich im Backend, der die kritischen Betriebsannahmen sichtbar prüft und im Zweifel warnt.
Dazu kommt der Blick auf den Bestand an Fremdplugins. Sicherheits-Plugins blockieren gern anonyme POST-Anfragen an Standard-Endpunkte. Optimierer fassen Skripte zusammen und ändern damit die Ladereihenfolge. Zwei parallel installierte Consent-Manager sind keine Seltenheit. Jede dieser Komponenten kann eine Eigenentwicklung lautlos aushebeln.
Ein Sonderfall, der jedes Mal geprüft gehört: Steht ein Reverse-Proxy vor der Seite, liefert die Serverumgebung für sämtliche Besucher dieselbe Adresse. Jede Logik, die auf Besucherunterscheidung baut, kippt damit — und zwar unsichtbar, weil der ausgesperrte Besucher nur eine höfliche Meldung sieht und weiterklickt.
Die Anforderung härten
Die wertvollste Arbeit an einem Plugin passiert, bevor die Architektur steht: das Zerlegen des Auftragssatzes in Anforderungen, die sich gegenseitig widersprechen.
Ein Beispiel. Eine Online-Umfrage soll anonym sein, und jede Teilnahme soll nur einmal möglich sein. Beides zusammen ist technisch nicht sauber lösbar, solange nichts von außen dazukommt. Alles, was im Browser liegt — Cookie, lokaler Speicher — ist mit zwei Klicks gelöscht. Eine Sperre muss serverseitig sitzen, und jede serverseitige Sperre braucht ein Merkmal, das den Teilnehmer wiedererkennt. Genau das steht der Anonymität entgegen.
Aus dieser Spannung werden Optionen mit ihren Folgen:
Eine gesalzene Prüfsumme der Besucheradresse ist niedrigschwellig und hält gegen Cookie-Löschung, Inkognito-Modus und Browserwechsel. Ihre Grenzen gehören offen benannt: Adressen werden von mehreren Anschlüssen geteilt, sie wechseln im Betrieb, und jede Sperre auf Netzwerkebene lässt sich mit etwas Aufwand umgehen. Sie hält gegen Bequemlichkeit, nicht gegen Absicht.
Ein Codeverfahren mit vorab vergebenen Zugangsnummern ist der Goldstandard, kostet aber Verteilaufwand und senkt die Beteiligung spürbar.
Eine Geräteerkennung wäre technisch härter als beide — und scheidet aus, weil sie nach geltendem Recht einwilligungspflichtig ist. Damit bräuchte die Umfrage ein Consent-Banner und wäre nicht mehr niedrigschwellig. Die technisch beste Lösung ist hier die fachlich schlechteste.
Die Entscheidung fiel für die Prüfsumme, und zwar mit einer Begründung, die nichts mit Technik zu tun hat: Wenn eine Umfrage überhaupt etwas aussagen soll, zählt die Beteiligungsquote mehr als die Fälschungssicherheit. Eine breite Teilnahme mit weicher Sperre trägt weiter als eine schmale mit harter.
Entscheidend ist weniger die Wahl selbst als ihre Dokumentation. Wer in zwei Jahren an dieses Plugin geht, findet die verworfenen Wege samt Grund vor und muss die Abwägung nicht raten.
Das Datenmodell zuerst
Oberflächen lassen sich jederzeit umbauen. Ein Datenmodell nicht — jedenfalls nicht, sobald echte Daten drinstehen. Deshalb liegt hier der Schwerpunkt.
Am Beispiel der anonymen Umfrage lässt sich zeigen, wie weit das trägt. Vier Festlegungen sehen nach Überkorrektheit aus und sind jeweils die Antwort auf einen konkreten Angriffspfad:
Stimmen, Sperrvermerke und Freitexte liegen in drei Tabellen ohne gemeinsame Spalte auf Zeilenebene. Stünden Stimme und Sperrmerkmal in einer Zeile, stünde dort wörtlich, welche Prüfsumme wie abgestimmt hat.
Die Primärschlüssel sind Zufallswerte statt fortlaufender Zähler. Ein Zähler verrät die Einfügereihenfolge, und das Zugriffsprotokoll des Webservers protokolliert dieselbe Reihenfolge mitsamt Adresse und Zeitstempel. Wer beide Listen nebeneinanderlegt, ordnet jede Stimme zu.
Zeitangaben werden tagesgenau gespeichert, nicht sekundengenau. Aus demselben Grund.
Freitexte liegen getrennt von den Strukturdaten. Wenige strukturierte Merkmale plus ein persönlich formulierter Kommentar ergeben in einer kleinen Grundgesamtheit sehr schnell einen identifizierbaren Einzelfall.
Dazu kommt eine Gewohnheit, die sich immer auszahlt: absehbare Erweiterungen als leere Spalte vorbereiten. Wenn das Codeverfahren später doch gebraucht wird, liegt das Feld dafür bereits im Schema — die Nachrüstung braucht dann keine Datenmigration.
Und noch eine Regel aus der Praxis: Schlüssel so schneiden, dass ein späterer Umbau bestehende Daten nicht entwertet. Enthält ein Sperrvermerk die Kennung der Umfrage, müssten beim Umstieg von einer auf mehrere Umfragen sämtliche bestehenden Sperren neu berechnet werden — ohne die ursprünglichen Ausgangsdaten unmöglich.
Sicherheit ist kein Kapitel am Ende
In jeder Entwicklung gelten dieselben Pflichtmuster, ohne Ausnahme und ohne Abkürzung: Direktaufrufe der Dateien werden abgefangen. Jedes Formular trägt ein Einmal-Token, jeder Handler prüft es. Vor jeder schreibenden Aktion steht eine Berechtigungsprüfung mit der kleinstmöglichen Rechtestufe. Eingaben werden beim Eintritt bereinigt, Ausgaben beim Austritt maskiert — je nach Zielkontext unterschiedlich, denn ein Wert im HTML-Attribut braucht eine andere Behandlung als einer im Fließtext oder in einer Verlinkung.
Ein Punkt, der außerhalb der üblichen Checklisten steht, aber im Agenturbetrieb regelmäßig zuschlägt: Präfix-Disziplin. Klassen, Optionen, Tabellen, Hooks und Übersetzungsdomänen bekommen ein projekteigenes Kürzel. Sobald zwei Eigenentwicklungen auf derselben Installation laufen und beide eine gleichnamige Hilfsklasse mitbringen, endet das in einem sofortigen Abbruch der Seite. Diese Art Fehler ist trivial zu vermeiden und teuer zu finden.
Die rechtliche Seite gehört in dieselbe Phase, nicht in eine spätere. Wo personenbezogene Daten anfallen, werden Löschfristen als Funktion gebaut und nicht als Vorsatz. Sensible Felder werden verschlüsselt abgelegt. Und der dafür nötige Schlüssel ist ein eigener, kein globaler Systemschlüssel — denn ein eigener lässt sich nach Projektende löschen, wodurch die Restdaten unbrauchbar werden. Ein Systemschlüssel bleibt in der Konfiguration stehen.
Ein Plugin bringt Funktion mit, kein Design
Die häufigste Ursache für hässliche Frontend-Ausgaben ist ein Plugin, das eigene Farben, Rundungen und Schaltflächen mitbringt. Auf modernen WordPress-Installationen kommt das gesamte Erscheinungsbild aus dem Design-Kit des Builders oder des Themes. Minimalistische Themes liefern für Formularfelder und Schaltflächen nur ein Reset, kein Aussehen.
Bringt ein Plugin trotzdem eigene Optik mit, liegen zwei Designsysteme übereinander, und jede spätere Kit-Änderung läuft am Plugin vorbei. Sauber ist das Gegenteil: Das Plugin liefert Struktur und Layout und dockt für Farben und Schriften an die Systemvariablen des Builders an, die auf jeder Installation vorhanden sind. Projektspezifische Kit-Farben tragen dagegen instanzabhängige Kennungen und sind für ein wiederverwendbares Plugin nicht ansprechbar.
Zum selben Themenkreis gehört eine Falle, die viel Zeit kostet: Page-Builder rendern eingebettete Kurzbefehle im Editor über asynchrone Nachladung. Ein Stylesheet, das erst im Kurzbefehl selbst registriert wird, greift dort nicht mehr — das Formular sieht im Editor unformatiert aus, und versteckte Schutzfelder werden sichtbar. Assets gehören deshalb global registriert.
Testen heißt, die Umgebung nachzubauen
Eine Funktion durchzuklicken ist kein Test. Getestet wird gegen eine lokale Kopie mit denselben Versionsständen, demselben Theme und denselben relevanten Fremdplugins.
Ein Detail lohnt besondere Erwähnung: Die lokale Installation sollte in einem Unterverzeichnis liegen, auch wenn das Ziel im Wurzelverzeichnis läuft. Pfadfehler bei der Erzeugung von URLs — etwa wenn Basis-URL und angeforderter Pfad unsauber zusammengesetzt werden und das Verzeichnis doppelt erscheint — fallen in einer Wurzelinstallation nie auf und auf dem nächsten Kundenprojekt sofort.
Die Testmatrix umfasst vier Zustände, nicht einen: Erstinstallation auf leerer Datenbank, Update von der Vorgängerversion mit echtem Altbestand, Deaktivierung und vollständige Deinstallation. Besonders der zweite Fall gehört ernst genommen. Migrationen laufen häufig nicht im Aktivierungs-Hook, weil dort noch nicht alle Registrierungen stehen, sondern beim regulären Start — und sie müssen mehrfach ausgeführt werden können, ohne Schaden anzurichten.
Drei Stolpersteine aus der Werkstatt, die sich nur beim Bauen zeigen: Automatische Datenbankanpassungen können bestehende Primärschlüssel nicht ändern, dafür braucht es einen expliziten Schritt mit vorheriger Prüfung. Versteckte Formularfelder belegen in einem CSS-Raster echte Zellen und reißen Lücken — betrifft auch die Felder der Token-Ausgabe. Und je nach Werkzeug können unter Windows erzeugte ZIP-Archive Rückwärts-Schrägstriche in den Pfaden speichern; auf einem Linux-Server entstehen daraus flache Dateien mit Schrägstrich im Namen, und das Plugin ist defekt. Jedes fertige Paket gehört gegengeprüft, bevor es beim Kunden landet.
Ausliefern, aktualisieren, übergeben
Die Versionsnummer steht an genau einer Stelle und wird von dort gelesen — verteilte Versionsangaben in Plugin-Header, Konstante und Changelog laufen garantiert auseinander.
Beim Einspielen einer neuen Fassung gilt eine Regel, die im Alltag oft verletzt wird: ersetzen, nicht löschen und neu installieren. Ein sauber gebautes Plugin räumt bei der Deinstallation seine Tabellen ab — genau das ist gewünscht und genau das vernichtet bei einem falsch verstandenen Update sämtliche Daten.
Zur Auslieferung gehört eine Übergabe, die den Namen verdient: Bedienung, Diagnosewege, bekannte Grenzen, Versionshistorie mit Begründungen. Diese Dokumentation ist kein Beiwerk. Sie ist der Unterschied zwischen einem wartbaren Modul und einer Black Box, die beim nächsten Personalwechsel niemand mehr anfassen will.
Modul statt Plugin-Zoo
Wer über Jahre für viele Installationen baut, stellt fest, dass sich Anforderungen wiederholen. Anmeldeseiten im Kundendesign, Wartungsanzeigen, wiederkehrende Ausgabeelemente, Schnittstellen zur eigenen Verwaltung.
Der Reflex, dafür je ein kleines Plugin zu bauen, rächt sich. Zwanzig Einzelplugins bedeuten zwanzig Versionsstände, zwanzig Update-Wege und zwanzig Gelegenheiten, dass eines vergessen wird. Die tragfähigere Bauweise ist ein modulares Werkzeug: ein Rahmen mit gemeinsamer Infrastruktur, darin abschaltbare Module, zentral aktualisiert. Neue Anforderungen werden zu Modulen, nicht zu Plugins.
Damit verschiebt sich auch die Wirtschaftlichkeitsrechnung. Die erste Umsetzung einer Anforderung kostet vollen Aufwand, die zweite und dritte kosten Konfiguration.
Woran sich erkennen lässt, ob der Eigenbau richtig war
Fünf Fragen, beantwortbar zwei Jahre nach der Auslieferung. Läuft das Plugin nach mehreren Core- und PHP-Updates ohne Eingriff? Konnte eine neue Anforderung ergänzt werden, ohne bestehende Daten zu migrieren? Findet ein fremder Entwickler in der Dokumentation, warum die Architektur so aussieht, wie sie aussieht? Hat das Plugin bei einem Design-Relaunch der Website unverändert weitergearbeitet? Und ließ sich ein Fehler auf einer Installation ohne Fehlerprotokoll überhaupt einkreisen?
Wer viermal ja sagen kann, hat kein Plugin gebaut, sondern ein Werkzeug. Der Unterschied zeigt sich nie am Tag der Auslieferung, sondern immer erst danach.
Wenn bei einem Projekt die Frage aufkommt, ob eine Funktion als Eigenbau oder mit Bordmitteln gelöst wird, klären wir das gemeinsam, bevor gebaut wird. Wie wir WordPress-Projekte grundsätzlich aufsetzen, steht auf unserer Seite zur WordPress-Entwicklung — dort findest du auch den Weg zum Erstgespräch.
Häufige Fragen zur Plugin-Eigenentwicklung
Wann lohnt sich ein eigenes WordPress-Plugin statt eines fertigen?
Wenn die Anforderung aus einem konkreten Betriebsablauf stammt und es dafür kein Produkt gibt, wenn ein Fremdplugin vierzig Funktionen mitbringt und nur eine gebraucht wird, oder wenn die Datenverarbeitung nicht von der Roadmap eines fremden Anbieters abhängen soll. Faustregel: Gebaut wird, wenn die Anforderung länger lebt als das Projekt.
Was bedeutet ein eigenes Plugin für die Wartung?
Jede selbst gebaute Zeile ist eine dauerhafte Verpflichtung. Sie altert mit PHP, mit WordPress und mit dem Page-Builder. Wer ein Plugin baut, übernimmt dessen Pflege für die Lebensdauer der Website — das gehört in die Entscheidung, nicht erst in die Rechnung.
Kann ein eigenes Plugin bei einem WordPress-Update kaputtgehen?
Wenn es sauber gebaut ist, überlebt es Core- und PHP-Updates ohne Eingriff. Vorausgesetzt, es nutzt die offiziellen Schnittstellen, verzichtet auf Eingriffe in fremden Code und wurde vor der Auslieferung gegen dieselben Versionsstände getestet, die auf der Zielinstallation laufen.
Bringt ein eigenes Plugin ein eigenes Design mit?
Nein, und genau das ist der Punkt. Ein Plugin liefert Funktion und Struktur, die Optik kommt aus dem Design-System des Themes oder Page-Builders. Andernfalls liegen zwei Designsysteme übereinander, und jede spätere Änderung am Erscheinungsbild läuft am Plugin vorbei.
Über den Autor: Jörg Kiefer betreibt redbra.in und übernimmt in unseren gemeinsamen Projekten Webdesign, technische Umsetzung und Eigenentwicklungen für WordPress.
