WordPress ablösen mit Laravel (und ganz viel KI)

Die Ausgangslage

Ursprünglich habe ich das Projekt von einem Kollegen übernommen, der seine Berufung gewechselt hat und nicht mehr als Webdesigner tätig sein wollte. Anfangs ging es nur um die laufende Wartung, aber mit der Zeit wünschte sich der Kunde auch funktionale Erweiterungen.

Die WordPress-Website ist eigentlich keine Website, sondern ein aufwendiges, komplexes Formular, mit dem Mitarbeiter selbst PDFs erstellen können. Inklusive Unterformularen, eigenen Einträgen bei Dropdowns und vielen weiteren Ausnahmen, Annahmen und Regeln.

Ein zusammengeklicktes Legacy-WordPress-Projekt

Das WordPress-Projekt war leider mehr zusammengeklickt als sauber programmiert; die Logik für die “Applikation” fand sich:

• im Child Theme,
• einem eigenen Plugin (!),
• den Vorlagen für die PDF-Erstellung (!)
• sowie direkt in GravityForms
• sowie den Erweiterungen von GravityForms verstreut.

Bei jedem Update habe ich ein Stoßgebet an den Himmel geschickt, dass das Kartenhaus danach noch steht. Bei jeder Änderung oder jedem Bug war unnötig viel Zeit mit der Suche nach der richtigen Stelle und den richtigen Zusammenhängen notwendig.

Ein typisches Resultat, wenn man zwar Programmierleistungen anbietet, aber nicht programmieren kann…

Schlampig aufgesetzte WordPress-Projekte gleichen einem wackligen Kartenhaus, das bei jeder kleinen Änderung einstürzen kann.

– Michael Baierl, WordPress-Profi

Neue Anforderungen

Hinzu kamen neue Anforderungen, die schon lange auf der Wunschliste standen, aber nicht umsetzbar waren:

• Login via SSO / Keycloak
• Speichern, bearbeiten und duplizieren von Formularen (aktuell mussten die Formulare bei jeder Änderung komplett neu ausgefüllt werden!)
• Saubere Übergabe von Formularen bei Urlauben und Abwesenheiten
• Erweitertes Reporting und besserer Workflow (anstatt E-Mails manuell zu sammeln und weiterzuleiten)

Die bestehende Lösung (meiner Meinung nach eher ein Prototyp, der es in die Produktion geschafft hat) war schon längst am Ende des Entwicklungszyklus angekommen und der Kunde war offen für eine komplette Neuprogrammierung. Zumal ja eh keine Daten migriert werden mussten.

Überlegungen zur Weiterentwicklung

Als WordPress-Profi versuche ich natürlich zuerst das Problem mit WordPress zu erschlagen, also sehen wir uns die Möglichkeiten der Reihe nach an:

Überlegung: WordPress und ACF Pro

Anstelle von GravityForms würde ich ACF Pro einsetzen, damit könnte ich die Daten in Custom Post Types speichern und die Benutzerverwaltung und Rollen von WordPress nutzen.

Die PDF-Generierung wäre eigener Code (sauber, in EINEM Plugin, nicht verteilt), was sauber umgesetzt endlich auch das sinnvolle Debugging der PDF-Ausgabefehler ermöglichen würde…

Bei näherer Analyse und in Gesprächen mit dem Kunden ergab sich aber das Problem, dass die Nutzer nicht sehr technik-affin sind und sie das WordPress-Backend gerne meiden würden. Ich wäre also eine Zeit lang beschäftigt ein Frontend-Login, Design usw. zu entwickeln oder das Backend von WordPress entsprechend einzuschränken….

Das klingt für mich nach einem Kampf gegen WordPress… warum also nicht WordPress einfach weglassen?

(Kleiner Einschub: das erinnert mich an den Film “Paycheck – Die Abrechnung” mit Ben Affleck, siehe hier für die Schlüsselszene, die ich grandios finde).

Die Alternative: Laravel und ganz viel KI

Im Endeffekt ist das Projekt relativ simpel:

1. Login mit zwei Rollen (Benutzer, Administrator)
2. Daten via Formular eingeben, bearbeiten, verarbeiten, dazu ein paar Regeln, wann die Bearbeitung nicht mehr möglich ist
3. Export der Daten als PDF bzw. als Übersicht für’s Reporting

Warum sollte ich mir die technischen Schulden und Nachteile von WordPress aufhalsen, wenn ich die Formulardaten in eigenen Tabellen speichern und moderne PHP-Tools nutzen kann?

In Absprache mit dem Kunden entstand folgende Alternative:

• Laravel, als moderneres, stabiles PHP-Framework.
• FluxUI für die UI-Komponenten.
• Claude Code mit direktem Zugriff auf den gesamten Code.

Na dann, lass uns schauen, wie weit ich mit dem Ansatz gekommen bin….

Die Migration in 5 Schritten

Schritt 1: Technisches Setup von Laravel

Das erste technische Setup habe ich händisch durchgeführt (wozu Tokens verbraten, ein composer global require laravel/installer laut der ausgezeichneten Doku von Laravel bekomme ich selbst schneller hin und die KI legt mir garantiert kein Git-Repository an….):

1. Laravel installieren.
2. Laravel Boost – das ist der KI-Support für Laravel – aktivieren. Dabei entstehen automatisch Skills im Projektverzeichnis, auf die sich Claude beziehen kann, sowie ein MCP-Server. Claude kann somit auf die Dokumentation uvm. zugreifen.
3. Die CLAUDE.md prüfen und anpassen (z.B. darf Claude ohne Nachfrage keine Pakete – composer, npm – installieren).
4. FluxUI installieren und aktivieren (kleiner Kommentar dazu: ich mag Tailwind CSS gar nicht, aber in dem Fall bin ich über meinen Schatten gesprungen).

Schritt 2: Anforderungen sammeln und niederschreiben

Der zweite, weitaus zeitraubendere Schritt, war es, die Anweisungen für Claude zusammenzutragen. Sprich genau zu erklären, was zu tun ist.

Dazu habe ich die Funktionalität der bestehenden Applikation durchgespielt und niedergeschrieben, zum Beispiel:

...
# User flow (non-admin user)
- Login (mandatory). Logged out users only see the login screen. No registration. 
- After the login the users see see a list of [...] they created (Titel, Ort, Datum & Uhrzeit, Status), sorted by date (oldest on top). Sorting is not needed, pagination possible
- Users can filter the list: Future (incl. today)/Past, Status
- can duplicate existing programs (any program in any status). Duplicates get the status "Entwurf". If the date is in the past it gets unset, so the user must choose a date prior saving.
- can add a new programm (status draft)
- can edit their progams which are:
  - drafts (status "Entwurf"),
  - final (status "Final") if the date is in the future or today.
  - other programs can only be viewed (form fields are read-only, sorting not possible)
...

Du siehst schon, da steckt die ganze Logik drinnen, wann wer welche Daten bearbeiten darf. Weiters habe ich alle Modelle (=Tabellen) und deren Eigenschaften beschrieben, inklusive Anweisungen, woher die initialen Daten zu beziehen sind:

...
# Model: Ort
- has these fields: 
    - Name (string, mandatory)
    - Active (boolean, default true)
    - Created by (User, mandatory, automatically set)
- Can only be deleted by admins if they are not used in any program
- The initial list of entries can be found in the file "ort.txt". Use for seeding.
...

Dazu kamen technische Anweisungen (FluxUI Version 2.0 verwenden, Code und Kommentare in Englisch, Labels für die Benutzer in Deutsch…).

Dieser Prozess hat einiges an Zeit in Anspruch genommen, allerdings hatte ich am Ende eine Datei mit der Business-Logik und Anweisungen für die KI.

Um zu prüfen, ob diese Anweisungen in sich konsistent sind, habe ich – Überraschung – Claude Code befragt:

Analyze the file _instructions/instructions.md and answer the following questions:                                                                                            

  - Do you find any logic errors in the above description? 
  - What else do you need to implement this application?                                                                        
  - How would you implement the subform?
  - ...

Selbstverständlich gab es einige Themen, die mein “Mitarbeiter #2” für mich gefunden hat, die haben wir dann gemeinsam noch ausgebessert…

Schritt 3: Claude Coden lassen

Der nächste Schritt war endlich der, von dem alle KI-Gurus schwärmen. Claude Code programmiert, ich trinke Kaffee. Oder arbeite in der Zwischenzeit an einem anderen Projekt.

Als Claude genug Tokens verbrannt hatte und meinte, er sei fertig, kam die Stunde der Wahrheit. Das Öffnen von http://localhost:8000 … und … die Überraschung, dass alles so umgesetzt war wie gewünscht.

Surprise, es läuft!

Doch die wahre Arbeit stand noch bevor…

Schritt 4: Review, Testing, Anpassungen

Nach diesem ersten Erfolg ging es ans Testen, den Feinschliff und das Implementieren weiterer Funktionen. Und auch an’s Review von dem Code, den Claude produziert hat.

Denn alles andere – Vibe Coding in seiner reinsten Form – ist grob fahrlässig!

Jede (!) Zeile Code, die von KI geschrieben wurde, gehört gelesen und verstanden. Alles andere ist grob fahrlässig.

– Michael Baierl, Website-Programmierer

Dank der MCP-Zugriffe auf die Dokumentation und die Skills folgt der von Claude Code erstellte Code den Laravel-Standards und auch die FluxUI-Komponenten sind vorschriftsgemäß eingesetzt. Da gibt es nicht viel zu bemängeln.

Funktional habe ich natürlich einige Kleinigkeiten übersehen und während der Tests kommen neue Ideen auf. Logging, Backups, Statistiken wurden eingebaut. Auch die Erstellung des PDF-Exports wurde im Erstentwurf der Applikation ausgelassen und als weitere Iteration mit eigenen, längeren Anweisungen umgesetzt.

Warum? Weil der HTML-Code, der zur Erstellung des PDFs verwendet wird, tief in den Quellen des Gravity PDF Addons versteckt war, gemixt mit Einstellungen in WordPress und angerührt mit eigenen Templates… sauber geht anders.

Aber auch hier: mit kleinen Nachbesserungen war die Migration erledigt, die neue HTML-Vorlage für das PDF ist sauberer, wartungsfreundlicher und leichter anpassbar. Ein Erfolg auf ganzer Linie würde ich sagen.

Übrigens, Claude war nach der Coding-Session sehr am Limit:

Schritt 5: Integration und Go-Live

(Noch?) nicht von KI lösbar waren die Installation am Live-Server des Kunden sowie die doch komplexe Integration mit dem SSO-System. Klar, auch hier hat KI bei der Recherche geholfen, aber auch klassische Web-Recherche ist ein Skill, den man als Profi noch beherrschen sollte.

Der Aufwand für die Migration von WordPress zu Laravel

Zeitlicher Aufwand

Da ich meine Arbeitszeit immer minutengenau tracke (und nicht nur grob schätze), gibt es eine Auflistung des Aufwands:

• Analyse und verstehen der Funktionalität: ~2h (plus ein paar Sorgenfalten beim Lösen von Problemen in der Original-App)
• Technisches Setup von Laravel: ~30 Minuten
• Schreiben der Anforderungen für Claude: <2h*
• Coding von Claude: 45 Minuten (!!)*
• Code-Review, Anpassungen, weitere Funktionalität: >10h

* Dies inkludiert nur den ersten Wurf, nicht die Iterationen zum finalen Produkt.

Premium Software

• FluxUI Pro: ca. 150,-, einmalig
• Claude Pro: ca. 20,-/Monat

Verbrannte Tokens

Laufend anfallende Kosten

Im Unterschied zu laufenden Updates bei WordPress ist Laravel sehr pflegeleicht, allerdings müssen ebenso regelmäßig Sicherheits- und Paketupdates (composer update; php artisan test; dep deploy;) eingespielt werden. Aufwand bei dieser kleinen App ca. 15 Minuten / Monat, eher weniger.

Laravel Major Upgrades benötigen etwas mehr, aber nicht übertrieben viel, Aufwand. Mit ca. 2-3h pro Jahr musst du hier rechnen.

Fazit & Learnings

Das Wichtigste zuerst: ich bin WordPress zwar wieder untreu geworden, allerdings bin ich nach wie vor ein WordPress-Fan. Es geht hier nicht um “WordPress vs. Laravel”, sondern darum, das richtige Werkzeug für das richtige Problem zu nutzen, anstatt stur mit einem Hammer ständig Schrauben in die Wand schlagen zu wollen.

Learning 1: KI ist (d)eine Superkraft!

Allerdings nur, wenn es (wie bei Laravel) gute Skills gibt und du klare Leitplanken vorgibst. Die CLAUDE.md muss passen. Du solltest auch genau vorgeben, welche Pakete verwendet werden dürfen.

Du als Entwickler bist in der Verantwortung und sitzt am Steuer, auch wenn die KI den Prozess antreibt und beschleunigt. Daher ist auch JEDE Zeile Code zu lesen und zu prüfen.

Learning 2: Es ist trotzdem Aufwand und schafft einen Wert

Trotz KI sind solche Projekte nicht “in 5 Minuten erledigt”. Klar, die Zeit wird kommen, wenn Claude dieselbe Programmieraufgabe viel schneller erledigt. Aber das ist, wie du oben siehst, der geringste Teil. Ob Claude jetzt 45 Minuten oder 5 Minuten beschäftigt ist, macht nicht wirklich einen Unterschied.

Das Verstehen der Anforderungen, das Übersetzen in Anweisungen und das Kontrollieren des Ergebnisses, die Tests, Kommunikation mit dem Kunden, Integration in externe Systeme… all das frisst nach wie vor Zeit und benötigt Expertise.

Nur der Teil des Programmierens, früher locker 2 Wochen, ist jetzt dank Claude ruck zuck erledigt…

Learning 3: Du musst nach wie vor am Steuer sitzen

Ganz ohne Wissen und Erfahrung wird das Ergebnis eine Black Box aka “Vibe-Coding”. Das ist nicht professionell, sondern nur grob fahrlässig. Du solltest also schon wissen, was du tust und Grundkenntnisse der Tools haben, die du einsetzt.

Egal, ob es sich um Novamira, WordPress, Laravel oder Statamic handelt…

Fazit des Fazits :-)

Die Migration von WordPress/GravityForms zu Laravel war definitiv die richtige Entscheidung. Neue Anforderungen sind rasch umgesetzt, das System läuft stabil und vor allem: die Kunden und Nutzer sind zufrieden.

Und darum geht’s letztendlich.

Fragen zur Ablöse von WordPress mit Laravel