Unbenötigte Module in Drupal-Projekten

In jedem Drupal-Projekt ist es äußerst wichtig, dass die Anwendung stets vollständig über Code definiert ist. Indem mit einem sauberen Konfigurationsmanagement (auf Basis von Git, Features, Drush-basierten Shell-Skripten und Master) gearbeitet wird, ist es möglich den kompletten Konfigurationsstatus der Drupal 7 Anwendung nachvollziehbar und reproduzierbar festzuhalten.

Drupal-Modulliste überwachen

Auf diese Weise hat das Team für die Entwicklung der Anwendung ein gutes Werkzeug in der Hand. Es kann hierüber sogar den Status der Drupal-Module im Projekt zentral verwalten. Besonders in großen Drupal-Projekten ist es immer wichtig, die Module zu kennen, die eingesetzt werden, welche Module aktiviert sind und welche Module deaktiviert werden können. Selbst bereits deaktivierte Drupal-Module beeinflussen das System und die allgemeine Developer-Experience des Teams.

Eine große Anzahl an Modulen im Projekt erhöht das Rauschen für die Entwickler. Während sie versuchen die Ziele des aktuellen Entwicklungssprints umzusetzen, werden sie zum Beispiel bei der Suche nach einem Code-Schnipsel im Projekt zur Analyse eines Problems mit Ergebnissen konfrontiert, die in bereits nicht mehr genutzten Modulen gefunden werden. Unter anderem aus solchen Gründen ist es wichtig alle Module, die nicht benötigt werden, zu deaktivieren und vollständig zu deinstallieren. Wenn möglich sollten diese Module dann im Anschluss vom Projektverzeichnis entfernt werden. Da wir (hoffentlich) alle mit einem Versionskontrollsystem (wie Git) arbeiten, ist es gefahrlos die Module zu löschen, ohne dabei Informationen zur Projektentwicklung zu verlieren.

Module mit Master entfernen

In Projekten, die über mehrere Monate gewachsen sind und dabei niemand einen Blick in Modulverzeichnis geworfen hat, wird es schmerzvoll und zeitintensiv diese unnötigen Module zu entfernen. Um im Entwicklungsprozess bei dieser Aufgabe zu unterstützen haben wir vor einiger Zeit das Master-Modul entwickelt. Mit der neuesten Version von Master haben wir zudem einen neuen Befehl eingeführt, der dabei unterstützt Module zu finden, die im Projektverzeichnis gar nicht mehr benötigt werden.

Mit drush master-removables wird eine Liste aller Drupal-Modulverzeichnisse ausgegeben, die vom Projektverzeichnis gelöscht werden können. Wenn dieser Befehl mit dem Löschbefehl kombiniert wird, können die Dateien so automatisch entfernt werden:

rm -rf $(drush master-removables --absolute --pipe)

Vorher sollte natürlich die Ausgabe von drush master-removables noch einmal überprüft werden. Besonders wenn auf unterschiedlichen Staging-Umgebungen ausgerollt wird (wie develop, testing, live), ist darauf zu achten, dass auf allen Systemen die zu löschenden Module vorher vollständig in Drupaldeinstalliert wurden.

Zum Beispiel, wenn das Team in Sprint 11 entscheidet doch nicht mehr mit dem Context-Modul arbeiten zu wollen, aber es bereits in einem vorherigen Sprint ausgerollt und aktiviert wurde, kann das Modul nicht einfach im Sprint 11 vom Git-Repository gelöscht werden. Das Modul wird nämlich beim nächsten Roll-Out noch benötigt um auf dem Produktivsystem das uninstall-Prozedere anzustoßen. Das Modul darf daher nur vollständig nach dem erfolgreichen Roll-Out gelöscht werden, was meist im nächsten Sprint erfolgen kann.Tipp: Wenn diese Situation auftritt, ist es ratsam sich für den nächsten Sprint selbst daran zu erinnern, indem ein neues referenziertes Ticket dafür ins Backlog für den anstehenden Sprint gelegt wird.

Fehlende Module

In manchen Fällen, z.B. wenn Module sorglos aktualisiert oder entfernt wurden, kommt es vor, dass Module fehlen, obwohl sie von der Drupal-Installation noch benötigt werden. Problematisch wird es vor allem, wenn ein Modul vom Dateisystem entfernt wurde, obwohl es noch aktiviert war. In diesem Fall ist sogar mit erheblichen Performance-Verlusten zu rechnen.

Damit wir nicht in ein solches Szenario rennen, enthält der neueste Master-Release auch einen Befehl, der die Module auflistet, die nicht in der Installation sind, aber dort sein sollten. Mit drush master-absent wird die Liste ausgegeben, anhand derer eventuelle Probleme gelöst werden können.

Der Befehl listet dabei auch Module auf, die zwar Teil der Master-Konfiguration sind, aber nicht im Modulverzeichnis zu finden sind.

Master-Development

Uns interessiert natürlich eure Erfahrung mit Master und anderen Ansätzen zur Verwaltung vom Drupal-Modul-Status. Da wir aktuell die Entwicklung eines Stable-Releases für Drupal 7 voran bringen wollen, freuen wir uns über jedes Feedback in der Master-Issue-Queue auf drupal.org.

Zudem unterstützen wir euer Team natürlich auch gerne bei der Optimierung des Drupal-Entwicklungsablaufes und helfen gerne mit unserer professionellen Drupal-Dienstleistung.