Pidgin auf mehreren Rechnern←▼→Gartenbank im Selbstbau

contao,werkzeuge,windows

Contao 3.2.x → 3.3.x

Erstellt: 22.06.2014 Lesedauer 3 - 4 Min.

Nachdem die letzten Wochen die Zeit mit anderen Dingen gut gefüllt war, musste ich erschreckt feststellen, dass es bei Contao munter weiter ging. Mein Status war 3.2.7, aktuell ist 3.3.3. Arbeit!

Mittlerweile habe ich eine gewisse Routine, was die Aktualisierung von Contao-Installationen betrifft. Innerhalb der dritten Stelle muss man sich typischerweise keine Gedanken machen. Das klappt vergleichsweise stressfrei. Allerdings gibt es mit dem Sprung von 3.2.7 auf die 3.3.3 eine neue Strategie für die Module. Die Idee, dass man Contao erst mal im Core-Modus hochfährt, ist zwar eine nette, kann aber in ordentlich Arbeit ausarten.

Wichtig: BACKUP anlegen!

Das ist zwar eigentlich logisch, aber „mal fix Update einspielen“ macht gelegentlich leichtsinnig.

Die Grundstrategie via XAMPP habe ich bereits erläutert. Unter Windows 8.1 treibe ich es mittlerweile noch etwas härter. Denn der Explorer lässt sich (bei meinen Webspaces…) so sauber aufschalten, dass ich die Kopieraktivitäten damit direkt durchführe.

  1. Ich mache ein Backup der kompletten Umgebung
  2. Ich hole mir die gepackten Dateien per Download
    • Dann habe ich die Backups lokal bei mir als Sicherung
    • Ich kann mir aus den Dateien die Datenbank(en) und Webseiteninfos ziehen
    • Zwei dicke Dateien werden signifikant schneller herunter geladen, als viele kleine
  3. Ich schiebe mir die Daten in XAMPP

Mittlerweile ist EasyUpdate3 im Repository verfügbar. Mit den passenden Paketen versehen, gehen Updates schnell, allerdings gibt es diesmal eine Stelle beim Umstieg von 3.2.10 → 3.3.0, bei der es klemmt.

Ich habe es jetzt mehrfach gemacht, es klemmt immer und lässt sich trivial lösen: „Zurück“-Pfeil des Browsers anklicken und nochmal auf „Nächster Schritt“. Dann läuft es sauber durch und es funktioniert auch alles.

Vorsicht: Falle!

Mit Version 3.3.0 werden erst einmal alle zusätzlich installierten Module deaktiviert, damit man schauen kann, ob es grundsätzlich klappt. Da EasyUpdate am Ende eines Zyklus in den Install springt, ist jetzt etwas Vorsicht angezeigt. Denn mit Version 3.3.0 müssen ein paar Tabellen angepasst werden.

Im ersten Zug nur die Tabellen aktualisieren, die das Install-Werkzeug alleine ausgewählt hat. Dann erst mal ins Backend gehen und bei den Modulen schauen, ob es für das ein oder andere Aktualisierungen ab Version 3.3.0 gibt.

Bei einigen Modulen ist das der Fall. Dann den Core-Modus deaktivieren und schauen, ob alles klappt. Wenn dann bei der Datenbank-Aktualisierung noch Tabellen geändert werden sollen, kann man die durchführen. Wird es vorher gemacht, werden womöglich Daten gelöscht, die man entweder von Hand wieder einpflegt, oder nochmal bei (4) anfängt, was — abhängig von der Datenmenge — womöglich schneller geht.

Ich weiß das, weil ich beim Google- und GIS-Baukasten ins Harakiri-Messer gelaufen bin. Ob andere Module ebenfalls davon betroffen sind, weiß ich nicht, jedenfalls gab es mit der geschilderten Methode dann keinen Stress mehr.

Ich habe die Delete-xxx.txt Dateien von EasyUpdate in eine Batch-Datei zusammenkopiert und starte sie im HTDOCS von XAMPP, das entrümpelt schon mal recht gut. Dann räume ich noch die Backups und Aktualisierungs-ZIP-Dateien aus dem EasyUpdate-Verzeichnis ab. Das macht die ZIP-Datei schön schlank, die auf den Server geladen werden muss.

Eventuell Zweckmäßig

Es gibt ein paar Module, die nicht mehr gewartet werden. Das sind potenzielle Updatestörer oder gar Update-Verhinderer. Hier frage ich mich sehr intensiv, ob ich es wirklich (noch) brauche, oder ob es womöglich auch ohne geht. Sich trennen können kann das Leben in solchen Fällen deutlich vereinfachen. Vor allem, wenn man feststellt, dass es Module gibt, die man eigentlich gar nicht (mehr) verwendet, also damit lediglich Ballast mitschleppt, der zu allem Überfluss auch noch Ärger machen kann.

Seiteneffekte

Bei meiner Homepage gab es ein paar Seiteneffekte, die ich noch nicht erforscht habe. Mein Responsive-Design ging da teilweise kaputt, das Logo wurde zu groß dargestellt — keine Ahnung, was da in die Grütze ging. Alles nicht schlimm, war vergleichsweise schnell repariert. Ich vermute, dass mir hier CSS-Altlasten auf die Füße gefallen sind. Wer sehr alte Seiten aktualisiert, sollte sich deshalb eventuell mal etwas Zeit nehmen, um die CSS-Datei(en) von Grund auf sauber mit den neuen Möglichkeiten aufzubauen.

Nachtrag 1:

Heute morgen (23.06.2014) stelle ich fest, dass der RSS-Reader nicht mehr alle Feeds anzeigt. Warum ist unklar, denn der nicht angezeigte (mein Blog) entspricht formal den angezeigten. Aktuell ist noch keine Antwort darauf in Sicht.