Ich wollte ein modernes WordPress Plugin mit React und PHP-DI entwickeln. Ziel war saubere Architektur, testbare Komponenten und zukunftssichere Struktur ohne das typische WordPress-Chaos. Doch je tiefer ich einstieg, desto klarer wurde: Ich baue nicht nur ein Plugin. Ich kämpfe gegen das Ökosystem. Und am Ende entstand daraus: Ein vollständiges Plugin-Skeleton für moderne WordPress-Entwicklung.
Kein Dev.to-Plugin für WordPress – also baute ich ein WordPress Plugin mit React und PHP-DI
Was mich zum Projekt brachte, war eigentlich eine Kleinigkeit: Ich wollte meine Dev.to-Beiträge direkt aus WordPress heraus veröffentlichen können. Doch trotz des riesigen WordPress-Ökosystems gab es kein einziges Plugin dafür nicht einmal ein simples Auto-Publishing-Tool mit Dev.to-Integration.
Ich dachte: Wie schwer kann das sein? Also fing ich an und landete tiefer in der WordPress-Architektur, als mir lieb war.
WordPress verhindert moderne Plugin-Architektur mit React und PHP-DI
Je tiefer ich einstieg, desto klarer wurde mir: WordPress ist kein Freund moderner Softwareentwicklung. Es will gar kein sauberes System sein. Es lebt von Chaos und verteidigt es aktiv:
- Kein Composer, keine externen Abhängigkeiten erlaubt
- Kein PSR-konformes Autoloading – alles global
- Keine Dependency Injection
- Keine Events, keine Services – nur Hooks
Was viele als „Einfachheit“ verkaufen, ist in Wahrheit eine veraltete und schwer wartbare Struktur, die moderne PHP-Standards ignoriert.
Architektur mit PHP-DI und React – mein Ansatz für ein zukunftsfähiges WordPress Plugin
Ich wollte es anders machen. Ich wollte ein Plugin schreiben, das nicht aussieht wie ein Plugin sondern wie ein modernes, testbares PHP-Projekt. Also entschied ich mich für:
- Hexagonale Architektur mit klaren Modulgrenzen
- Trennung von Domain, Application, Infrastructure
- PSR-4 Autoloading mit Composer
- PHP-DI als Dependency Injection Container
- Logging mit Monolog
- Markdown-Konvertierung mit League\CommonMark
- Publisher-Strategien (Dev.to, Mastodon, LinkedIn)
Mein Ziel war: Eine Architektur, die auch unabhängig von WordPress funktioniert oder irgendwann davon ganz losgelöst werden kann.
Die Realität? Ich kämpfte mehr gegen WordPress als mit meinem eigentlichen Code.
Warum mein WordPress Plugin mit React und PHP-DI nie offiziell erschien
Die erste Version war irgendwann fertig: github.com/N3XT0R/WP-XPub/tree/1.0.0
Eigentlich wollte ich sie gar nicht als „1.0.0“ releasen aber WordPress verlangt das für Plugin-Uploads. Also passte ich die Version an. Und schickte sie ein.
Doch ich kam nicht mal bis zum Review-Team. Die automatische Validierung beim Upload schlug jedes Mal fehl und das in Salami-Taktik. Statt alle Fehler auf einmal auszugeben, wurde mir immer nur ein einzelner Fehler angezeigt. Also: Upload, Fehler beheben, alle Checkboxes neu setzen, wieder hochladen und dann die nächste Meldung. Immer und immer wieder.
Fazit: Moderne Architektur war nicht das Problem – ich kam nicht einmal bis zur Diskussion darüber.
Also entschied ich mich gegen den offiziellen Upload. Und für meine eigene Update-Logik über GitHub.
Vom manuellen Service-Wiring zum PHP-DI Plugin-Skeleton für WordPress
Anfangs hatte ich alle Services manuell verdrahtet. Dann wurde es zu viel. Ich wechselte auf PHP-DI ein vollwertiger Dependency Injection Container mit Caching, Proxy-Generierung und klarer Struktur.
Weil ich sowieso nicht mehr auf die WordPress-Standards angewiesen war, konnte ich modern entwickeln und das tun, was in Symfony, Laravel oder Slim längst Standard ist.
React + Vite statt PHP-Templates: Modernes Frontend im WordPress Plugin
Ursprünglich hatte ich PHP-basierte Views aber das war mir zu statisch und zu fragmentiert. Ich stellte auf React um mit Vite als Bundler. Das Frontend wird nun als modulare App ausgeliefert – dynamisch, wiederverwendbar, testbar.
Natürlich kam das nächste Problem direkt hinterher: WordPress lädt JavaScript-Dateien kreuz und quer. Eine echte Dev-Umgebung mit Hot-Reload war kaum sauber integrierbar.
Also entwickelte ich meinen eigenen ReactAppLoader. Der erkennt die Umgebung (Development vs. Production) und lädt entweder die lokalen Vite-Module oder gebaute Assets aus dem dist-Verzeichnis – inklusive CSS und Initialdaten.
So lässt sich eine moderne React-App vollständig in WordPress integrieren, ohne auf Skript-Hacks oder Workarounds angewiesen zu sein.
Übersetzungen mit React im WordPress Plugin – eine (fast) unlösbare Aufgabe
Wer glaubt, die Integration von React in WordPress sei schon das Ende der Fahnenstange, der hat noch nie versucht, Übersetzungen (.po/.mo) sauber in eine moderne React-App einzubinden.
Ich bin beim Thema Internationalisierung (i18n) in eine Wand gelaufen: WordPress verlangt, dass pro Eintrag in der .po-Datei ein Kommentar existiert, der auf die entsprechende .jsx-Datei verweist selbst wenn die eigentliche Quelle eine .ts(x) oder .js(x) ist.
Wer zum Henker soll das wissen?
Es steht nirgends richtig dokumentiert. Ich musste die wp-cli i18n-Befehle debuggen, um überhaupt zu verstehen, was da passiert. Ohne diesen Schritt hätte ich nie herausgefunden, warum bestimmte Strings einfach nicht übersetzt wurden.
Als ich es irgendwann geschafft hatte, .json-Dateien mit den richtigen Übersetzungen zu erzeugen, trat das nächste Problem auf: WordPress fand die Dateien nicht.
Also baute ich einen eigenen Loader in JavaScript, der die JSON-Dateien zur Laufzeit lädt und mit @wordpress/i18n registriert.
OAuth und Client-IDs im Klartext? Nicht mit meinem WordPress Plugin
Beim Einbau von OAuth-Authentifizierungen fiel mir etwas Erschreckendes auf: Praktisch alle Plugins im WordPress-Hub hardcoden ihre client_id und client_secret. Das LinkedIn-Plugin wp-linkedin-auto-publish etwa nutzt für alle Nutzer eine Organisation aus Florida.
Ich wollte es besser machen – über eigene OAuth-Strategien im Plugin, sauber gekapselt als Strategy Pattern. Sicher, modular und verständlich.
Fazit: Mein Plugin-Skeleton für moderne WordPress Plugins mit React und PHP-DI
WP‑XPub ist funktionsfähig – aber das wirklich Spannende ist die Infrastruktur darunter. Ich habe mir eine Umgebung geschaffen, in der WordPress-Entwicklung nicht weh tut. In der PHPUnit läuft. In der Logging und Fehlerbehandlung möglich sind. In der man Code schreiben kann, der auch in drei Jahren noch lesbar ist.
Das Plugin war nur der Aufhänger. Was entstanden ist, ist ein vollständiges, modernes Plugin-Skeleton – ein Startpunkt für alle, die WordPress nutzen müssen, aber sich nach sauberem Code sehnen.
Und genau deshalb habe ich aus den Erfahrungen rund um WP‑XPub das wp-modern-plugin-skeleton gebaut um anderen diese Schmerzen zu ersparen und eine Grundlage für saubere, zukunftssichere Plugins zu schaffen.
👉 Plugin + Architektur: github.com/N3XT0R/WP-XPub
👉 Plugin Skeleton für moderne WordPress Plugins mit React und PHP-DI: github.com/N3XT0R/wp-modern-plugin-skeleton
Wenn du das hier liest und dir denkst: Genau das fehlt mir seit Jahren – dann schau rein. Fork es. Nutze es. Oder bau es um.
Denn WordPress wird sich nicht ändern. Aber wie wir damit umgehen – das liegt bei uns.
