in2template für TYPO3

Ein einheitliches Skelett bringt Struktur in Site Packages, bevor sie zur Wartungshölle werden

Wer in TYPO3 ein Site Package für eine große Website aufsetzt, steht jedes Mal vor derselben Frage: Wie organisiere ich Templates, Partials, Layouts und Content-Elemente so, dass sie in zwei Jahren noch wartbar sind? in2template taucht in Code-Beispielen von in2code als Name einer projekteigenen Extension auf, veröffentlicht ist es weder im TER noch auf Packagist. Eine strukturierte Antwort liefert ein Grundgerüst für moderne Site Packages: klare Verzeichnisstruktur, vordefinierte Content-Elemente, vorbereitete Konfiguration für TypoScript, Fluid Styled Content und Backend-Layouts. Für TYPO3-Teams, die regelmäßig neue Projekte starten, ersetzt ein solches Skelett die alte Copy-Paste-Praxis aus dem letzten Kundenprojekt durch ein dokumentiertes Muster.

Die Zielgruppe sind Agenturen mit mehreren parallelen TYPO3-Projekten und Inhouse-Teams, die Corporate-Templates für Konzern- oder Hochschul-Sites pflegen. Besonders dort, wo sich Entwicklerinnen und Redakteurinnen das Site Package teilen, ist eine konsistente Ordner- und Namenskonvention überlebenswichtig. Ein einheitliches Skelett adressiert genau diese Lücke.

Typische Einsatzszenarien

Ein erstes Szenario ist der saubere Projektstart. Eine Agentur mit acht Entwicklerinnen und drei laufenden TYPO3-Projekten führt ein eigenes Skelett als internen Standard für Site Packages ein. Jedes neue Projekt beginnt mit demselben Skelett: identische Verzeichnisstruktur, identische Naming-Konventionen, identische TypoScript-Basis. Das Ergebnis: Ein Entwickler kann zwischen Projekten wechseln, ohne sich jedes Mal neu zu orientieren.

Ein zweites Szenario ist die Modernisierung eines alten Site Packages. Ein Hochschul-Portal mit 800 Seiten und einem seit TYPO3 v7 gewachsenen Template-Ordner wird im Rahmen eines Upgrades von v11 auf v12 neu strukturiert. Statt den alten Wildwuchs weiterzutragen, baut das Team das Site Package auf Basis eines solchen Skeletts neu auf und migriert die Inhalte schrittweise.

Ein drittes Szenario ist das Onboarding neuer Redakteure. Ein Verlag mit 30 Redakteuren erklärt auf Basis des Skeletts, welche Content-Elemente wofür gedacht sind. Die Konsistenz in Benennung und Struktur macht die Schulung kürzer, die Backend-Fehlerquote sinkt.

Ein viertes Szenario ist die interne Refactoring-Vorlage. Ein Unternehmen mit fünf TYPO3-Installationen aus unterschiedlichen Baujahren möchte die Site Packages langfristig in eine einheitliche Struktur überführen. Ein einheitliches Muster dient dabei als Referenz-Skelett, gegen das jedes Alt-Projekt schrittweise umgebaut wird - ohne dass das Team jedes Mal eine neue Zielstruktur diskutieren muss.

Technische Architektur

Ein solches Skelett ist kein klassisches Add-on, sondern eine Vorlage für ein eigenes Site Package. Es bringt eine Verzeichnisstruktur mit: Resources/Private/Templates, Resources/Private/Partials, Resources/Private/Layouts, Configuration/TypoScript, Configuration/TsConfig, Configuration/TCA/Overrides. Ergänzt wird das Gerüst um vorbereitete Content-Elemente (Text, Text mit Bild, Akkordeon, Teaser-Grid) und eine Konfiguration für Backend-Layouts.

Ein Composer-Paket gibt es nicht; ein solches Skelett wird in das eigene Site-Package-Repository kopiert und umbenannt. In der Praxis nutzen Teams ein solches Skelett selten als direkte Abhängigkeit - üblich ist ein initialer Klon, der dann projektspezifisch weiterwächst. Das macht das Skelett zu einem Starter-Kit und nicht zu einem Framework, das über Versionen hinweg aktualisiert werden müsste.

Für die Integration mit Fluid Styled Content gibt es eigene Override-Mechanismen, die sicherstellen, dass die mitgelieferten Content-Elemente mit den Core-Elementen koexistieren. TypoScript-Pfade sind durchgängig namespaced, damit mehrere Site Packages auf derselben Installation parallel laufen können.

Häufige Probleme und Lösungen

Das erste Problem ist die Verwechslung mit einem Framework. Teams, die ein Site-Package-Skelett wie Bootstrap oder Tailwind einbinden und auf Updates hoffen, erleben eine Enttäuschung: Ein Skelett ist ein Template zum Abkupfern, kein Upstream-Stack. Die Lösung ist, das Skelett als einmalige Vorlage zu betrachten und das daraus entstehende eigene Site Package klar zu versionieren.

Das zweite Problem ist die Überfrachtung mit nicht genutzten Content-Elementen. Das Starter-Kit bringt mehr Elemente mit, als die meisten Projekte brauchen. Wer sie nicht nutzt, schleppt sie trotzdem durch die Wartung. Die Lösung ist ein Clean-up direkt nach dem initialen Import: Ungenutzte Content-Elemente löschen, nicht genutzte Backend-Layouts entfernen, nicht verwendete TypoScript-Blöcke streichen.

Das dritte Problem ist die Anpassung an individuelle Design-Systeme. Skelette bringen oft eigenes CSS mit eigenen Utility-Klassen mit. Wer ein bestehendes Design-System mit eigenen Token-Namen einsetzt, muss die gelieferten Stylings konsequent übersetzen, sonst entsteht Stil-Dopplung und widersprüchliche Cascade.

Ein viertes Problem sind Konflikte mit anderen Starter-Kits. Wer ein Skelett teilweise übernimmt und parallel Bausteine aus einem anderen Skelett integriert, bekommt widersprüchliche TypoScript-Pfade und überlappende Fluid-Namespaces. Die Lösung ist, bei Projektbeginn eine Entscheidung für genau ein Skelett zu treffen und inkonsistente Zusatz-Komponenten in einer klar benannten Projekt-eigenen Layer zu halten.

Migration und Versions-Kompatibilität

in2template ist nicht veröffentlicht; welche TYPO3-Versionen es unterstützt, lässt sich deshalb nicht prüfen. Weil ein Skelett in Projekten fast immer geklont und angepasst wird, ist die Versions-Frage weniger eine Frage von Update-Pfaden und mehr eine Frage der Code-Disziplin: Teams sollten beim Upgrade ihres Site Packages einen Blick in aktuelle Vorlagen wie den Site Package Builder von TYPO3 werfen, um strukturelle Verbesserungen (neue Backend-Layout-Konventionen, neue Fluid-Pattern) nachzuziehen.

Wichtig beim Upgrade eines auf in2template basierenden Site Packages ist der Blick auf veränderte TYPO3-Konventionen: TCA-Overrides, Backend-Layout-Definitionen, Content-Element-Registrierung und Fluid-Rendering haben sich zwischen v11 und v13 mehrfach bewegt. Wer diese Änderungen nicht im eigenen Site Package nachzieht, läuft Gefahr, dass Inhalte im Backend plötzlich leer wirken oder die Content-Element-Wizards nicht mehr erscheinen.

Gosign übernimmt in TYPO3-Projekten die Analyse, welche Teile des bestehenden Site Packages nach einem in2template-ähnlichen Muster aufgeräumt werden können und welche besser auf ein eigenes, minimalistisches Skelett migrieren. Das Ergebnis ist ein Site Package, das in Code-Reviews ohne Raunen durchgeht und beim nächsten TYPO3-Upgrade keine Überraschungen produziert.