Drupal 7 – Hook-System Teil 1

Im Rahmen eines Projekts habe ich etwa einen Monat mit dem bekannten CMS Drupal 7 gearbeitet. Ich erlaube mir nach diesem Zeitraum mit einem Feature von Drupal 7 abzurechnen. Die meisten werden schon aus dem Namen des Artikels erkannt haben, dass es sich bei diesem Feature um das Hook-System von Drupal 7 handelt.

Wie auch viele weitere Content-Management-Systeme hat Drupal 7 einen Möglichkeit mit dem ein Entwickler sich in verschiede Vorgänge einklinken kann und dabei können Daten verändert werden, aber auch das Content-Management-System mit Funktionalitäten erweitert werden. Nun ist so ein Hook-System per se nicht als Schlecht zu bezeichnen, da solche Schnittstellen in so gut wie jedem Content-Management-System existieren und das Hook-System die Basis der Starke Modularisierung der Content-Management-System ist. Nun bin ich aber sehr unglücklich mit der Art und Weise wie das Hook-System in Drupal 7 implementiert worden ist.

Zunächst möchte ich kurz darstellen, wie ein Entwickler auf das Hook-System von Drupal 7 zugreift. Dabei wird in Drupal 7 davon ausgegangen, das nur von sogenannten Modulen auf das Hook-System zugegriffen wird. In unserem Fall nennen wir unser Module mymodule und wir möchten auf den Hook, welcher nach der Aktivierung des Modules aufgerufen wird, zugreifen. Zu diesem Zweck muss nur die folgende Funktion definiert werden.

function mymodule_enable {
  ...
}

Auf den ersten Blick wird jeder Entwickler sagen: “Sind wir wirklich schon fertig?” Und ich kann aus Erfahrung sagen, ja das ist wirklich schon alles. Nun hat das Hook-System von Drupal 7 so gut wie keinen spürbaren Overhead. Jedoch z.B. für Drupal 7 Neulinge wie mich, war zu Beginn gar nicht erkennbar, dass wir hier schon auf das Hook-System zugreifen. Außerdem leben wir in keinem Mikrokosmus und mit dem weiteren Verlauf des Projekts wird das Module größer und größer. Schlussendlich sind wir ganz schnell bei 50 oder mehr Methoden für das gesamte Module und dabei greifen nicht mal alle Methoden auf das Hook-System zu. Viele der Methoden sind einfach nur Hilfsmethoden, welche Duplikated-Code verhindern sollen oder eine Funktionalität in logische Unterfunktionen aufteilen sollen. Jedem Entwickler der mir aus dem Stehgreif unter 50 Module Methoden sofort sagen kann, welche der Methoden auf das Hook-System zugreifen und welche nicht, gebe ich sehr gerne ein Bier aus, aber die Realität sieht anders aus. Des Weiteren hat alleine Drupal 7 knapp über 700 Hooks, welche sich in der Gesamtheit kein Entwickler merken kann. Aus diesem Grund wird häufig die Definition der Methode wie folgt erweitert, damit klar zu erkennen ist, dass diese Methode auf das Hook-System zugreift.

/**
  * Implement hook_enable()
  */
function mymodule_enable {
  ...
}

Nun haben wir schon den ersten Overhead für den Zugriff auf das Hook-System. Davon Mal abgesehen, dass diese Methode auf gar keinen Fall bei Refactoring-Maßnahmen umbenannt werden darf. Schauen wir uns das ganze mal in einem anderen Content-Management-System wie z.B. WordPress an. Mir ist bekannt, das WordPress auch viele Fehler hat, jedoch beim Hook-System haben sie bis auf die Tatsache einer nicht vorhandenen objekt-orientierten Schnittstelle, eine guten Job erledigt. Hier nun dasselbe Beispiel mit WordPress:

add_action('activate_'.__FILE__, function() {
  ...
});

Nun haben wir in WordPress ein kleines bisschen mehr Overhead, indem wir eine Funktion aufrufen müssen und einen String für den Namen des Hook übergeben müssen. Der Vorteil liegt hier in der klaren Schnittstelle. Mit der Methode add_action weiß jeder Entwickler, dass die übergebene Funktion in das Hook-System eingebunden wird. Außerdem lässt add_action sogar zur das wir in PHP auf eine Funktion eines Objekts verweisen können.

class MyModule {
  public function activate() {
    ...
  }
}

add_action('activate_'.__FILE__, array(new MyModule(), 'activate'));

Abschließend möchte ich nur sagen, das sich Drupal 7 mit einer extrem simple Schnittstelle für das Hook-System auf der anderen Seite schlecht lesbaren Code, schlecht Wartbaren Code und nicht auf heutigen objekt-orientierte Paradigmen anwendbare Schnittstelle erkauft hat. An diesem Beispiel ist deutlich erkennbar das Drupal schon im nächsten Jahr 15 Jahre alt wird und hier einiges an Altlasten über ein Jahrzehnt mitgeschleift wurde. Ich bin sehr froh das mit Drupal 8 ein großer Teil des Core-Systems ausgetauscht wird und hoffe das hier die Fehlern von Drupal 7 nicht wiederholt werden.