Wissen / Extensions & individuelle Funktionen / Was passiert mit eigenen Extensions und individuellen Funktionen

Was passiert mit eigenen Extensions und individuellen Funktionen?

Eigene Extensions und individuelle Funktionen sind bei TYPO3 nichts Ungewöhnliches. Im Gegenteil: Genau darin liegt eine der Stärken des Systems. Funktionen lassen sich sehr genau an ein Projekt anpassen. Beim Update bedeutet das aber auch: Für eigenen Code ist man selbst verantwortlich.

TYPO3 aktualisiert eine Custom Extension nicht automatisch auf die neue Version. Deshalb schaue ich mir zuerst den Code an, verschaffe mir einen Überblick und prüfe anschließend im Frontend, welche sichtbaren Funktionen auf der Website tatsächlich von dieser Extension abhängen.

Wie prüfe ich eine eigene Extension vor dem Update?

Nach einem kurzem ‘Smoke-Test’ im Frontend, ist der erste Schritt ist immer der Code. Ich schaue mir an, welche TYPO3-Funktionen und Schnittstellen verwendet werden, wie die Extension aufgebaut ist und welche Teile bei der gewünschten Zielversion angepasst werden müssen. Danach schaue ich mir die bestehende Website an. Nur der Code allein sagt nämlich nicht immer sofort, welche Bedeutung eine Funktion im Alltag hat.

So lässt sich klären:

  • welche Funktionen die Extension bereitstellt
  • wo sie im Frontend verwendet wird
  • ob es Backend-Funktionen gibt
  • welche Daten sie speichert
  • ob externe Dienste angebunden sind
  • welche Teile beim Update besonders kritisch sind

Ich möchte nicht nur wissen, welcher Code geändert werden muss. Ich möchte auch verstehen, welche Aufgabe dieser Code für die Website erfüllt.

Was muss bei einer alten Custom Extension typischerweise angepasst werden?

Das hängt von der Extension und den übersprungenen TYPO3-Versionen ab. Typische Bereiche sind zum Beispiel:

  • Extbase
  • TCA
  • TypoScript
  • Fluid-Templates
  • Hooks und Events
  • Scheduler-Tasks
  • CLI-Commands
  • Backend-Module
  • eigene ViewHelper
  • Datenbankzugriffe
  • APIs und externe Bibliotheken

TYPO3 verändert diese Bereiche von Version zu Version. Funktionen werden als veraltet markiert, später entfernt oder durch neue Lösungen ersetzt. Bei einem kleinen Versionssprung kann sich der Aufwand stark in Grenzen halten. Bei einer über viele Jahre nicht gepflegten Extension können sich dagegen Änderungen aus mehreren TYPO3-Versionen angesammelt haben. Trotzdem gilt nicht automatisch: alt = teuer. Eine sehr kleine Extension, die nur eine überschaubare Aufgabe erledigt, kann auch nach vielen Jahren relativ schnell angepasst sein.

Wie findet man veralteten TYPO3-Code?

Dafür muss man nicht jede Änderung ausschließlich von Hand suchen. TYPO3 bietet im Backend Werkzeuge, die Extensions auf veraltete oder nicht mehr unterstützte Funktionen prüfen können. Solche Scans sind eine gute Hilfe, um problematische Stellen schnell zu finden. Zusätzlich sind die Changelogs der TYPO3-Versionen wichtig. Dort ist dokumentiert, welche Funktionen verändert, als veraltet markiert oder entfernt wurden.

Für PHP-Code gibt es außerdem Rector. Das Tool analysiert Code anhand definierter Regeln und kann viele notwendige Anpassungen erkennen oder teilweise sogar automatisch durchführen. Für Fluid gibt es mit Fractor ein ähnliches, noch sehr neues Werkzeug.

Solche Tools sparen Arbeit, ersetzen aber nicht die Prüfung des Projekts. Sie können Code analysieren, wissen aber nicht automatisch, was eine individuelle Funktion fachlich tun soll.

Auch ein Sitepackage ist eine Custom Extension

Eigene Logik steckt nicht immer in einer Extension mit einem besonders auffälligen Namen. Auch das Sitepackage eines TYPO3-Projekts ist technisch eine eigene Extension. Und gerade dort sammelt sich über die Jahre häufig deutlich mehr als nur das Grundlayout der Website.

Darin können zum Beispiel liegen:

  • eigene Content-Elemente
  • TypoScript-Konfiguration
  • Fluid-Templates
  • eigene ViewHelper
  • Formularanpassungen
  • JavaScript-Logik
  • Backend-Konfiguration
  • API-Anbindungen
  • spezielle Projektfunktionen

Ein über Jahre gewachsenes Sitepackage kann deshalb beim Update genauso relevant sein wie jede andere große Custom Extension.

Entscheidend ist nicht, wie die Extension heißt, sondern wie viel individuelle Logik darin steckt.

Wann ist neu schreiben sinnvoller als aktualisieren?

Manchmal lohnt es sich nicht mehr, alten Code Stück für Stück zu reparieren. Wenn eine Extension technisch so veraltet ist, dass ohnehin ein großer Teil neu gebaut werden müsste, kann eine saubere Neuentwicklung günstiger und sinnvoller sein.

Dabei spielen mehrere Dinge eine Rolle:

  • Umfang der Extension
  • Alter des Codes
  • verwendete TYPO3-Techniken
  • Codequalität
  • Dokumentation
  • Datenstruktur
  • externe Abhängigkeiten
  • zukünftige Anforderungen

Eine pauschale Grenze gibt es dafür nicht. Bei einer kleinen Extension kann auch alter Code schnell modernisiert sein. Bei einer großen Extension, die auf längst entfernten TYPO3-Techniken basiert, kann ein Neubau dagegen der bessere Weg sein.

Muss beim Update auch gleich der ganze Code aufgeräumt werden?

Nicht unbedingt. Wenn der Auftrag lautet: „Bring diese Extension auf TYPO3 Version X zum Laufen“, dann konzentriere ich mich zunächst genau darauf. Ich baue nicht automatisch das halbe Projekt um, nur weil mir dabei Stellen auffallen, die man heute anders schreiben würde. Wenn dagegen das Ziel lautet, die Extension so zu modernisieren, dass auch kommende Updates leichter werden, spielt Codequalität deutlich stärker hinein. Dann kann ein TYPO3-Update gleichzeitig ein Refactoring sein. Das bedeutet: Veraltete Strukturen werden nicht nur irgendwie kompatibel gemacht, sondern sauber auf aktuelle TYPO3-Techniken umgestellt.

Wie weit diese Modernisierung gehen soll, muss vorher klar sein. Sonst wird aus einem Update schnell ein viel größeres Projekt als geplant.

Was ist mit Funktionen, von denen niemand mehr genau weiß, dass es sie gibt?

Das kommt bei gewachsenen Projekten durchaus vor. Eine Website läuft vielleicht seit zehn Jahren, Entwickler haben gewechselt und Dokumentation fehlt. Dann kennt der Kunde oft die wichtigsten Funktionen, aber nicht jede technische Besonderheit im Hintergrund. In solchen Fällen hilft nur: Code lesen und die bestehende Website genau ansehen.

Ich vergleiche, welche Funktionen auf dem alten System vorhanden sind und welche Teile davon durch eigenen Code umgesetzt werden. So fallen auch Dinge auf, die in keinem Pflichtenheft stehen, aber im Alltag trotzdem gebraucht werden. Gerade bei Legacy-Projekten ist diese Analyse ein wichtiger Teil des Updates.

Was passiert, wenn eigener Code von einer alten externen Bibliothek abhängt?

Custom Extensions hängen nicht nur von TYPO3 ab. Sie können zum Beispiel externe PHP-Bibliotheken, APIs oder andere Dienste verwenden. Wenn eine solche Abhängigkeit nicht mehr gepflegt wird oder mit der neuen Serverumgebung nicht mehr funktioniert, reicht ein reines TYPO3-Update nicht aus.

Dann muss entschieden werden, ob:

  • die Bibliothek aktualisiert werden kann
  • die Funktion auf eine neue Lösung umgebaut wird
  • ein anderer Dienst eingesetzt wird
  • die betreffende Funktion nicht mehr benötigt und entfernt wird

Wenn die technische Grundlage einer Funktion nicht mehr existiert, kann auch die Custom Extension diese Funktion nicht einfach unverändert weiter anbieten.

Sind eigene Extensions beim Update grundsätzlich problematisch?

Nein. Custom Code ist nicht automatisch schlechter Code. Eigene Extensions sind ein völlig normaler Bestandteil vieler TYPO3-Projekte. Sie werden problematisch, wenn sie jahrelang nicht gepflegt wurden, niemand mehr weiß, was sie tun, oder sie auf technischen Grundlagen basieren, die längst verschwunden sind. Eine sauber aufgebaute und regelmäßig gepflegte Custom Extension lässt sich dagegen oft sehr gut aktualisieren. Der entscheidende Unterschied zu einer Extension aus dem TYPO3 Extension Repository ist nur die Verantwortung: Bei eigenem Code kann man nicht darauf warten, dass ein anderer Entwickler eine kompatible Version veröffentlicht.

Was passiert also mit eigenen Extensions beim TYPO3-Update?

Zuerst wird geklärt, was die Extension technisch macht und welche Funktionen sie auf der Website abdeckt. Danach wird geprüft, welche Teile mit der neuen TYPO3-Version angepasst werden müssen. Dabei helfen TYPO3-eigene Prüfwerkzeuge, Changelogs sowie Tools wie Rector und Fractor. Bei kleinen Extensions kann das schnell erledigt sein. Bei großen, alten oder stark individuellen Erweiterungen kann ein größerer Umbau notwendig werden. Manchmal ist sogar eine Neuentwicklung sinnvoller.

Eigene Extensions sind kein Problem, solange klar ist, was sie tun und der Code gepflegt werden kann. Beim Update müssen sie aber aktiv an die neue TYPO3-Version angepasst werden – automatisch passiert das nicht.