Erfahrungsbericht: Alte Drupal 7-Instanzen updaten

  • D6 seit 2009, dann archiviert
  • D7 seit 2013 jährlich
  • Einreichungen per Webform
  • seit 2015 entschlackt: Content-Teil: statische Seite & jährliche Dubletten der Einreichungs-Instanz
  • seit 2017 Git-basierte Releases
  • 28.03.2018 Drupalgeddon: schnelles Update 2018, Abschaltung übriger Subdomains
  • 2020: Drush-Phar im Repo
  • 2022: Nachziehen aller Instanzen seit 2015 für die Schnittstelle zur Datenmigration
  • Idee: D9-Plattform zur Bewertung kann schon an Schnittstelle der alten Instanz zur Einreichung laufen

Suche nach Lösung der nahezu einheitlichen Codebase über viele Jahre.

Integration Prä-Git-Umgebung auf Git durch Fork des ersten Zustandes (Update von 2016 für 2017) und Diffen mit 2015-Zustand aus Snapshot.

Problem: altes Drush + PHP-/DB-Versionen nicht mehr mitgezogen (auch Encoding, u.a. Sonderzeichen)

Erste Tests: Legacy-PHP und MariaDB-Versionen + Versuch, die Seite wieder lauffähig zu bekommen.

Sehr umständlich + Probleme mit Updates. Schrittweise Versionsanhebung?

Alte Umgebungen laufen noch nicht auf PHP 7.

Dann Erkenntnis: neue Drush-Versionen für 7 laufen bis auf wenige Warnings auch auf alten PHP-Versionen.

Also 1.: Drush-Phar hochgezogen in PHP 7.4

Dann 2.: Dev-Umgebung auf PHP 5 geswitcht, Seite reagiert und drush up kann Module hochziehen.

Dann 3. PHP wieder auf 7 stellen, DB-Updates durchführen + Settings anpassen

Nach Versionierung der Updates muß remote nur das Repo (davor Switch auf Versionierte Fassung) hochgezogen und DB-Update durchgeführt werden.

Jetzt können die Jahre wieder baumartig Updates erhalten, da minimale Modul- und Theme-Abweichungen bestehen. Git komprimiert eh und bei Bedarf gibt's backports von Views/Features.

Aufgabe: 2013+2014 updaten + Snapshots anlegen inkl. Context-Switches (DEsignfail)