Contao: Von 2.11 nach 3.2, vom Catalog zu MetaModels

Der geschätzte Kollege Peter Müller (dessen Bücher ich nebenbei immer wieder gerne empfehle) hatte anlässlich der Contao-Konferenz zusammen mit Harry Boldt einen Vortrag zum Theme Updates gehalten. Darin erwähnte er, dass er keinen Zauberstab habe und Tipps zum Update von der 2er auf die 3er-Version von Contao nebst einer Transplantation von Catalog-Daten in die MetaModels-Erweiterung nicht geben könnte. Natürlich ist das ein etwas komplexeres Szenario - aber grundsätzlich ist das machbar.

 

Natürlich ist alles auch ein wenig von den Voraussetzungen abhängig. Wie habe ich unterContao 2 gearbeitet? Setze ich problematische Erweiterungen ein? Habe ich den Ordner /templates ohne Not mit unzähligen geänderten Templates bestückt? Diese Fragen sollte man vorher klären - vielleicht ist das ja auch ein Anstoß um zukünftig Templateänderungen wo immer es geht zu vermeiden. CSS ist erstaunlich mächtig.

Vorspiel

Zunächst aber einmal zur bisherigen Systemkonfiguration, die ich im Beispiel referenziere. Ein Contao-2.11-System, das drei Unternehmensteile jeweils zweisprachig abbildet. Alles ist über verschiedene Domains realisiert - insgesamt sieben an der Zahl. Darin ein Catalog, der zur Darstellung von Referenzen auf einer Karte benutzt wird - alles kein Hexenwerk, aber schon etwas anspruchsvoller, denn für die Zuordnung der Referenzen (also Firmendaten inklusive der Anschrift) sorgt der eher experimentelle ContaoMaps-Layer von Christian Schiffler. Der Kunde mag es, im Backend auf einer Karte einen Marker zu setzen und dann die Geokoordinaten ausgefüllt zu bekommen - und umgekehrt.

ContaoMaps hat den Vorteil, dass es nicht nur eine Anbindung an den Catalog sondern auch an MetaModels gibt. Und es gibt eine Version, die vermutlich auch mit Contao 3.2 lauffähig ist. Also eigentlich ganz gute Voraussetzungen.

Bevor wir aber auch nur einen einzigen Knopf zum Update drücken machen wir erst einmal ein Backup. Ich benutze dafür gerne SynCto, da ich damit eine Installation vollständig replizieren kann ohne mir einen Kopf darum zu machen, was ich jetzt in welcher Reihenfolge wohin kopieren muss. Klick und los. Trotzdem erst einmal ein einseitiges Vergnügen - zur Zeit vertragen sich MetaModels, SyncCto und der DC_General nicht sonderlich, und es gibt mehrere Versionen, da man mal installieren, mal deinstallieren und gegeneinander austauschen muss.

Vor der Replikation lege ich noch schnell auf dem Zielserver ein paar Subdomains an - zum testen will ich ja jeden Teil des Seitenbaumes direkt aufrufen können. Alles ins Zielverzeichnis geleitet, dort mit dem Contao-Check die erst einmal benötigte Contao-Version 2.11 installiert und mit SyncCto auf den Stand gebracht. Das Bett ist jetzt gemacht, und wir arbeiten im Folgenden auschließlich mit dieser Seitenkopie und nicht mit der Livesite.

 

Versionitis

Zu diesem Thema sind zunächst ein paar Vorüberlegungen wichtig - nicht alles läuft mit jeder Contao-Version, manche Extensions interferieren recht häßlich miteinander.MetaModels möchte am Liebsten via Composer installiert werden, aber eine Migration des Catalogs ist (jedenfalls in der von mir verwendeten Fassung aus dem SVN) nicht möglich, weil damit eine unerwünschte Version aus dem Contao-Extension-Repository darübergebügelt werden würde. MetaModels und der Catalog laufen zumindest in Grundzügen parallel, und unter Contao 2 steht mir das überaus nützliche Tool 'TabImporter' des Kollegen Christian de la Haye (auch sehr geschätzt) zur Verfügung.

Also sollte es ein guter Plan sein, zunächst eine ältere 1er-Version von MetaModels unter dem Contao 2.11 zu installieren und damit die Catalogstruktur nachzubauen. Gesagt, getan und die Arbeit eines halben Nachmittags. Am Ende haben wir zwei Backendmodule für die Referenzen - einmal vom Catalog, einmal von MetaModels. ich atme durch und mache vor dem nächsten Schritt erstmal ein Komplettbackup.

Datentransfer

Allerdings sind meine Daten noch im Catalog, und jetzt sollen sie ins MetaModel. Der TabImporter erweist sich dabei als besonders hilfreich, denn er bietet die Möglichkeit des Importes aus einer Datenbanktabelle. Importjob aufsetzen, Felder zuordnen, Job starten. Klingt ganz einfach, aber ich brauche schon ein paar Runden, bis ich alles transferiert habe. Die Belohnung ist ein Listenmodul, mit dem ich meinen Adressenbestand erst einmal ausgeben kann. Alles da? Jetzt ist der Zeitpunkt um das zu überprüfen. Den Maps-Layer lasse ich erst einmal aus dem Spiel.

Nachdem das aber alles gut ausschaut lösche ich jetzt all das, was den Transfer nach Contao3 nicht überstehen würde. Darunter fällt gewiss der Catalog - ein beherzter Druck auf die <del>-Taste erledigt das via FTP, und genauso entsorge ich die Taxonomie, die ich im neuen MetaModel nicht benötige. Dieser Punkt ist etwas fummelig, denn der Catalog bringt in diesem Fall eine Menge an Abhängigkeiten mit. Nach drei Jahren muss man da erstmal durchsteigen. Hatte ich erwähnt, dass Backups eine gute Idee sind? Und das es auch eine gute Idee ist, diese Bacxkups in mehreren Versionen und in Ordnern zu lagern, die exakt mit dem beschriftet sind was drin ist? Gut.

Den TabImporter benötige ich ebenfalls nicht mehr und lösche ihn also. Und dann gibt es ja noch Erweiterunugen, von denen ich zunächst erstmal nur weiß, dass ich sie vielleicht noch einmal brauchen kann, die aber ganz sicher beim Upgrade der Installation Ärger machen können. Das TaskCenter ist so ein Fall - deaktivieren, genauso wie alles andere was ich nicht zwingend benötige (oder von dem ich nicht verstehe wozu ich es benötigen könnte). Vor dem Upgrade ist ein guter Zeitpunkt dafür. Was nicht aktiv ist kann auch keinen Ärger machen, schließlich möchten wir nachher noch den Composer benutzen.

Contao 3, FTW!

Im Forum gibt es eine recht gute Anleitung zum Systemupdate von C2 nach C3 - einfach mal nachlesen. Vieles beschäftigt sich mit Contao 3.0, aber das Prinzip gilt für alle Versionssprünge genauso. Ich möchte direkt auf Contao 3.2 LTS, und ich möchte, dass alle Dateien von 'tl_files' nach 'files' wandern. Das sollte machbar sein.

Der nächste Schritt ist es, ein Archiv mit der gewünschten Contao-Version lokal zu entpacken und per FTP (oder FTP-Synchronisation, wenn man neckisch veranlagt ist) in unsere gesicherte Updateinstalltion zu verschieben. Leo Feyer und andere haben sich die Mühe gemacht, die Differenzen zwischen C2 und C2 zu dokumentieren: eine Liste von verwaisten Dateien, die ich mit dem Finger über der Löschtaste abarbeite. Übrig bleibt etwas, was im Kern ein Contao 3.2 sein sollte, und es ist eine gute Idee, das mit demContao-Check zu überprüfen.

Wenn der Check positiv ausgefallen ist dann wird jetzt das Contao-Installtool aufgerufen. Mehrere Datenbankupdates später kann ich mich das erste mal im Backend anmelden. mein Sytsem läuft im abgesicherten Modus, da kann eigentlich nichts schiefgehen. Et voilá.

Composer hilft bei Extensions

Der nächste Punkt sind jetzt die deaktivierten Erweiterungen - die müssen sämtlich auf eine zu Contao 3 kompatible Version angehoben werden. Das geht in vielen Fällen mit dem alten Extension-Repository und händischer Installation von all den Dingen, die dort nicht ladbar sind - viel schöner ist dabei aber der Composer, denn damit geht mein MetaModel-Update (bisher sind wir ja bei Version 1.0) ganz einfach von der Hand. Also lade ich mit dem alten ER-Client den Composer-Installer und freue mich nach der Migration der Erweiterungen an der neuen Paketverwaltung.

Composer hat alle vorhandenen Erweiterungen migriert und die Verwaltung der so genannten Legacy-Extensions übernommen. Ich möchte aber neue Versionen, also installiere ich mittels Composer die Alternativen direkt aus den Repositories. Wem das jetzt nicht ganz klar ist: beispielsweise gibt es die DLH-Googlemaps-Extension sowohl imContao-ER als auch via Entwicklerrepository auf Github. ich möchte die aktuellste Version, suche also im Composer-Client nach dlh_googlemaps, installiere die gewünschte Fassung und entferne danach die Legacy-Erweiterung mit dem Paketmanager. Das mache ich für jede im System vorhandenen Erweiterung.

MetaModels installiere ich ebenfalls via Composer auf Version 1.1 (die TNG möchte ich in diesem Fall nicht) und nutze dann den Bundle-Installer (metamodels/bundle_all) um Attribute und Filter auf den Stand zu bringen. Das geht schneller als erwartet, auch wenn ich bei manchen Erweiterungen mehrere Anläufe brauche (gefühlt).

Zeit für den letzten Akt: aus tl_files wird files. dazu gibt es ein kleines Script von Tristan Lins und Leo feyer, das auf Github zu finden ist. Dieses Script versehe ich mit meinen Zugansdaten zu Datenbank, und lade es es ins Domainroot auf dem Webserver hoch. Der nächste Schritt ist, im Contao-Backend unter Einstellungen der Speicherort für Dateien von /tl_files nach /files zu ändern.

Dann erst rufe ich das Script es im Browser auf. Alle Ressourcen, die bisher auf den tl_files-Ordner zeigten werden jetzt im datenbankgestützten Dateisystem von Contao auf den files-Ordner umgeschrieben. Nach Abschuss des Scripts benenne ich per FTP den Ordner /files in /files_empty und den Ordner /tl_files in /files um. Anschließend logge ich mich ins Backend ein, klicke zur Überprüfung in der Dateiverwaltung auf "synchronisieren" und freue mich abschließend daran, dass alles geklappt hat.

 

Was bleibt

Ich habe mein System upgegradet, und ich habe alle Daten migriert. Jetzt muss ich mich noch einmal mit den MetaModels-Templates für die Kartenmarker beschäftigen. Aber das ist ja nicht mehr so schlimm.

Als Fazit kann ich sagen, dass Planung und Information das A und O sind. Ohne Überlegungen zu den einzelnen Migrationsschritten kommt man nur schwer ans Ziel, und genaue Informationen über Versionen sind superwichtig.

Insbesondere der Composer hat dabei seine Tücken - ich habe auch lernen müssen dass eine Migration zu ungewünschten Ergebnissen führen kann. Diese Probleme kann man aber bewältigen.

Ach ja: herzlichen Gruß an Peter und Harry. Man braucht keinen Zauberstab.

Zurück