Extension Builder für TYPO3

Der Extension Builder ist das Scaffolding-Werkzeug, ohne das kein TYPO3-Entwickler wirklich produktiv wird

Der Extension Builder ist seit über zehn Jahren das offizielle Werkzeug, mit dem Entwicklerinnen in TYPO3 neue Extensions aus dem Nichts erzeugen. Wer eine Extbase-Extension mit Domain-Model, Repository, Controller und Backend-Modul benötigt, bekommt über den Extension Builder einen visuellen Editor, der aus einem UML-ähnlichen Domain-Diagramm den kompletten Boilerplate-Code generiert: TCA-Konfiguration, SQL-Schema, ext_localconf, Controller-Stubs, Fluid-Templates, Language-Files. Für Agenturen und Produktteams, die regelmässig eigene Extensions ausliefern, bleibt das Tool der schnellste Weg vom Konzept zum ersten lauffähigen Prototyp.

Die Zielgruppe sind TYPO3-Entwicklungsteams in Agenturen und im Inhouse-Bereich, die über Site Packages hinaus eigene Business-Logik in TYPO3 abbilden. Typisch sind Extensions für Produktkataloge, Event-Management, Job-Portale, Kundenportale oder branchenspezifische Datenstrukturen. Ohne Extension Builder müsste jede dieser Extensions von Hand aus einem leeren Verzeichnis wachsen - mit dem Risiko, dass die Struktur vom TYPO3-Core-Schema abweicht und beim nächsten Upgrade bricht.

Typische Einsatzszenarien

Ein erstes Szenario ist der Prototyp für ein Kundenportal. Ein Maschinenbauer mit 2.000 Ersatzteilen braucht eine Extension, die Produktfamilien, Produkte und Dokumentationen als eigene Datenstrukturen im Backend verfügbar macht. Der Extension Builder erzeugt in unter 30 Minuten das komplette Gerüst: TCA, Repositories, Controller, List- und Detail-Ansicht. Das Team beginnt sofort mit der Business-Logik statt mit Boilerplate.

Ein zweites Szenario ist die Schulungs- und Einarbeitungssituation. Ein Entwickler, der zum ersten Mal eine TYPO3-Extension baut, lernt durch das generierte Scaffold die Konventionen des Frameworks kennen, ohne sich in Dokumentationen zu verlieren. Der generierte Code ist nicht perfekt, aber er ist idiomatisch und zeigt, wie Extbase gedacht ist.

Ein drittes Szenario ist die Migration bestehender Datenstrukturen. Wer aus einem alten CSV-Export eine neue TYPO3-Extension mit zehn Entitäten aufsetzen muss, kann das Domain-Modell im Extension Builder zusammenklicken, exportieren und im Anschluss den generierten Code mit einem Import-Kommando befüllen. Das spart mehrere Personentage gegenüber einem Handaufbau.

Ein viertes Szenario ist die Standardisierung in einem Agentur-Pool. Ein Dienstleister mit 15 TYPO3-Entwicklern möchte sicherstellen, dass jede neue Extension denselben Grundaufbau hat. Der Extension Builder erzwingt diesen Aufbau durch die Generierung, und eigene Templates für den Code-Generator sorgen dafür, dass Code-Style, Lizenz-Header und Verzeichnisstruktur projektübergreifend identisch bleiben.

Technische Architektur

Der Extension Builder ist eine klassische TYPO3-Backend-Extension mit eigener Benutzeroberfläche. Im Backend erscheint ein Modul, in dem das Domain-Modell über eine Drag-and-Drop-Oberfläche erstellt wird: Entitäten als Boxen, Properties als Felder, Beziehungen als Linien. Beim Export wird ein JSON-Schema persistiert, aus dem der Generator den kompletten Extension-Code schreibt.

Die Installation erfolgt klassisch über Composer (friendsoftypo3/extension-builder). Die Extension hat keine Produktionsrelevanz, sie gehört in die Development-Umgebung und sollte in Production gar nicht erst aktiviert sein. Beim Generieren greift der Builder auf Twig-ähnliche Templates zurück, die sich bei Bedarf projektspezifisch anpassen lassen - etwa um eigene Code-Styles oder abweichende Lizenz-Header zu erzwingen.

Wichtig ist, dass der Extension Builder keinen Roundtrip beherrscht: Wer einmal generiert und dann den Code von Hand erweitert, kann die Extension zwar im Builder öffnen, sollte aber auf keinen Fall erneut generieren - sonst überschreibt der Builder Teile der manuell ergänzten Logik. In der Praxis wird der Builder als einmaliger Scaffold-Schritt verwendet, danach lebt die Extension im Git-Repository.

Häufige Probleme und Lösungen

Das erste Problem ist die Überschreibungsfalle nach dem ersten Generierungslauf. Teams, die den Builder zum zweiten Mal starten, um ein Feld nachzuziehen, verlieren eigene Code-Änderungen. Die Lösung ist eine klare Regel im Team: Der Extension Builder wird einmal benutzt, der Rest ist Handarbeit. Nachträgliche Feldänderungen erfolgen manuell in TCA, SQL und Model.

Das zweite Problem ist die Kompatibilität mit modernen PHP-Konventionen. Der Generator erzeugt immer noch Code, der an ältere PHP-Versionen und ältere Extbase-Konventionen angelehnt ist. Die Lösung ist ein Cleanup-Pass direkt nach der Generierung: Type-Declarations ergänzen, Return-Types setzen, readonly-Properties einführen, veraltete Annotation-Kommentare durch native Attribute ersetzen.

Das dritte Problem ist die unreflektierte Nutzung als Code-Wunder. Manche Teams erwarten, dass der Extension Builder eine produktionsreife Anwendung ausliefert. Das tut er nicht - er liefert ein Gerüst. Jede Business-Logik, jede Validierung, jedes Security-Konzept bleibt Aufgabe der Entwicklerin.

Ein viertes Problem sind veraltete Backend-Muster im generierten Code. Die mitgelieferten Controller verwenden manchmal noch deprecated Extbase-Patterns, die im aktuellen TYPO3 Deprecation-Warnings erzeugen. Die Lösung ist ein Lint-Schritt direkt nach der Generierung, der den Code gegen die aktuellen Coding Standards prüft und fehlende Type-Deklarationen oder veraltete Annotationen markiert. Moderne Pipelines kombinieren diesen Schritt mit automatischem Code-Rewriting durch Rector, um den Aufwand des Cleanups möglichst klein zu halten.

Migration und Versions-Kompatibilität

Der Extension Builder ist offiziell für TYPO3 v11 und v12 verfügbar und wird von den Friends of TYPO3 weitergepflegt. Für TYPO3 v13 existiert eine aktualisierte Fassung, die den neuen Extbase-Konventionen folgt. Teams, die bestehende Extensions upgraden, benötigen den Builder dafür in der Regel nicht mehr - das Upgrade läuft über Upgrade-Wizards im Install Tool und manuelle Anpassungen.

Interessanter ist der strategische Blick: In einer Zeit, in der generative KI komplette Extension-Grundgerüste inklusive Business-Logik aus einem Prompt erzeugen kann, verliert der visuelle Builder einen Teil seines ursprünglichen Vorteils. Gosign kombiniert beide Welten: Für Standard-Scaffolds mit vielen Entitäten bleibt der Builder effizient, für anspruchsvolle Extensions mit Domain-spezifischer Logik generieren wir den Code direkt aus einem Fachbriefing mit KI-Unterstützung - und sparen im Vergleich zum klassischen Handaufbau bis zu 80 Prozent der Entwicklungszeit bei gleichzeitig höherer Code-Qualität.