Ziel des Smooth-Migration-Projekts ist es, von TYPO3 4.5 auf Version 6.2 zu aktualisieren. Der Umzug soll dabei möglichst wenig Aufwand verursachen und die neue Seite ein stabiler Grund für weitere Entwicklungen sein. Leichter gesagt als getan, insbesondere bei den Tausenden Extensions. Zwar gibt es auch dafür Unterstützung, der Aufwand wächst aber mit der Zahl der installierten Erweiterungen. Der grundsätzliche Upgrade-Prozess beim Wechsel auf Version 6.2 unterscheidet sich nur leicht vom üblichen Vorgehen. Nach dem Update auf die neueste 4.5-Version müssen zunächst die Erweiterungen aktualisiert werden – im besten Fall sind hier bereits 6.2-kompatible Versionen verfügbar. Nicht benötigte Extensions können in diesem Zug deinstalliert und auch gelöscht werden. Anschließend kommen die vom Smooth-Migration-Projekt zur Verfügung gestellten Extensions sowie das überarbeitete Install Tool zum Einsatz. Zentrale Anlaufstelle für „Smooth Migration“ ist das Forge-Projekt. Im Wiki finden sich aktuell insbesondere Links und Anleitungen sowie erste Extension-Patches. Außerdem werden die zentralen Extensions vorgestellt. An Dokumentation fehlt es zwar bislang, doch das Forge-Projekt wird vermutlich auch in Zukunft die zentrale Stelle für alle Smooth-Migration-bezogenen Arbeiten und Ressourcen sein. Entsprechend ist hier nur etwas Geduld gefragt.

In der Zwischenzeit lohnt ein Blick in die Haupt-Extension des Projekts, „smoothmigration“ (ehemals „upgradereport“). Sie vermittelt einen guten Überblick darüber, was im Code alles vor dem Upgrade angepasst werden muss. Und das ist eine ganze Menge – zahlreiche veraltete TYPO3- und PHP-Funktionen, die Entfernung der veralteten t3lib-Dateien und damit einhergehende Probleme mit klassischen Require-Anweisungen, nicht mehr verwendete Konstanten und so weiter. Die Extension durchsucht die eigene Installation, zählt auf, welche Änderungen nötig sind, und führt auf Wunsch einige Anpassungen selbst durch. Darüber hinaus erkennt sie verwendete DAM-Klassen (dazu später mehr) und, ob das System bereit für UTF-8 ist. Ob die Änderungen automatisch vorgenommen werden können, zeigt die Extension in einem Backend-Modul, und bietet entsprechende Cron Jobs an. Diese benötigen einen eigenen Backend-User („_cli_smoothmigration“) und lassen sich anschließend über die Konsole und das Skript „cli_dispatch.phpsh“ mit dem Parameter „smoothmigration“ aufrufen. Mit dem Paramter „migrate“ starten die Cronjobs schließlich ihre Arbeit. Aktuell ersetzen sie wahlweise veraltete Aufrufe statischer Methoden (über den zweiten Parameter „replaceDeprecatedStaticMethods“) oder aber löschen Require- und Include-Anweisungen von t3lib-Dateien (Parameter „requireOnce“), da diese mit dem Einsatz von Namespaces nicht nur überflüssig, sondern zur Fehlerquelle werden.

Weniger zur Fehlervermeidung denn zur Arbeitsersparnis gedacht ist die System Extension „filemetadata“. Sie stellt jene DAM-Felder für Meta-Daten von Dateien wieder zur Verfügung, die der neue File Abstraction Layer (FAL) nicht implementiert. Dazu zählen etwa Foto-Koordinaten oder Informationen zur verwendeten Software beim Erstellen von Dateien. Wichtig ist dabei lediglich, die Extension zu installieren, bevor die DAM-Dateien migriert werden. Denn Felder, die beim Umzug fehlen, werden nicht befüllt. Die entsprechenden Informationen sind dann verloren bzw. müssen neu migriert werden.

Die dritte der empfohlenen Extensions, „dam_falmigration“, übernimmt DAM-Relationen und -Informationen in den neuen FAL. Dazu zählen die bereits erwähnten Meta-Daten sowie mm-Relationen und Daten in sämtlichen tx_dam*-Tabellen. Dateien aus dem dam_frontend werden standardmäßig in das Uploads-Inhaltselement übernommen. Die Extension zeigt direkt im Backend-Modul an, welche Schritte zum Umzug nötig sind. Im Gegensatz zur „smoothmigration“-Extension sind die Cron Jobs hier jedoch im Scheduler verfügbar und können dort nacheinander gestartet werden. Aktuell verfügt die Erweiterung über drei Cronjobs, von denen manche manuelle Hilfe in Form von geänderten Einstellungen im Install Tool benötigen. Entsprechende Hinweise spuckt dam_falmigration ebenfalls im Backend-Modul aus. Für weitere Anwendungsfälle lohnt zudem ein Blick in einen Fork der Extension. Dort gibt es bereits weitere Jobs, welche etwa eine Migration der Kategorien ermöglichen. In Summe macht ein DAM-Umzug die Migration um einiges aufwändiger. Die „smoothmigration“-Extension gibt zu den nötigen Schritten zwar bereitwillig Auskunft, ist jedoch nicht imstande, den Umzug hier voranzutreiben. Und selbst mit weiteren Erweiterungen bleiben etwa Anpassungen an jenen Stellen im Template, wo DAM verwendet worden ist.

Um im Dickicht der Migration eine Art Rückfallschutz zu haben, war einst eine „Compatibility Extension“ geplant. Diese sollte altbekannte Methoden und Konstanten wieder zur Verfügung stellen und auf die jeweiligen Äquivalente verknüpfen. Da die Extension „smoothmigration“ allerdings bereits große Teile der verwendeten statischen Methoden finden und ersetzen kann, ist diese geplante Extension aktuell auf Eis gelegt. Zudem verliert sie dank PHP-Aliases und Autoloader, die die Verwendung alter Klassen (z.B. t3lib_*) weiterhin ermöglichen, etwas an Relevanz. Ob sie aufgrund künftig auftretender Probleme dennoch nötig wird, steht derzeit noch nicht fest.

Nach der Überprüfung und Migration der Extensions kommt die erste spürbare Neuheit von Version 6.2 zum Einsatz. Denn das Install Tool ist nicht nur optisch neu, sondern kann nun mit fehlerhaften und veralteten Extensions umgehen. So lassen sich Erweiterungen direkt auf Fehler prüfen und gegebenenfalls deinstallieren. Für erste Tests eignen sich zudem „Configuration Presets“ für „Development“, eine Bündelung gängiger Einstellungen, die die Konfiguration erleichtern. Für das Upgrade interessant ist darüber hinaus der Upgrade Wizard, welcher wie gewohnt die nötigen Schritte zur Migration von Daten in passender Reihenfolge ausführt. Dazu gehören das Aktualisieren der Workspaces, der Umzug verknüpfter Dateien (sofern kein DAM eingesetzt worden ist) sowie das Installieren der wichtigsten System-Erweiterungen. Zudem sucht das Install Tool nach falsch gesetzten Dateisystem-Berechtigungen und bietet an, diese per Klick selbst zu korrigieren.

Allen automatisierten Migrationsprojekten zum Trotz: Jede TYPO3-Installation ist anders und entsprechend gilt es, jedes Upgrade mit Bedacht anzugehen. Auch das Smooth-Migration-Projekt kann diese Vorsicht nicht komplett übernehmen – das wird schon bei der nicht wirklich intuitiven Bedienung der involvierten Extensions deutlich. Besonders anfällig für Probleme sind selbst modifizierte oder nicht mehr gepflegte Third-Party-Extensions. Hier hilft außer der Suche nach einer passenden Alternative nur, selbst am Code Hand anzulegen. Noch mehr Arbeit verlangen Extensions, die bislang auf DAM setzen, sei es per PHP oder direkt im Template. Beides muss händisch auf FAL geändert werden. Gleiches gilt auch für direkte MySQL-Aufrufe in Extensions, da der TYPO3-Core auf mysqli umgestellt wurde. Eine im Vorfeld des Upgrades angefertigte Liste der Erweiterungen mit beurteilter Relevanz und nutzbarer Alternative erspart hier unter Umständen eine Menge Arbeit.

Upgrade-Checkliste

auf 4.5-Patch-Version aktualisieren Extensions auf 6.2-kompatible Versionen bringen nicht benötigte Erweiterungen deinstallieren deinstallierte Erweiterungen löschen DAM deinstallieren mit smoothmigration gefundene Fehler beheben sys_refindex aktualisieren TYPO3-Core aktualisieren Upgrade Wizard ausführen DB-Compare durchführen ggf. DAM mit dam_falmigration umziehen ausgiebig testen

Um ein Upgrade zu vereinfachen, hat das Smooth-Migration-Projekt bereits ganze Arbeit geleistet; wenn auch das Ziel noch nicht endgültig erreicht ist. Die Schaffung einer zentralen Stelle für sämtliche Dokumentationen ist unablässig, um die Migrationen zu vereinfachen. Hier sind nicht nur die Entwickler, sondern auch all jene gefordert, welche mit Migrationen bereits Erfahrungen gesammelt haben und Input liefern können. TYPO3 6.2 ist wie die Version 4.5 auf den Long Term Support (LTS) ausgelegt, sodass das CMS wieder für einige Jahre gerüstet sein wird. Dies betrifft einerseits Sicherheitsaspekte, andererseits die Code-Qualität und nicht zuletzt die Performance. Die Frage, ob sich ein Upgrade lohnt, stellt sich ab Herbst 2014 nicht mehr. Dann wird die Unterstützung für TYPO3 4.5 eingestellt.