Rector to the rescue
Tools und Strategien für das nächste TYPO3-Upgrade
Wisst ihr noch, was ihr drei Tage vor dem Heiligen Abend 2020 gemacht habt? Idealerweise habt ihr euch auf die Feiertage eingestellt, mit den im Dienst verbliebenen Kollegen gequatscht, letzte Amazon-Bestellungen aufgegeben, in der Hoffnung, dass diese rechtzeitig vor dem Feste eintreffen.
Was ihr nicht gemacht habt: Spontan ein TYPO3-Upgrade für die Urlaubszeit vorbereitet. Der Support für das laufende Jahr war schließlich abgeschlossen, alte Tickets sortiert, da kann man im Grunde ein bisschen ausprobieren. So zumindest dachte es sich Henrik Elsner, Developer im Team DFAU.
Bereits früh im Einsatz
Versions-Upgrades gehören zu TYPO3-Agenturen wie Entkalker zur Wartung von Waschmaschinen – ohne ist irgendwann Schicht im Schacht. Man könnte also meinen, dass Upgrade-Prozesse von Haus aus wie gut geölte Maschinen laufen: Kunde gibt den Auftrag, Dev-Team führt den Auftrag aus, Dev-Team meldet Vollzug. Dass es nicht ganz so einfach ist, weiß jede Agentur aus dem Alltag.
Zurück zu unserem dedicated employee Henrik und seinem Experiment kurz vor Weihnachten: “Um zu prüfen, wie so ein Upgrade effizienter gestaltet werden kann, habe ich Rector installiert. Gelesen hatte ich davon damals auf Twitter.” Im TYPO3-Slack (noch nicht dabei? Hier anmelden!) stellte Henrik wie in der Szene üblich aufgekommene Fragen. Darüber freute sich einer besonders: Sebastian Schreiber, seines Zeichens Hauptentwickler von TYPO3-Rector.
Effizient mit TYPO3-Rector am Projekt arbeiten
“Sebastian brauchte Use-Cases und Feedback. Für uns war das natürlich ideal, da wir wiederum 1:1-Support zum laufenden Projekt bekommen haben”, erinnert sich Henrik. “Ich habe in der Folge immer wieder damit gearbeitet und auch Tickets angelegt, wenn etwas nicht funktioniert hat und getestet. Irgendwann habe ich angefangen kleinere Issues zu lösen.” So gehört Henrik inzwischen zum Support-Team rund um TYPO3-Rector und arbeitet am Projekt mit.
Ob nun zufällig oder weil die Feiertage ihn erneut wenig besinnlich gestimmt haben: Kurz nach Ostern 2022 bot Henrik seine Erfahrungen und Arbeitsweise mit TYPO3-Rector als Sessionthema auf dem TYPO3-Camp Vienna an. Zum Wiener Camp war vom 22. bis 24. April 2022 (fast) das gesamte DFAU-Dev-Team angereist. Noch am selben Vormittag ging es an die Präsentation, deren wichtigste Kernpunkte wir hier im Blog gerne für euch noch einmal aufbereiten.
Wichtigste Inhalte zur Rector-Session von Henrik Elsner
Nützliche Extensions/Packages vorne weg:
- https://extensions.typo3.org/extension/core_upgrader
- https://extensions.typo3.org/extension/typo3db_legacy
- https://github.com/sabbelasichon/typo3-rector
Was tun diese Extensions?
core_upgrader:
Stellt ältere Upgrade-Wizards bereit, die im normalen LTS-Package nicht mehr vorliegen. Ein Upgrade-Wizard wird immer für zwei Versionen beibehalten, wenn man also von TYPO3 Version 7 auf 10 geht, fehlen die Wizards für den Versionssprung von 7 auf 8. Die Extension stellt diese und alle anschließenden Wizards zur Verfügung.
Dadurch lassen sich Zwischenschritte beim Upgraden sparen – statt von TYPO3 v7 auf v8 und dann auf v10 kann man direkt von v7 auf v10 oder sogar v11 gehen. Es kann durchaus notwendig sein, dass man trotzdem einen Zwischenschritt braucht – an den fehlenden Upgrade-Wizards scheitert es allerdings nicht. Im Grunde steht und fällt der reibungslose Ablauf mit den Third Party Extensions, die man verwendet.
typo3db_legacy:
Mit TYPO3 v9 wurde $GLOBALS[‘TYPO3_DB’] endgültig aus dem System entfernt, sodass damit keine Queries mehr funktionieren. typo3db_legacy ändert das und macht die Variable nochmals verfügbar. Super hilfreich ist die Extension also für einen schnellen Start – das System wirft keine Fehler, weil die globale Variable nicht mehr vorliegt und Queries entsprechend fehlschlagen.
Außerdem lässt sich sehr schön vorher/nachher vergleichen, da man seine umgeschriebenen Queries einfach so auch noch während des Upgrades mit einer v9 oder späterem System gegenüber dem alten Verhalten abgleichen kann.
typo3_rector:
Im Gegensatz zu den anderen beiden Erweiterungen ist Rector nicht nur ein Hilfsmittel, sondern eine Art Mitarbeiter, den man wie einen Junior behandeln kann. Ganz blind vertrauen sollte man ihm nicht, aber die Changes und der Pull Request, der am Ende dabei herauskommt, können einfach geprüft werden. Dabei muss man sich selbst die Finger nicht schmutzig machen an TCA, TypoScript Conditions, ViewHelpern und anderen lästigen Dingen.
Die Strategie:
Ziel ist es, das Upgrade jederzeit wieder durchführen zu können. Dafür notwendig sind die folgenden beiden Schritte:
Aufräumen:
Es ist ratsam, alte Seitenbäume, Seiten, Elemente vor dem Upgrade etc. aufzuräumen. TYPO3 bietet dafür cleanup tasks, die sys_log oder sys_history aufräumen, oder auch Datensätze, die als deleted eingetragen sind. Das macht die Datenbank schlanker und auch schneller bei Abfragen. Auch gibt es die Möglichkeit, eigene Aufräum-Skripte zu schreiben und z. B. alle hidden records, die länger als X Jahre nicht bearbeitet wurden, zu löschen.
Das ist natürlich ein wenig riskanter, aber seien wir ehrlich: Mit “Das brauchen wir irgendwann mal noch und deswegen heben wir es auf” von Kundenseite macht man sich genauso etwas vor wie mit dem “temporary fix” als Entwickler.
Tickets und Notizen:
Legt eine Notiz oder ein Ticket an, was für den Kunden wichtig ist. Ganz vorneweg die Nutzerrechte – diese müssen vergeben werden. Ähnliche Punkte sind Veränderungen von Icons, nützliche Hinweise, wie z. B. der Content-Element-Filter, oder auch elementare Dinge wie das Slug- und Redirect-Handling, welches ab TYPO3-Version 9 greift.
Nochmal mehr für jeden Dev selbst sollte alles abgelegt werden, was euch unterwegs begegnet. Ihr führt einen Wizard aus? Aufschreiben! Ihr wechselt die Version von v8 auf z.B. v10? Commit speichern! Ihr seht eine Stelle in v8, von der ihr wisst, dass sie mit v10 brechen wird? “v10change”-Markierung rein!
Bringt euch in eine Position, aus der ihr nicht darauf angewiesen seid, euch zu erinnern “Was war nötig?”, sondern schreibt euch konstant die Anleitung mit. So könnt ihr am Tag des Livegangs o. ä. effizient eine Liste abarbeiten.
Rector kennt den Core
Rector hilft euch auf dem Weg – in allen Lagen. Eure Aufgabe wird es lediglich sein, die changes zu prüfen und ggf. anzureichern. Dabei werden Änderungen chronologisch ausgeführt. Zum Beispiel die Verschiebungen von TCA Language Keys für palettes und fields innerhalb von EXT:lang. Anschließend erfolgt das Auflösen von EXT:lang durch Rector. Das funktioniert auch mit Suchen und Ersetzen, allerdings nicht so schnell und nicht ohne die neuen Pfade aus der Doku zu erfassen – die liefert Rector in der Kommandozeile gleich als Link mit, falls man nochmal etwas nachschauen möchte.
Das heißt vor allem bei changes, die ihr nicht auf dem Schirm habt, ist der Mehrwert geboten, dass man direkt mit der Doku lernen kann, wie, wo, was und warum sich Dinge im Core geändert haben. Die Grundlage für nahezu alle Rector-Regeln sind nämlich die TYPO3-Changelogs – die Informationsquelle ist also für Rector und Entwickler dieselbe. Fragt sich nur, wer schneller ist, den change durchzuführen.
Ungeliebte changes – werden übernommen
Weitere Beispiele für lästige changes, die vom Rector übernommen werden, sind z. B. das Entfernen von interface in jeder TCA-Definition. Hier lässt sich zwar auch wieder danach suchen. Allerdings ist Suchen und Ersetzen schon nicht mehr möglich, da die Inhalte der interface-Angabe von TCA zu TCA unterschiedlich sind.
Zuletzt unterstützt Rector auch bei changes wie den ViewHelper render-Parameter zu initializeArguments. Bei diesem muss man alle Parameter aus der render-Methode extrahieren und diese in die initializeArguments-Methode auslagern und dort registrieren.
Die Änderungen sind nicht wirklich mit Suchen und Ersetzen umsetzbar und je nach Menge und Größe der ViewHelper extrem mühsam.
Zudem beschäftigt man sich in dem Moment nicht einmal mit der Funktion des ViewHelpers. Vielmehr liegt der Fokus darauf, dass dieser überhaupt läuft, bevor man dazu kommt, den eigentlichen Code zu fixen, der durch das Upgrade nicht mehr funktioniert.
Rector frühzeitig und für Kundenangebote einsetzen
All diese Dinge müssen nicht erst mit dem Upgrade geprüft werden, sondern können auch schon zuvor für ältere Versionen gecheckt werden. Die Arbeit mit Rector beginnt also schon vor dem eigentlichen Upgrade und nicht erst wenn dieser ansteht.
Auch eine Annehmlichkeit von Rector ist es, beim Schätzen vor dem Angebot zu helfen. Innerhalb kürzester Zeit zeigt Rector an, was sich in der neuesten TYPO3-Version ändern wird und was nicht mehr von Hand erledigt werden muss. Damit lässt sich leicht erschließen, welche offenen Aufgaben für die Angebotserstellung übrig bleiben.
Fazit & Ausblick
Rector hat wie alle Mitarbeiterinnen und Kollegen auch Grenzen – Rector versucht aber den alten Code zu erkennen und dann eine entsprechende Meldung in der Kommandozeile zu liefern, wenn keine automatisierte Änderung möglich ist. Insgesamt bringt Rector alles mit, was mit dem Extension-Scanner bereits seinen Weg in den Core (Install Tool) gefunden hat – nur ohne false positive und direkt mit der Möglichkeit, den Code zu ändern.
Wer also nicht bis Weihnachten warten möchte, ehe euch die Inspiration ergreift, setzt sich schon bald an den nächsten großen Versionssprung! Release für TYPO3 v12.0 (nicht LTS!) wird voraussichtlich für den Sommer 2022 erwartet. Schon weit vor Veröffentlichung der LTS-Version habt ihr also die Möglichkeit, euch mit TYPO3-Rector und seinen vielen Einsatzmöglichkeiten und Hilfestellungen vertraut zu machen. Henrik Elsner, Sebastian Schreiber und alle Contributors im Slack-Channel #ext-typo3-rector freuen sich auf euren Beitrag.