Ralf Hendel, Geschäftsführer
Drupal Enthusiast und Freizeit-Pianist.

Testszenario für Modul-Patches

Drupal Modul-Patches einspielen leicht gemacht - auch für Nicht-Entwickler

Als Nicht-Entwickler hat man vor Patches ziemlichen Respekt und traut sich da nicht so recht heran.

Wenn man neue Module ausprobiert gelangt man häufig an den Punkt, dass Fehler auftreten und man den Befund in der Issue-Queue wieder findet. Mit etwas Glück gibt es dazu bereits einen Patch und den gilt es nun einzuspielen. Zum Glück ist das aber gar nicht so schwer und auch für Nicht-Entwickler mit etwas gutem Willen sehr gut zugänglich.

Nach langer Zeit habe ich mir heute einmal wieder die 7-er Modulversionen von Taxonomy Menu, Taxonomy Manager und Term Merge angeschaut. In Drupal 6 waren die Module dermaßen buggy, dass wir seitdem einen Bogen um sie gemacht hatten.

Test am Beispiel des "Term Merge"-Moduls

"Term Merge" ist ein recht praktisches Modul, welches ermöglicht, unterschiedliche Terms zu einem gemeinsamen Term zusammen zu legen und die vertaggten Inhalte automatisch mit nachpflegt. Ein schönes Modul, würde es denn funktionieren ;-)

Beim Testen habe ich festgestellt, dass ich anschließend beide Terms nicht mehr im System habe, wenn ich die beiden Kategorien "Hamburg" und "Hmaburg" in "Hamburg" zusammenführen möchte. In der Issue-Queue steht dieser Fehler gleich an erster Stelle. Zum Glück gibt es es dafür aber schon einen Patch. Also auf geht's!

In der Issue-Queue habe ich außerdem gesehen, dass die zugewiesenen Nodes nicht mit nachgepflegt werden. Auch hier gegen existiert ein Patch.

Module und Patches nur auf Testumgebungen probieren

Dass man Module nicht auf Live-Sites testet ist im Grunde eine Selbstverständlichkeit. Der Vollständigkeit halber erwähne ich es aber dennoch...

Test-Szenario einrichten und Datenbank-Dump vor dem Test sichern

Zum Testen richte ich mir zwei neue Terms ein sowie zwei Nodes, die mit je einem der beiden Terms verlinkt sind. Ich sichere mir die Datenbank mit Backup & Migrate, sodass ich von der Shell aus mit einem einzigen Befehl

mysql -u[Username] -p[Passwort] [Datenbankname] < [Pfad zur Backup-Datei]

jederzeit wieder herstellen kann.

Anwenden des Patches

Laut den git-instructions auf den Modul-Seiten von drupal.org kopiert man den Patch in den Modul-Ordner und führt in der Shell anschließend den Befehl git apply -v [patchname.patch] aus. Dabei erhält man jedoch keine Bestätigungen, weder positiver noch negativer Art.

Bei mir hat das jedoch nicht funktioniert: der Fehler bestand weiterhin. Jetzt musste ich herausfinden ob entweder das Anwenden des Patches oder der Patch selbst nicht funktioniert hat. Da das im Code-Wühlen meine Dev-Skills schnell übersteigt, nehme ich git zur Hilfe:

Kontrolle der Änderungen mit Git

Um das heraus zu finden hilft mir ein einfacher "git status" weiter: wenn sich die Modul-Datei geändert hat, erscheint sie auch in der Liste der modifizierten Dateien. In meinem Fall war die Modul-Datei unverändert. "git apply" hat offenbar nicht funktioniert.

Google hat mich auf eine andere Methode des Patchens gebracht, patch -p1 < example.patch die unter "Troubleshooting 'git apply'" beschrieben wird. Dabei werden auch Meldungen ausgegeben.

Um mich dennoch zu vergewissern, dass der Patch auch wirklich ausgeführt wurde, habe ich mit git diff [dateiname.module] die Änderungen anzeigen lassen. An Änderungen hat mir git exakt den Inhalt der Patch-Datei zurück gegeben. Kein Wunder: eine Patch-Datei stellt ja nichts anderes als einen git-diff-Auszug dar.

Nach dem Anwenden des Patches muss man einmal den Drupal-Speicher löschen, damit Drupal die veränderten Codes verwendet. Am einfachsten geht das mit Drush von der Shell per drush cc all

Beide Patches habe ich einzeln ausgeführt und die Datenbank jedesmal vorher zurück gesetzt um die Funktion testen zu können. Beide haben einwandfrei funktioniert.

Umgang mit geforkten Modulen

Durch die Patches sind die Module nun in einem veränderten Zustand gegenüber den auf drupal.org veröffentlichten Versionsständen. Sie sind geforkt.

Forks sind ein häßlicher Begriff. Manchmal lässt sich das aber nicht vermeiden. Dafür brauchen wir eine Methode, um mit diesen Forks umgehen zu können.

Wir verteilen unsere Modul im /sites/all/modules-Ordner auf verschiedene Unterordner "contrib", "custom", "features" und "fork". Normale, unveränderte Modue kommen in den "contrib"-Ordner.

Drush ist übrigens so schau, dass es neue Module beim Download automatisch im "contrib"-Ornder ablegt, so es ihn gibt.

Da sich geforkte Module nicht ohne weiteres updaten lassen, müssen sie anders behandelt werden. Beim Update ist sicherzustellen, dass alle Patches entweder weiterhin vorhanden sind oder nicht mehr benötigt werden.

Zum Nachvollziehen der Änderungen empfiehlt sich die Dokumentation der Änderungen in einer "fork.txt"-Datei, die ebenfalls im Modulordner mit abgelegt werden.

In meinem Fall sieht diese Datei so aus:

applied patch https://drupal.org/files/term_merge_not_updated-1160612-15.patch from https://drupal.org/node/1160612#comment-5642252

applied patch https://drupal.org/files/term_merge-deletingdest-1647642-1.patch from https://drupal.org/node/1647642#comment-6177436

Feedback an die Community zurück geben

Damit die Arbeit nun nicht nur dem eigenen Projekt sondern auch für die Community zugute kommt, ist es wichtig, den Patch in der Issue-Queue zu kommentieren.

Wenn man der erste Tester ist, befindet sich die Issue vermutlich im Zustand "needs review". Wenn der Patch genau das leistet, war er leisten soll, stellt man den Zustand auf "reviewed & tested by the community". So gewinnt der Patch an Vertrauen und dem Maintainer wird die Arbeit erleichtert, wenn er ein neuen Release-Stand veröffentlichen möchte.

Auf diese Weise können auch wir Nicht-Entwickler einen wertvollen Beitrag für die Community und die Weiterentwicklung Drupals leisten.

Probiert es aus! Es ist ganz einfach...

Kommentare

dawehner - 8. Oktober 2012 - 10:06
Wichtig beim Unterschied git apply/patch ist vorallem, dass neue Dateien bei letzerem manuell via git add hinzugefügt werden muss, dies kann natürlich oft zu Probleme führen (hei beir mir ging es lokal, ehrlich!) Zum Reviewen eines Patches gehört leider auch noch das lesen des Patches und dessen Bewertung. Reine Funktion ist natürlich der erste Schritt, aber dazu kommen weitere Schritte: http://drupal.org/patch/review
Anja Schirwinski - 8. Oktober 2012 - 9:25
Die Handbuch-Seite zum Patchen findet man hier http://drupal.org/patch/apply "git apply" ist eigentlich für was anderes gedacht - nehmen wir an du bist Modulmaintainer, clonest dir dein Modul und willst einen Patch darauf anwenden. Dann nimmst du git apply. Wenn man lediglich Nutzer eines Moduls ist und einen Patch aus der Queue anwenden will, nimmst du aber immer den patch-Befehl.