in2template für TYPO3

in2template bringt Struktur in Site Packages, bevor sie zur Wartungshölle werden

Wer in TYPO3 ein Site Package für eine grosse 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? Die Extension in2template aus dem Haus in2code ist der Versuch, auf diese Frage eine strukturierte Antwort zu geben. Sie 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ässig neue Projekte starten, ersetzt in2template 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. in2template 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 in2template 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 von in2template 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 in2template-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. in2template 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

in2template ist kein klassisches Add-on, sondern eher eine Vorlage für ein eigenes Site Package. Die Extension 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.

Die Installation erfolgt als klassischer Composer-Download des Packages, das anschliessend in das eigene Site-Package-Repository kopiert und umbenannt wird. In der Praxis nutzen Teams in2template seltener als direkte Abhängigkeit - üblich ist ein initialer Klon, der dann projektspezifisch weiterwächst. Das macht die Extension 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 in2template wie Bootstrap oder Tailwind einbinden und auf Updates hoffen, erleben eine Enttäuschung: Die Extension ist ein Template zum Abkupfern, kein Upstream-Stack. Die Lösung ist, in2template 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. in2template liefert Tailwind-nahes CSS mit eigenen Utility-Klassen. 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 in2template 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 wird von in2code für TYPO3 v11 und v12 gepflegt, die TYPO3-v13-Kompatibilität wird entlang der Release-Zyklen von TYPO3 selbst aktualisiert. Weil die Extension 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 das aktuelle in2template-Repository 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.