Laravel.

Laravel ist ein quelloffenes PHP-Framework für Webanwendungen, das dem MVC-Muster folgt und die wiederkehrenden Teile einer Anwendung ab Werk mitbringt: Routing, Datenbankzugriff über das Eloquent-ORM, versionierte Migrations fürs Schema, Queues für Hintergrundarbeit, die Kommandozeile Artisan, Validierung, Authentifizierung und ein Rechtesystem. Taylor Otwell hat es 2011 veröffentlicht, es steht unter MIT-Lizenz.

Wichtig für die Einordnung: Laravel ist kein fertiges Produkt, das man installiert und befüllt. Es ist ein Gerüst mit klaren Konventionen — wo Code hingehört, wie Daten geladen werden, wie eine Anfrage durch die Anwendung läuft. Diese Konventionen sind der eigentliche Wert: Zwei Entwickler, die Laravel kennen, finden sich in einem fremden Projekt nach wenigen Minuten zurecht. Wie das Framework in unseren Stack passt und wann eine Eigenentwicklung überhaupt sinnvoll ist, steht im Überblick unter PHP & Laravel.

Die häufigste Ursache für eine Laravel-Anwendung, die nach zwei Jahren niemand mehr anfassen will, ist immer dieselbe: Controller, in denen alles steckt — Validierung, Rechteprüfung, Fachlogik, Datenbankzugriff, E-Mail-Versand. Das funktioniert bis zur dritten Änderungsanfrage. Deshalb ziehen wir die Schichten von Anfang an auseinander: Der Controller nimmt die Anfrage entgegen und gibt eine Antwort zurück — mehr nicht. Die Fachlogik liegt in Services und Actions, also in Klassen mit einer Aufgabe und einem Namen, der sie verrät.

Alles, was von außen kommt, wird vorher gefiltert. Eingaben laufen durch Form Requests — ein Ort pro Formular, an dem die Regeln und die deutschen Fehlermeldungen stehen, statt verstreut über Controller und Template. Berechtigungen liegen in Policies: „Darf dieser Nutzer diesen Datensatz bearbeiten?" wird einmal beantwortet und überall gleich geprüft, im Controller wie im View. Das Datenmodell selbst führen wir über Migrations, damit lokal, Staging und Produktion denselben Stand aufbauen und keine Änderung von Hand nachgeklickt wird.

Alles Langsame verlässt den Request: PDF-Erzeugung, Bildverarbeitung, Mailversand, der Aufruf einer fremden API wandern in Queues. Der Nutzer bekommt sofort eine Antwort, ein Worker erledigt die Arbeit nebenläufig, fehlgeschlagene Jobs landen nachvollziehbar in der Fehlertabelle statt still zu verschwinden. Wiederkehrende Aufgaben — nächtliche Importe, Reports, Aufräumläufe — bauen wir als eigene Artisan-Befehle und hängen sie in den Scheduler.

Abgesichert wird das über Tests: nicht flächendeckend, sondern dort, wo Geld, Rechte oder Daten im Spiel sind. Diese Tests laufen bei jedem Push über Git und GitHub Actions, bevor irgendetwas live geht. Beim Schreiben helfen uns Copilot, Cursor und Claude — jeder Stand wird von einem Menschen gelesen, bevor er gemergt wird. Wie wir mit KI-gestützter Entwicklung arbeiten, steht im eigenen Stack-Kapitel.

Der typische Fall ist ein Projekt, in dem nicht Seiten den Kern bilden, sondern Objekte, Filter und Regeln. Für die Garbe-Gruppe haben wir ein Karten-Portal auf Basis von Mapbox und OpenStreetMap gebaut — Standorte, Datensätze, Suchlogik, eine Schnittstelle dahinter. In so einem Projekt arbeitet ein CMS gegen sich selbst; ein Framework bildet die Fachwelt direkt ab. Alle Referenzen stehen unter Cases.

Der zweite, weniger offensichtliche Fall: Laravel läuft auch dort mit, wo man es nicht sieht. Statamic ist kein eigenes System, sondern ein Laravel-Paket — unter jeder Statamic-Website steckt eine vollständige Laravel-Anwendung. Genau das nutzen wir: Redaktion und eigene Fachlogik im selben Projekt, ohne Systemwechsel, wenn aus einer Website später ein Kundenbereich oder eine Formularstrecke wächst.

Und wo Inhalt wirklich der Kern ist, gehen wir den anderen Weg: Der Konzern-Auftritt von Spelsberg läuft seit 2018 auf TYPO3 in 13 Sprachen, angebunden an PIM, Cadenas, Algolia und Hubspot. Redaktion, nicht Fachlogik — ein Framework wäre dort der Umweg gewesen.