TYPO3 ist mehr als ein CMS
Business-Anwendungen mit dem TYPO3-Backend bauen.
Ich möchte nur einen anderen Blick anbieten.
Die DevDays sind der richtige Ort für unfertige Ideen — ein Experiment, ein paar Entscheidungen und einiges, das nicht funktioniert hat. Das ist keine Produktankündigung.
Nehmt die Ideen mit, die euch nützen. Manchmal brauchen wir kein neues Werkzeug — wir müssen dasselbe Objekt nur von einer anderen Seite betrachten.
Letzte Weihnachten…
…beschloss ich, die Winterpause mit Vibecoding zu verbringen — unser eigenes ERP-, Zeiterfassungs- und „Alles“-Tool zu bauen. Mit einem echten Projekt, nicht mit einem Tutorial.
Ich wollte keinen Vortrag schreiben. Ich habe mich hingesetzt, weil mich etwas bei der Arbeit sehr lange gestört hatte.
Ein System, das uns nicht mehr folgte.
Wir betrieben ein normales ERP. Über die Jahre änderten sich unsere Prozesse, das System nicht. Antworten dauerten lange, Änderungen noch länger, und die Berichte, die wir brauchten, waren nur schwer zu bekommen.
Und dann, in jenem Dezember, erreichte ich sie gar nicht mehr. Da hörte ich auf zu warten. Das Produkt war in Ordnung — es war nur nicht unser Produkt.
Der Entwickler in mir — und der Geschäftsführer in mir.
Der Entwickler will: Kontrolle über den Code, Fokus auf die Anwendungslogik und ein getestetes, sicheres Framework, das einfach zu benutzen bleibt.
Der Geschäftsführer will: schnelle Ergebnisse, weniger Lizenzkosten, keine Zeit für triviale Grundfunktionen verschwenden — einfach Wert schaffen.
„Das gibt es in TYPO3 schon.“
Mein erster Impuls war Symfony — es ist hervorragend, und TYPO3 nutzt viele seiner Komponenten. Das ist kein Symfony-gegen-TYPO3-Kampf. Aber bei jeder Fähigkeit, die ich auflistete — Admin-Oberfläche, Benutzer & Rechte, Modulnavigation, Datensatzbearbeitung, Listen, geplante Aufgaben, Logging, Dashboards — kam derselbe Satz zurück.
Warum neu bauen, was ich schon habe, was schon getestet ist und was ich schon kenne?
Und womit baut man das überhaupt?
Der Assistent, der es schreibt — Gemini, Claude, ChatGPT, Kimi?
Das Framework darunter — Symfony, .NET, React?
Stellt euch vor, TYPO3 ist nicht „nur“ ein CMS, sondern ein Framework für Anwendungen.
Stellt euch TYPO3 ohne Inhalt vor. Keine Seiten. Keine Inhaltselemente. Keine Website.
Was bleibt übrig?
Wenn die Antwort „nichts“ lautet, ist dieser Vortrag in zwei Minuten vorbei. Statt zu raten, schauen wir uns an, wie TYPO3 tatsächlich zusammengesetzt ist — Composer verrät uns den Großteil der Antwort.
Wo die Teile wirklich liegen.
Modernes TYPO3 ist eine Menge von Composer-Paketen. Seiten liegen tief im Core; tt_content — die Inhaltselemente — kommen aus dem Frontend-Paket. Inhalt ist Frontend-Sache; Seiten sind Core-Sache. Das Frontend ist also der Teil, den wir wegnehmen können.
Ja.
Technisch hängt nichts Grundlegendes davon ab. Die Abhängigkeit läuft andersherum — das Frontend hängt vom Core ab, nicht der Core vom Frontend. Das ist kein Hack; das ist die Architektur, wie sie gedacht ist.
Vieles nutzt es doch.
# das Fundament braucht das Frontend nicht —
# aber viel Code drumherum setzt es voraus.
RuntimeException: No site configuration found for request
TypeError: a rendering context was expected
Error: a page id is required (pid)…
Zwei Dinge sind gleichzeitig wahr: TYPO3 hat eine mächtige Backend-Plattform, die das Frontend nicht braucht — und es ist (noch) nicht als vollwertiges Backend-only-Produkt gedacht. Nicht kaputt; außerhalb des Hauptanwendungsfalls genutzt.
Dinge, die du beim TYPO3-Backend von Haus aus bekommst.
Das sind die Dinge, für die du keinen Cent ausgeben musst — vom Framework abgedeckt, getestet und sicher.
Identität & Zugriff.
Eine Business-Anwendung muss wissen, wer ihr seid und was ihr sehen und ändern dürft. Ich habe keine Auth-Schicht erfunden — ich habe eine erweitert, die viele Menschen über viele Jahre geprüft haben.
TCA macht aus einer Datenstruktur ein nutzbares Backend.
Beschreibt eine Tabelle mit TCA, und die FormEngine erzeugt eine funktionierende Bearbeitungsoberfläche — samt Datensatzliste für jede Tabelle. Ehrliche Warnung: Das ersetzt kein UX-Design. Aber der Unterschied zwischen über ein Formular nachdenken und ein Formular-Framework bauen ist enorm.
Arbeit passiert, während niemand hinsieht.
Nächtliche Importe. Eine Reaktion, wenn Geld eingeht. Eine Benachrichtigung an ein anderes System. Die Planung und ihre Verwaltung existieren bereits. Und ein neues Modul ist keine neue Architektur — ein Controller, ein Repository, ein Fluid-Template, eine TCA-Definition. Alles andere ist entschieden.
Der technische Unterbau.
Niemand führt Logging vor. Aber wenn morgens um sieben in der Produktion etwas kaputtgeht, ist das die Schicht, nach der ihr greift — und sie war von Tag eins an da.
Das Anwendungsfundament existiert bereits.
TYPO3 lässt uns näher am Geschäftsproblem starten. Vier Fundament-Schichten, eine dünne Schicht obendrauf — und diese dünne Schicht ist der einzige Teil, bei dem es wirklich um mein Geschäft geht.
DigiTrack — läuft auf TYPO3 14.
Keine Website. Keine Inhaltselemente. Nur das Backend. Kein Konferenz-Prototyp — wir betreiben damit unsere Firma. Alles Vertraute kam von TYPO3; alles Unvertraute ist unser Geschäft.
Das Backend ist die ganze Anwendung.
Aus TYPO3-Paketen gebaut.
Controller fragen die Datenbank nicht ab — Business-Logik steckt in Services, Datenzugriff in Repositories. Deshalb ist der Code auch nach einem Jahr schneller Änderungen noch verständlich.
Jetzt der praktische Teil.
Ein Blocker. Ein Workaround. Drei Ideen.
pid
Gespeichert als Parent-ID. Behandelt als Page-ID. Berechtigungen, der Seitenbaum, der Modulkontext — alle setzen das voraus. Eine Anwendung ohne Seiten hakt an diesem einen Feld. pid ist nicht falsch; für ein CMS ist es richtig.
Die Grenze ist die Organisation, nicht die Seite.
record.pid = 0 # keine Seite, kein Baum
record.organisation = currentOrganisation # beim Speichern per DataHandler-Hook gesetzt
# jeder Lese- & Schreibzugriff ist auf die Organisation begrenzt — man kann es nicht vergessen.
Alles wird außerhalb des Seitenbaums gespeichert. Die Zugehörigkeit wandert in unseren eigenen Kontext: In einem CMS ist die Grenze die Seite — in DigiTrack die Organisation. Es ist ein Workaround, und ich nenne ihn auch so. Aber er ist klein und eingegrenzt.
Drei Dinge, die wir fürs Backend gebaut haben.
1. Backend-User-Einladung — eine kleine Extension, die wir veröffentlichen: Redakteure per E-Mail einladen und ihre Gruppen wählen, statt Konten von Hand anzulegen.
2. Sortierbare Listenspalten — nicht nur auswählen, welche Spalten erscheinen, sondern nach ihnen sortieren. Ein besserer Blick auf die Daten.
3. Filter in der Listenansicht — eine TCA-basierte Logik, um Filter zu definieren und direkt in der Listenansicht anzuwenden.
Geschwindigkeit schneidet in beide Richtungen.
KI und Coding-Agenten ließen mich mehr Code in weniger Zeit bauen. Aber es ist jetzt sehr leicht, Code zu erzeugen, der inkonsistent, unsicher oder nicht wartbar ist — generierter Code bringt kein Sicherheitsmodell mit. Die Folgen eines schwachen Fundaments sind weiterhin teuer.
Ein gutes Fundament verwandelt Entwicklungsgeschwindigkeit in Wert.
Entwicklung wird günstiger, also werden mehr interne Tools möglich. Und weil wir mehr bauen können, zählt die Qualität des Fundaments mehr, nicht weniger.
Die Lizenzersparnis war nicht der größte Gewinn.
Was, wenn das TYPO3-Backend euer Anwendungs-Framework ist?
Entfernt die Website, und ein überraschend vollständiges Fundament bleibt. TYPO3 bleibt ein CMS — das ist seine Stärke. Aber vielleicht können wir aufhören, das Backend nur als den Ort zu sehen, an dem Redakteure Websites pflegen.
Was würdet ihr damit bauen?
Danke.