Custom WordPress
Plugins,
die halten.
Standard-Plugins reichen nicht immer. Wenn kein fertiges Plugin Ihren Use-Case abdeckt, zwei Plugins sich gegenseitig stören oder eine externe System-Anbindung gebraucht wird, entwickeln wir ein Plugin, das genau das tut - sauber gebaut, dokumentiert, nach WordPress Coding Standards.
Massarbeit statt
Kompromiss.
Wir entwickeln WordPress-Plugins präzise auf Ihre Anforderungen, zugeschnitten auf genau Ihren Use-Case. Jedes Plugin gehört nach Abschluss vollständig Ihnen: Repository, Dokumentation, volles Nutzungsrecht.
01 Custom Plugins Wenn kein fertiges Plugin den Use-Case abdeckt: spezifische Geschäftslogik, proprietäre Datenstrukturen, einzigartige Workflows - maßgeschneidert für Ihr WordPress.
02 Block-Entwicklung (Gutenberg) Native Block-Editor-Integration statt Page-Builder-Abhängigkeit. Custom Blocks mit eigenem Inspector-Panel, Server-Side-Rendering und strikter Abwärtskompatibilität.
03 REST-API-Erweiterungen Custom Endpoints für Headless-Setups, externe Integrationen und mobile Clients. Authentifizierung, Rate-Limiting und Response-Struktur nach Ihren Anforderungen.
04 ERP- und Drittsystem-Anbindungen Bidirektionale Schnittstellen zu SAP, DATEV, Salesforce, HubSpot und anderen Systemen. Sync-Logik, Fehlerbehandlung und Logging für stabile Produktiv-Betrieb.
05 Wartung bestehender Plugins Refactoring veralteter Code-Basis, Update-Pflege bei WordPress-Major-Releases, Sicherheits-Patches und schrittweise Modernisierung ohne Totalumbau.
06 Code-Audit Systematische Analyse bestehender Plugins auf Sicherheitslücken, Performance-Probleme und Abweichungen von Coding-Standards - mit priorisiertem Maßnahmenplan.
Wie wir Plugins bauen
WordPress Coding Standards einhalten
Die WordPress Coding Standards sind die verbindliche Grundlage unserer Arbeit. Sie legen fest, wie PHP-Code formatiert, Variablen benannt, Datenbankzugriffe abgesichert und Funktionen dokumentiert werden. Wer diese Standards ignoriert, schreibt Code, der schwerer zu warten, schwerer zu debuggen und schwerer an andere Entwickler zu übergeben ist. Wir nutzen PHP_CodeSniffer mit dem WordPress-Ruleset als festen Teil des Entwicklungsprozesses. Vor jedem Commit läuft eine automatische Prüfung. Code, der nicht durch den Sniffer kommt, geht nicht in Produktion.
Das hat einen praktischen Grund jenseits von Sauberkeit: Wenn Sie das Plugin eines Tages selbst pflegen wollen oder einen anderen Dienstleister beauftragen, findet jeder erfahrene WordPress-Entwickler sich sofort zurecht. Kein proprietärer Stil, keine undokumentierten Abkürzungen.
Update-sicher durch sauberes Hook-System
Update-Sicherheit ist das Ergebnis konkreter Entscheidungen im Code. Wir greifen niemals direkt in WordPress-Core-Dateien ein. Stattdessen nutzen wir das Hook-System: Actions und Filter an den vorgesehenen Stellen, keine Funktionen überschreiben, keine Core-Dateien modifizieren. Das bedeutet: Wenn WordPress ein Update veröffentlicht, läuft Ihr Plugin in aller Regel weiter.
Wir meiden außerdem Funktionen, die in WordPress als deprecated markiert sind. Deprecated Funktionen werden in zukünftigen Versionen entfernt - wer heute darauf setzt, baut Probleme für morgen. Stattdessen nutzen wir aktuelle APIs, auch wenn der alte Weg auf den ersten Blick kürzer wirkt.
Für sicherheitskritische Bereiche - Datenbankzugriffe, Formulardaten, Benutzerrollen, AJAX-Handler - gilt striktes Sanitizing und Escaping. SQL-Injection, Cross-Site-Scripting und Privilege-Escalation sind bekannte Angriffsvektoren. Wir behandeln jeden Eingabe-Wert als potenziell feindselig, bis das Gegenteil bewiesen ist.
Internationalisierbar von Anfang an
Internationalisierung nachträglich einzubauen ist aufwändig. Von Anfang an richtig aufzusetzen kostet kaum mehr. Jede Benutzer-seitige Zeichenkette wird über die WordPress-eigenen i18n-Funktionen (__, _e, _n, esc_html__) ausgezeichnet, eine .pot-Datei wird generiert und eine Textdomain wird sauber registriert. Das Plugin ist damit sofort durch jeden Übersetzer oder Übersetzungsdienst lokalisierbar - ohne Code-Änderung.
Das gilt auch für Datum- und Zahlenformate, Zeichensatz-Behandlung und Rechts-nach-Links-Layouts. Wenn Sie heute nur eine Sprache brauchen, ist das kein Argument gegen sauberes i18n-Setup - es ist eine Investition in spätere Flexibilität ohne Mehraufwand.
Tests inklusive
Kritische Plugin-Funktionen werden mit PHPUnit abgedeckt. Was zählt als kritisch?
- Datenbankoperationen
- Berechnungslogik
- Berechtigungsprüfungen
- externe API-Aufrufe
- Migrations-Routinen
Tests für diese Bereiche gehören fest zur Lieferung.
Darüber hinaus laufen manuelle Integrationstests auf einer Staging-Umgebung, die Ihre Produktiv-Konfiguration abbildet: gleiche WordPress-Version, gleiche aktiven Plugins, gleiche PHP-Version. Wir testen Aktivierung, Deaktivierung und Deinstallation des Plugins explizit - Datenbank-Reste nach Deinstallation sind ein häufiger Fehler, den wir systematisch ausschließen.
Plugin-Ownership: Ihr Code, Ihre Kontrolle
Nach vollständiger Bezahlung übergeben wir das komplette Repository: alle Quelldateien, die Git-Historie, Konfigurationsdateien, Test-Suite und Build-Scripts. Sie erhalten das uneingeschränkte Nutzungs- und Bearbeitungsrecht. Keine Lizenzgebühren, keine monatlichen Kosten für die Weiternutzung, keine Abhängigkeit von uns für Basis-Funktionen.
Wenn Sie das Repository in Ihrer eigenen GitHub- oder GitLab-Instanz führen möchten, richten wir das auf Wunsch ein - inklusive Branch-Strategie und Deployment-Pipeline zu Ihrer WordPress-Instanz. Ihr Code, Ihr Versionsstand, Ihre CI/CD-Regeln.
Die Entwickler-Dokumentation umfasst:
- eine
README.mdmit Setup-Anleitung - eine API-Referenz für alle öffentlichen Hooks und Funktionen
- eine Beschreibung der Architektur-Entscheidungen
Wer das Plugin sechs Monate nach Übergabe selbst erweitern will, muss sich nicht durch undokumentierten Code arbeiten.
Wartung und Weiterentwicklung bieten wir als separaten Vertrag an - aber nur als Option, nie als Pflicht. Wer das Plugin intern pflegen oder an eine andere Agentur übergeben will, ist dazu berechtigt und bekommt von uns alle Unterlagen, die das ermöglichen.
Wann Plugin und
wann nicht.
Nicht jeder Use-Case braucht ein Custom-Plugin. Wo eine Konfiguration oder ein Snippet reicht, sagen wir das.
Wir bauen nicht für jeden Use-Case ein Custom-Plugin. Ein eigenes Plugin macht Sinn, wenn der Use-Case einzigartig ist, kein aktiv gepflegtes Plugin auf dem Markt die Anforderungen erfüllt und das Vorhaben dauerhaft Teil Ihrer WordPress-Infrastruktur werden soll.
Wenn ein bestehendes, gut gepflegtes Plugin mit 50.000 aktiven Installationen und einem aktiven Support-Forum Ihre Anforderungen zu 90 Prozent abdeckt, ist Custom-Entwicklung für die restlichen 10 Prozent in den meisten Fällen der schlechtere Weg. Dann ist das richtige Vorgehen: das existierende Plugin konfigurieren und die Lücke mit einem kleinen Custom-Snippet oder einem Action-Hook schließen.
Wenn es rein um Design und Layout geht, ist ein Custom-Plugin fast nie die Antwort. Das ist Sache des Themes. Ein Plugin, das ausschließlich Styles oder Markup verändert, ohne eigene Logik zu liefern, ist eine Architektur-Entscheidung, die Sie später bereuen werden. Wir sagen das auch dann, wenn ein Auftraggeber explizit ein Plugin möchte - und erklären warum.
Vom Briefing zur
Auslieferung.
Vier Phasen, kein Raten. So läuft ein Plugin-Projekt bei uns ab.
01.
Anforderungs-Workshop.
01
Erst verstehen,
dann schreiben.
Wir beginnen mit einem strukturierten Workshop: Was soll das Plugin leisten? Welche User-Flows löst es ab? Welche Daten verarbeitet es und woher kommen sie? Welche bestehenden Plugins und Themes sind betroffen? Je genauer das Briefing, desto präziser das Ergebnis - und desto weniger Nacharbeiten entstehen.
Wir klären im Workshop auch technische Constraints: Welche PHP-Version läuft auf dem Server? Wird Multisite benötigt? Müssen spätere Nutzer das Plugin selbst pflegen können? Gibt es Datenschutz- oder Complianceanforderungen, die die Architektur beeinflussen?
Am Ende des Workshops steht ein schriftliches Anforderungsdokument, das beide Seiten gemeinsam freigeben. Wer sich nicht sicher ist, ob Custom-Entwicklung der richtige Weg ist, bekommt von uns eine klare Einschätzung inklusive Alternativen.
02. Architektur und
Architektur und
Planung.
02
Struktur vor
Code.
Auf Basis der Spezifikation entwerfen wir die Plugin-Architektur: Klassen-Struktur, Hook-Strategie, Datenbank-Schema, Admin-Interface-Konzept, REST-Endpoints. Das klingt akademisch, ist aber der Unterschied zwischen einem Plugin, das in drei Jahren noch wartbar ist, und einem, das nach dem ersten Major-Update neu geschrieben werden muss.
Wir prüfen in dieser Phase, ob Multisite-Kompatibilität, Internationalisierung, Caching-Kompatibilität oder spezifische Sicherheitsanforderungen besondere Architektur-Entscheidungen erfordern. Nachträgliches Umbauen für diese Anforderungen kostet ein Vielfaches mehr als frühzeitiges Einplanen.
Sie bekommen den Architektur-Entwurf zur Freigabe. Erst nach Ihrem OK beginnt die eigentliche Entwicklung. Keine Überraschungen bei der Abnahme.
03. Entwicklung
Entwicklung
mit Tests.
03
Code, der
beweisbar funktioniert.
Wir entwickeln nach WordPress Coding Standards, mit PHPDoc-Kommentaren und einer Testabdeckung für kritische Funktionen. Während der Entwicklung bekommen Sie Zugang zu einer Staging-Umgebung und können den Entwicklungsstand jederzeit testen - Sie müssen nicht auf eine finale Version warten, um Feedback zu geben.
Sicherheitsrelevante Bereiche erhalten besondere Aufmerksamkeit: Datenbankzugriffe laufen ausschließlich über vorbereitete Statements mit wpdb-Methoden, Formulardaten werden konsequent sanitiert und escaped, Benutzerrollen-Prüfungen erfolgen an jedem sensiblen Einstiegspunkt. Keine Abkürzungen bei Security.
Wir führen Pull-Request-Reviews durch und halten die Git-Historie sauber und nachvollziehbar. Wenn Sie einen eigenen Entwickler im Team haben, kann dieser den Review-Prozess mitverfolgen.
04. Auslieferung
Auslieferung
und Wartung.
04
Übergabe mit
vollem Eigentumsrecht.
Nach Abnahme erhalten Sie das vollständige Repository mit Dokumentation, Test-Suite und Build-Scripts. Der Code gehört Ihnen - ohne Lizenzgebühren, ohne Abhängigkeit von uns für den laufenden Betrieb.
Auf Wunsch richten wir einen optionalen Wartungsvertrag ein: regelmäßige Kompatibilitätsprüfungen bei WordPress-Major-Updates, Bugfixes und kleinere Erweiterungen im vereinbarten Umfang. Das ist eine separate Vereinbarung, keine Bedingung für die Übergabe des Codes.
Wer das Plugin künftig intern pflegen oder an einen anderen Dienstleister übergeben will, bekommt von uns eine Übergabe-Session und vollständige Entwicklerdokumentation. Wir bauen nichts, das nur wir verstehen.
Bevor wir
anfangen.
Was kostet ein Custom-Plugin?
Das hängt stark vom Umfang ab. Ein Plugin mit klar abgegrenzter Funktion - etwa ein Custom-Block mit einem definierten Datenmodell - liegt in einem anderen Bereich als eine vollständige ERP-Anbindung mit bidirektionalem Datenaustausch, Fehlerbehandlung und Admin-Interface. Wir nennen keinen Pauschalpreis ohne Briefing. Nach dem Anforderungs-Workshop erhalten Sie ein konkretes Angebot mit Aufwand und Zeitrahmen.
Ist das Plugin Multisite-tauglich?
Auf Wunsch ja. Multisite-Kompatibilität erfordert einige spezifische Architektur-Entscheidungen: Tabellenstruktur pro Blog vs. global, Benutzerrechte auf Netzwerk-Ebene, Options-Verwaltung mit site_option statt option. Diese Anforderung muss frühzeitig im Prozess bekannt sein - nachträglicher Umbau ist aufwändig. Wenn Sie ein WordPress-Netzwerk betreiben oder planen, geben Sie das im ersten Briefing an.
Welche WordPress-Versionen werden unterstützt?
Wir entwickeln gegen die aktuelle stabile WordPress-Version und prüfen Abwärtskompatibilität für die zwei vorherigen Major-Releases. Ältere Versionen prüfen wir auf Anfrage - erfordern aber je nach Ausgangsstand zusätzlichen Aufwand. Grundsätzlich empfehlen wir, WordPress aktuell zu halten. Ein Plugin, das auf einer alten Version läuft, ist kein Argument gegen Updates, sondern ein Sicherheitsrisiko.
Was ist mit künftigen WordPress-Updates?
Wir entwickeln nach Coding-Standards, nutzen keine deprecated Funktionen und greifen nicht in Core-Dateien ein. Das reduziert das Risiko bei WordPress-Updates erheblich. Eine 100-Prozent-Garantie für alle zukünftigen Versionen kann niemand geben - WordPress ändert sich. Deshalb bieten wir optionale Wartungsverträge an, die regelmäßige Kompatibilitätsprüfungen nach Major-Releases beinhalten.
Gehört mir der Code nach Fertigstellung?
Ja. Nach vollständiger Bezahlung übergeben wir das vollständige Repository inklusive aller Quelldateien, der Git-Historie, Test-Suite und Dokumentation. Sie haben das uneingeschränkte Nutzungs- und Bearbeitungsrecht - ohne Lizenzgebühren, ohne Abhängigkeit von uns für den laufenden Betrieb.
Was wenn ich das Plugin später selbst pflegen will?
Kein Problem. Der Code ist nach WordPress Coding Standards strukturiert und dokumentiert. Jede öffentliche Funktion und jeder Hook ist mit PHPDoc kommentiert. Auf Wunsch machen wir eine Übergabe-Session mit Ihrem Entwicklerteam, erklären die Architektur und beantworten Fragen. Wir bauen nichts, das nur wir verstehen.
Open Source oder proprietär - was empfehlen Sie?
Das entscheiden Sie, nicht wir. Wenn Sie den Code im WordPress-Plugin-Verzeichnis veröffentlichen wollen, unterstützen wir das: Readme-Datei, Screenshots, Versionierungsstruktur nach WordPress.org-Standard. Wenn Sie den Code intern halten wollen, ist das ebenso möglich. Für individuelle Use-Cases - vor allem mit proprietärer Geschäftslogik - empfehlen wir in der Regel den proprietären Weg, schon allein um keine Implementierungsdetails offenzulegen.
Sind Tests inbegriffen?
Ja. Für kritische Funktionen schreiben wir PHPUnit-Tests als Teil der Lieferung: Datenbankoperationen, Berechnungslogik, Berechtigungsprüfungen, externe API-Aufrufe. Der genaue Umfang der Testabdeckung wird im Anforderungs-Workshop abgestimmt. Manuelle Abnahmetests auf Ihrer Staging-Umgebung sind immer Teil des Prozesses, unabhängig vom automatisierten Testumfang.
Block-Editor (Gutenberg) oder ACF - was empfehlen Sie?
Das kommt auf den Use-Case an. Native Gutenberg-Blocks sind zukunftssicherer, besser in den Core integriert und ohne Plugin-Abhängigkeit. Sie sind aber aufwändiger zu entwickeln - JavaScript-Kenntnisse für den Inspector und den Editor-Modus sind notwendig. ACF ist schneller zu bauen, vor allem für datenintensive Felder, bringt aber eine Plugin-Abhängigkeit mit. Für Projekte, bei denen Redakteure langfristig Inhalte pflegen, empfehlen wir in der Regel native Blocks. Für Konfigurationsseiten und Back-End-lastige Datenstrukturen kann ACF der pragmatischere Weg sein.
Können REST-API-Endpunkte für ein Headless-Setup entwickelt werden?
Ja. Custom REST-Endpoints sind ein häufiger Use-Case - für Headless-WordPress-Setups mit Next.js oder SvelteKit als Frontend, für mobile Apps oder für externe Dienste, die Daten aus WordPress abrufen oder schreiben sollen. Wir definieren Response-Struktur, Authentifizierung (Application Passwords, JWT oder eigene Token-Logik), Permissions und Rate-Limiting nach Ihren Anforderungen.
Wie läuft eine ERP-Anbindung konkret ab?
Wir beginnen mit der API-Dokumentation des Drittsystems und einem genauen Verständnis der Datenpfade: welche Daten fließen wohin, in welcher Frequenz, wie werden Konflikte aufgelöst, wie werden Fehler behandelt. Dann modellieren wir die Schnittstelle auf WordPress-Seite, implementieren das Sync-System mit Logging und Fehler-Queuing und testen auf einer Staging-Umgebung mit realen Testdaten. Vor dem Go-Live gibt es immer eine kontrollierte Testphase mit Ihrer IT.
Plugin-Werkstatt
Code mit Bestand.
Custom-Plugins sind keine Wegwerf-Ware. Sie bleiben oft länger im Einsatz als die Webseite drumherum. Deshalb schreiben wir sie so, dass jemand anderes sie in drei Jahren noch lesen, ändern und übergeben kann. Tests, Dokumentation, semantische Versionierung - kein Self-Service-Geheimwissen.