Typo3 in Frankfurt: Die Schulden-Spirale
Typo3-Projekte werden oft mit einer Philosophie gebaut, die man 'schnell funktioniert' nennt. Die richtige LTS-Versions-Strategie wird ignoriert oder viel zu spät überhaupt eingeführt - ein Projekt läuft auf Typo3 9 oder 10, während längst Version 13 existiert. Extensions aus dem TER werden einfach eingefügt, ohne dass geklärt ist, wer sie zukünftig wartet oder wie sie mit nächsten Versionen kompatibel bleiben. Das TypoScript wächst kontinuierlich unkontrolliert, Code-Duplikate entstehen unbemerkt, und irgendwann kann niemand mehr sagen, wie die Systeme zusammenhängen oder welche Abhängigkeiten verborgen sind. Das ist nicht böse gemeint - es passiert, wenn Updates als reiner Kostenfaktor behandelt werden.
Die Praxis in Frankfurt und bundesweit zeigt ein sehr häufiges Muster, das wir deutlich zu oft beobachten: Systeme wachsen, der Verwaltungsaufwand mit ihnen. Der DataHandler wird per TypoScript-Hooks überlastet und unnötig komplex, die Fluid Templating Engine wird mit zu viel Business-Logik beladen, statt sie im Extbase Framework sauber zu halten. Composer Mode wird völlig ignoriert - statt saubere Abhängigkeiten zu definieren wird wild gebündelt. Das Scheduler-System wird 'später' installiert, weil erst die Features fertig sein müssen. Indexierungsprozesse laufen nicht sauber, die FAL-Strukturen sind undokumentiert. Dann kommt der Update-Versuch, und niemand weiß mehr, welche Abhängigkeiten wo lauern und was brechen wird.
Ein solides Typo3-Projekt in Frankfurt braucht mindestens drei fundamentale, architektonische Fundamente, die in der Praxis regelmäßig schwach oder überhaupt nicht umgesetzt werden - und genau diese kritischen Lücken führen Jahre später zu schwerwiegenden Update-Problemen, zu Sicherheitskrisen oder zu dem schmerzhaften, teuren Szenario, dass eine Modernisierung oder ein Relaunch ohne kompletten Neubau praktisch unmöglich wird:
- LTS-Versioning-Strategie von Anfang an festlegen, nicht Jahre später improvisieren müssen
- Extbase Framework und Composer Mode konsequent nutzen, nicht TypoScript-Wildwuchs zulassen
- Scheduler-Jobs und DataHandler-Hooks dokumentieren, nicht Konfiguration und Abhängigkeiten verstecken
mindmelt kümmert sich in Frankfurt um genau das. Ein aktuelles Typo3-Projekt beginnt bei uns mit einem intensiven technischen Architektur-Gespräch: LTS-Roadmap definieren, bestehende Extensions auditieren, die Fluid Templating Engine sauber strukturieren und das CMS Core-Verhalten verstehen. Wir nutzen Extbase richtig, nicht gegen die Architektur. Code-Review während der Entwicklung schaut auf Abhängigkeiten, Extension Repository-Kompatibilität, FAL-Strukturen und zukünftige Update-Fähigkeit. Das kostet deutlich mehr Zeit am Anfang, spart aber Jahre später oder beim nächsten großen Update.
Typo3-Systeme ohne fundierte Architektur-Planung von Anfang an sind reine Schulden-Akkumulation - jedes Update wird zur teuren Notfall-Operation.