Es war verdächtig ruhig hier die letzten Wochen. Das lag zum einen an einem Wechsel aus Urlaub und Überastung auf Arbeit, zum anderen an einem selbstauferlegten "Code-Freeze", weil ich endlich mal die diesem Blog zu Grunde liegende Software auf einen aktuellen Stand bringen wollte.
Gerade eben, nach ungefähr 5 Tagen, hab ich dieses Vorhaben gestrichen. Und warum ich es hab sein lassen, darüber will ich nun berichten.
Vor knapp 4 Jahren, also irgendwann im Jahr 2004 bin ich von selbstgestickten HTML-Seiten auf ein Content Management System umgestiegen, in diesem Fall war es Drupal in der damals aktuellen Version 4 Punkt irgendwas. Ein großer Schritt und auf jeden Fall die richtige Entscheidung, weil das Schreiben und publizieren ab diesem Zeitpunkt echt einfacher war. Einfach Content reinhämmern und das CMS macht den Rest, inklusive suchmaschinenfreundlichen URLs und Querverlinkungen.
Leider habe ich zu diesem Zeitpunkt einen absolut klassischen Fehler begangen, weil mir ein paar Sachen nicht so richtig gefallen haben, und diesen Fehler begeht wohl so gut wie jeder, der Standardsoftwäre einsetzt: ich habe angefangen den Standard meinen Bedürfnissen anzupassen, neudeutsch zu customizen. Irgendwie erschien mir das legitim und richtig, heute bereue ich es zu tiefst, weil ich keine Möglichkeit mehr habe mit Bordmitteln der Standardsoftware auf eine aktuelle Version zu wechseln. Das Datenbankschema hat sich in der Zeit öfters mal geändert, Funktionsmodule sind obsolet geworden oder wurden durch neuere Komponenten ersetzt und ich habe in der Zeit immer weiter an meiner Version 4 herumgeschraubt, von neuen Modulen selber Downports gebastelt, die irgendwie auf mein ebenfalls angepasstes Datenmodell aufsetzen - naja, man kennt das ja.
Natürlich gibt es auf der ganzen Welt kein Migrationsskript, das mein einmaliges Datenmodell in das aktuelle der Version 6 überführt, also hab ich angefangen selber zu migrieren. Da aber das Datenmodell an manchen Stellen komplett überarbeitet wurde, hat mit auch ein "ALTER TABLE" nicht wirklich weitergeholfen. Das hieß also Tabelle als CSV exportieren, in Excel alles überarbeiten und dann in die neue Datenbank importieren. Das hat mich alleine 2 Tage gekostet. Leider haben meine "alten" Daten in der neuen Datenbank nicht so richtig funktioniert, weil ich irgendwelche Funktionen verwende, die bestimte Ausdrücke parsen und in etwas anderer Form wiederausgeben. Diese Funktionen gibt es natürlich nicht in der neuen Version, also müsste man auch Legacy-Code migrieren, was nicht wirklich sinnvoll ist, da es in der neuen Version auch neue Funktionen gibt. Also müsste man um standardnah zu sein den kompletten "alten" Content überarbeiten - und das geht im Zweifenlfall auch nicht wirklich automatisch.
Und dann bliebe noch das Thema eines Design-Relaunches, wenn man ohnehin schon etwas "neues" macht. Aber darauf hat man sicherlich keine Lust mehr wenn man die restlichen Baustellen sieht.
Was habe ich also gelernt?
1. Die 80-20-Regel bestätigt sich auch hier - der größte Teil war nach knapp 3 Tagen erledigt, aber für den Rest hätte ich mit Sicherheit nochmal 3 Wochen dranhängen können.
2. Wenn etwas Standardsoftware heißt, soll man es auch so behandeln. Individuelle Erweiterungen sind erlaubt, aber nur wenn es Erweiterungen sind und keine Anpassungen am Standard.
3. Wenn es irgendwie vertrebar ist, sollte man auch kleinere Versionssrpünge mitmachen. Das sind zwar jedesmal vielleicht 2-3 Tage Aufwand, aber dann sollte man auch wirklich durch sein.
4. Wenn man 4 Jahre mit einem Update wartet und stattdessen selber bastelt hat man letztendlich nichts gewonnen, ich sehe nur eine Menge toller neuer Funktionen, die ich gerne hätte, aber ohne erheblichen Aufwand nicht zu bekommen sind.
Technorati Tags: mind, migration, software, cms, Drupal, update, quality, field report