FFH für TYPO3

Branchenspezifische TYPO3-Extensions scheitern nicht an der Technik, sondern an der Pflege

FFH steht exemplarisch für eine Kategorie von TYPO3-Extensions, die für einen bestimmten Kunden oder eine bestimmte Branche entwickelt wurden: branchenspezifisch, funktional, aber nicht allgemein gepflegt. Im TER finden sich hunderte solcher Extensions. Manche haben 5 Downloads pro Jahr, keine Dokumentation und den letzten Commit vor 3 Jahren. Das bedeutet nicht, dass sie schlecht sind. Es bedeutet, dass sie Pflege brauchen, die der ursprüngliche Entwickler nicht mehr leistet.

Für Unternehmen, die auf solche Extensions angewiesen sind, stellt sich eine praktische Frage: Weiternutzen und selbst pflegen, auf eine Alternative migrieren oder neu entwickeln. Alle drei Wege sind gangbar. Die Entscheidung hängt von der Komplexität der Extension, der Verfügbarkeit von Alternativen und dem TYPO3-Versions-Druck ab.

Typische Einsatzszenarien

Branchenverbände mit Spezialanforderungen. Handwerkskammern, Sportverbände und Berufsgenossenschaften betreiben TYPO3-Websites mit Funktionen, die kein Standard-Plugin abdeckt: Mitgliederverzeichnisse mit Suchradius, Veranstaltungsmanagement mit Qualifizierungspunkten, Branchenregister mit Zertifizierungsstatus. Dafür existieren Custom Extensions, die vor 5-8 Jahren entwickelt wurden und seitdem nur minimal aktualisiert werden. Die Funktion läuft, aber TYPO3-Updates werden zum Risiko.

Medienunternehmen mit redaktionellen Workflows. Radiosender, Verlage und Medienhäuser nutzen TYPO3 mit Extensions für Playlists, Programmplanung, Medienarchive oder Content-Syndication. Diese Extensions sind oft intern entwickelt oder von einer Agentur gebaut worden, die das Projekt nicht mehr betreut. Der Code funktioniert auf TYPO3 v9, aber die Migration auf v12 scheitert an veralteten APIs.

Öffentliche Einrichtungen mit gesetzlichen Anforderungen. Schulen, Museen und Bibliotheken nutzen Extensions für Öffnungszeiten-Verwaltung, Katalogsuche oder Veranstaltungsbuchung. Die Anforderungen sind spezifisch (z.B. Integration mit einer Bibliothekssoftware wie Koha oder Alma), die Extension wurde einmal gebaut und seitdem nicht aktualisiert.

Technische Architektur

Branchenspezifische TYPO3-Extensions folgen typischerweise dem Extbase/Fluid-Pattern: Domain-Modell (PHP-Klassen), Repository (Datenbankzugriff), Controller (Geschäftslogik) und Fluid-Templates (Darstellung). Die Daten liegen in eigenen Datenbanktabellen mit tx_extensionname_ Prefix.

Die häufigsten architekturellen Muster: Plugin-basierte Extensions mit Frontend-Ausgabe (Listendarstellung, Detailansicht, Filterung), Backend-Module für die Datenpflege und Scheduler-Tasks für Import/Export. Viele branchenspezifische Extensions integrieren externe Systeme über REST-APIs oder CSV-Import.

Die Codequalität variiert erheblich. Extensions von professionellen Agenturen folgen TYPO3-Coding-Standards, nutzen Dependency Injection und haben Unit Tests. Intern entwickelte Extensions oder schnell gebaute Auftragsarbeiten haben oft hartcodierte Konfigurationen, fehlende Typisierung und keine Tests. Beides lässt sich pflegen, aber der Aufwand unterscheidet sich um den Faktor 3-5.

Ein typisches Analyse-Muster für branchenspezifische Extensions: Umfang messen (Lines of Code, Anzahl der Klassen, Anzahl der Datenbanktabellen), Abhängigkeiten prüfen (welche TYPO3-APIs werden genutzt, welche sind in v12/v13 deprecated), Testbarkeit bewerten (gibt es Unit Tests, ist der Code testbar strukturiert) und Migration-Aufwand schätzen.

Häufige Probleme und Lösungen

Deprecated APIs blockieren das TYPO3-Update. Die Extension nutzt $GLOBALS['TSFE'], GeneralUtility::_GP() oder ObjectManager::get(), alles APIs, die in TYPO3 v12 deprecated oder entfernt sind. Lösung: Systematisches Refactoring. Jede deprecated API hat einen dokumentierten Ersatz im TYPO3 Changelog. Bei einer Extension mit 5.000 Zeilen Code liegt der Refactoring-Aufwand bei 3-7 Tagen, abhängig von der Anzahl der Deprecations.

Kein Maintainer verfügbar. Der ursprüngliche Entwickler hat die Firma verlassen, die Agentur existiert nicht mehr, das TER-Paket ist verwaist. Lösung: Den Code auf GitHub forken, die Extension in das eigene Composer-Repository aufnehmen und selbst pflegen. Oder einen externen Dienstleister beauftragen. Der Fork ist rechtlich unproblematisch, wenn die Extension unter GPL steht (Standard für TYPO3-Extensions).

Keine Dokumentation. Weder Inline-Kommentare noch externe Docs. Neue Entwickler müssen den Code lesen, um die Funktion zu verstehen. Lösung: Vor dem Refactoring eine technische Dokumentation erstellen. 2-4 Stunden Analyse reichen für eine Extension mit 3.000-5.000 Zeilen Code, um Architektur, Datenmodell und Geschäftslogik zu dokumentieren.

Migration und Versions-Kompatibilität

Branchenspezifische Extensions haben naturgemäß keinen offiziellen v12/v13-Support. Die Migration muss individuell geleistet werden. Der Aufwand hängt von drei Faktoren ab:

Erstens: Welche TYPO3-Version ist der Ausgangspunkt? Von v9 auf v12 ist deutlich mehr Arbeit als von v11 auf v12, weil v10 den Middleware-Stack eingeführt hat und v11 die Backend-Module-Registrierung geändert hat.

Zweitens: Wie viele deprecated APIs werden genutzt? TYPO3s Extension Scanner (im Install Tool) zeigt das automatisch. Eine Extension mit 5 Deprecations braucht einen Tag, eine mit 50 braucht eine Woche.

Drittens: Wie gut ist der Code strukturiert? Sauberer Extbase-Code lässt sich mechanisch migrieren. Prozeduraler Code mit direkten Datenbankaufrufen erfordert Umschreibung.

Die drei Optionen: Portierung (Extension auf neue TYPO3-Version anpassen, 3-10 Tage), Neuentwicklung (gleiche Funktion, saubere Architektur, 2-4 Wochen) oder Alternative finden (Standard-Extension, die 80% der Funktion abdeckt, plus Custom-Anpassung). Gosign hat hunderte branchenspezifische TYPO3-Extensions analysiert, portiert und neu entwickelt und berät zur wirtschaftlichsten Option.