Upgrade auf WordPress 2.0.3
Vor zwei Tagen habe ich ein wenig freie Zeit dazu verwendet meine WordPress-Installation von Version 2.0.2 auf die vor Kurzem erschienene 2.0.3 zu heben. Das Upgrade 2.0.3 stopft einige Sicherheitslöcher und nach den Erfahrungen einer SQL-Attacke auf meine WordPress-Installation bin ich vorsichtig geworden, was die Verschleppung von Upgrades angeht.
Wie mir Subversion hilft
Ich stecke so ziemlich alles, was sich ab und an auf meiner Festplatte ändert in ein VersionControlSystem. Auch meine WordPress-Installation wird so versioniert. Ich kann also ohne Gefahr eines Änderungsverlusts die Dateien eines Upgrade-Archivs, wie man es auf der WordPress-Seite runterladen kann, aufspielen und sehe dann sofort, welche Dateien sich geändert haben.
Es erfordert dann ein wenig Handanlegen, um für jede geänderte Datei herauszufinden, ob das Überschreiben Änderungen von mir unter sich begräbt, oder ob es sich um eine Datei handelt, die nur von einer WordPress-Version zur nächsten verändert wurde.
In der Log-View von Subversion (oder prinzipiell in jedem VersionControlSystem) ist der erste Fall einfach zu entdecken:
Änderung: eigenen Code eingefügt
Upgrade auf WordPress 2.0.2Der Zweite Fall ist schwieriger, weil dort die erste Zeile aus dem Log nicht vorhanden ist:
Upgrade auf WordPress 2.0.2Hier muss man dann Recherchearbeit leisten. Entweder man kennt alle eigenen Änderungen (vielleicht macht man sie im Source kenntlich), oder man macht ein Diff zwischen verschiedenen Revisionen, um die Änderungen wieder herauszufinden.
In allen Fällen muss man dann die eigenen Änderungen in das Upgrade (hier: auf die 2.0.3) mergen. Mit Tools wie TortoiseMerge ist das aber kaum ein Problem.
Tipp: Wie erkennt man lokale Änderungen beim nächsten Upgrade
Die gemergten Dateien sollte man in einer eigenen Revision committen, dann sieht man diese Änderungen beim nächsten Upgrade sofort. Also: erst alle Dateien committen, die nur Änderungen durch die WordPressentwickler enthalten, dann eigene Änderungen in die restlichen Dateien einpflegen und committen.
So ergeben sich unterschiedliche Logs. Zum einen:
Upgrade auf WordPress 2.0.3
Upgrade auf WordPress 2.0.2Und:
Merges für 2.0.3
Upgrade auf WordPress 2.0.2Upgrade auf MySQL 5.0.21
Beruflich beschäftige ich mich seit Kurzem mit DBSchemaDiffing, der Möglichkeit Unterschiede zwischen zwei Datenbank-Schemata festzustellen.
Meine Suche im Netz nach einem Tool, das entsprechendes leistet, hat mir die Wichtigkeit solch datenbankadministrativen Tätigkeiten vor Augen gehalten: solche Tools sind unter ein paar hundert Euro nicht zu haben.
Es ist aber möglich solche Metadaten direkt aus einer ANSI-SQL-konformen Datenbank zu holen (und zwar mit SQL!). Das Stichwort heisst InformationSchema, ein Schema, das diese Metadaten anbietet und im ANSI-SQL92-Standard definiert wird.
MSSQLServer bietet dieses Schema in Form von Views an. Meine MySQL-version (4.1) nicht. Als ich feststellte, dass die 5er Version von MySQL das InformationSchema ebenfalls anbietet, war ein Update nötig.
MySQL
Ich habe MySQL durch das XAMPP-Paket von apachefriends.org installiert. Also habe ich mir das neue Paket besorgt und installiert: Fehler 1067 – Nach der Anpassung der Pfade (ich verwende jetzt absolute Pfade, nicht die standardmäßig relativen) funktioniert der SQL-Server:
basedir="/xampp/mysql" --> basedir=j:/Programme/xampp/mysqlApache!
Die neue Version des XAMPP-Paket installiert allerdings auch eine neue Version des apache-Servers und hier hat sich einiges an der Struktur von httpd.conf geändert. Mit Hilfe von Subversion konnte ich auch hier die Änderungen recht leicht übertragen – (Diff sei dank. ModPython habe ich nicht zum Laufen bekommen, da ich es lokal aber gerade nicht brauche, war das nicht so schlimm. Änderungen für DAV und Subversion habe ich auch nicht übernommen. Wie sich bald herausstellte: Ein Fehler, denn ohne diese Änderungen läuft auch Subversion nicht – logisch, wenn man die Repositories per apache anspricht. Nachdem auch diese Änderungen eingebaut waren musste ich feststellen, dass meine Version von Subversion (1.1.4) nicht mit dem Apache 2.2 zusammenarbeitet. Nun wäre es an der Zeit auch für Subversion die aktuelle Version zu installieren – geht aber bei mir nicht (wie berichtet).
Also habe ich mir wieder die 2.0er Version von Apache runtergeladen und in das xampp-Verzeichnis installiert. Durch mein Subversion-‘Backup’ waren meine alten conf-Dateien nicht verloren und das Drüberinstallieren funktionierte ebenfalls ohne Probleme. Ich liebe Programme ohne Querabhängigkeiten!
Resume
Beim Upgraden von Scripten (WordPress besteht z.B. aus php und javascript) und sonstigen Text-Dateien ist ein VersionControlSystem überaus hilfreich. Ich habe mit Subversion und Tortoise gute Erfahrungen gemacht.
