Stefan Wienert.net

Beruflich habe ich recht viel mit Drupal zu tun, einem in PHP geschriebenem CMS. Das Plugin-System, Module genannt, ist recht umfangreich und bietet vielfältige Möglichkeiten, fast jede Stelle des CMS’ anzupassen, ohne wirklich am Kerncode rumzuhacken.

Das ganze ist recht durchdacht, und bei weitem besser als nacktes PHP. Desweiteren bin ich kein großer “Fan” von den beiden Modulen “Views” und “CCK”, die sehr oft verwendet werden, um Modelle und SQL Statements nachzubilden. Ich bevorzuge aber Code, und nicht das Zusammenklicken dessen.

Voraussetzung für das Tutorial:

• installiertes Drupal 6
• PHP/SQL Erfahrungen

Hello World Modul

Drupal bietet zwei Ordner an, in die wir unsere Module packen können: ./modules und ./sites/all/modules. Der Konvention nach, sollten selbstgeschriebene Module in den letzteren, beides arbeitet aber korrekt.

In einen der beiden Ordner legen wir nun einen neuen Ordner an:

./modules/helloworld bzw. ./sites/all/modules/helloworld

In der Regel heißt der Ordner des Moduls so, wie das Modul selbst. Das muss aber nicht so sein. Auch können noch beliebige weitere Unterordner vorher folgen, um z.B. alle Module einer gewissen Funktionalität zu bündeln.

Ein Drupalmodul hat mindestens 2 “magische” Dateien, also Dateien, die per Definition eine besondere Rolle haben.

./helloworld/helloworld.info
./helloworld/helloworld.module

helloworld.info

./helloworld/helloworld.info ist nur eine Datei, wo Metainformationen über das Modul stehen, und woraus die Informationen für die Modulseite entnommen werden. Der Aufbau ist vorgegeben und recht kurz:

1
2
3
4
5
6
7

; $Id$
name = Hello World Modul
description = ...
package = StWienert
version = 1.0
core = 6.x
dependencies = user

Damit definiere ich, dass mein Modul vom Modul user abhängt, also nicht ohne dieses aktiviert werden kann, und in der “Package” StWienert, d.h. einer gesonderten Gruppierung “StWienert”, in der Modulübersicht zu finden ist.

helloworld.module

Dies ist eine PHP-Datei, die erst aufgerufen wird, falls unser Modul aktiviert ist. Hier der Code für ein Hello world:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
function helloworld_menu() {
  $items = array();
  $items['test/helloworld'] = array(
    'title' => 'Hello-World Site',
    'page callback' => '_helloworld_page',
    'access arguments' => array('access content'),
    'type' => MENU_CALLBACK,
  );
  return $items;
}

function _helloworld_page() {
  return "hello World";
}
# kein schließendes ?> notwendig, da die Datei inkludiert wird

Nun können wird das Modul aktivieren, und die Seite “example.com/test/helloworld” aufrufen, und sollten unser Hello World sehen.

Drupal basiert auf einem Callbacksystem. Funktionen, mit einem genau spezifizierten Namen, werden zu bestimmten Zeitpunkten aufgerufen und können Einfluss nehmen. Diese besonderen Funktionen werden “Hooks” genannt, wovon es eine ganze Menge gibt.
Hier verwenden wir den sogenannten hook_menu. Anstelle von “hook” müssen wir den (internen) Namen des Moduls einsetzen, also denselben Namen, den unsere Dateien .info und .module führen.

Ein paar der interessanteren Hook-Funktionen werde ich in einem folgenden Blogpost vorstellen, ansonsten ist ein wenig Stöbern in der Übersicht angebracht.

Addendum

Must-have-Module

Hier noch die wesentlichen Basis-Developer-Module, die ich nicht mehr missen möchte. Was hätte ich an Zeit gespart, hätte ich gleich das alles gewusst :)

• admin_menu Fügt ein JS Menü am oberen Bildrand, mit denen man sehr schnell an den benötigten Funktionen ist, und sich auf Dauer Fantastillarden an Klicks erspart. Ausserdem gibt es einen “Cache leeren” Button unter dem ersten Menüpunkt. Dieser ist wichtig, um z.B. den hook_menu unseres Moduls nach einer Änderung noch einmal aufgerufen wird. Sonst wird u.a. die Menüinformation gecacht.
• devel Fügt zwei für mich wesentliche Dinge ein; eine Funktion “dpm($variable)”, die wie das print_r von PHP funktioniert, aber das ganze wesentlich übersichtlicher. Zweiteres einen Error-Backtrace. Also statt “Whitescreen of Death” gibt es detaillierte Fehlerinformationen, neben einer Fehlermeldung und exakter Ort des Auftretens auch alle Variablen des aktuellen Kontextes. Quasi ein Debugger für Arme. Das Modul hat noch viele Features mehr, ein Blick lohnt.
• drush Drupal-Shell. Dies ist kein Drupalmodul, sondern ein externes Programm, das eine neue Schnittstelle zu Drupal eröffnet, nämlich die Kommandozeile. Dies kann natürlich nur installiert werden, wenn man Shellzugriff auf seinen Server hat. Hier ein paar Leckerbissen:

1
2
3
4
5
6
7

drush dl admin_menu && drush en admin_menu
# Ladet das Modul admin_menu herunter, entpackt es 
# nach sites/all/modules, dann wird das gleich aktiviert (enabled)
drush cc
# leert den Cache
drush eval "echo 'hello world'"
# Führt beliebigen PHP Code im Kontext des Drupals aus

CRE

Der Chaosradio-Radio-Express Podcast hat eine Sendung zum Thema Drupal. Hierbei geht es aber nicht um die Modulentwicklung, sondern um das Ökosystem allgemein.
Interessant ist das Fazit von Tim Pritlove: “Es ist ja nicht so, dass es [Drupal a.d.R.] sich anbiedern würde”. Ja das stimmt, Drupal haut nicht vom Hocker, und gerade die Features der z.B. DatenbankAPI nicht gerade auf Höhe der Zeit. Aber es ist was grundsolides und sehr flexibles.

Wenn ich zur Zeit während meines Praktikums etwas Zeit habe, arbeite ich an ein paar Hobbyprojekten, die mir so in letzter so eingefallen sind:

• Ein (hübsches) (openSource) DMS basierend auf Rails, welches doc, pdf, odf, text archiviert, taggt und indexiert, um die Dokumente leichter wiederzufinden
  • mit Paperclip, Ferret als Indexierungsdienst, Verwendung von pdftotext, antiword, odf2text und eventuell tesseract zum OCR (auch für Bilder und pdfs), rspec BDD Tests für die Modelle
• Einen “Bot”, der die eigene Website abgrast um interne Linkverbindungen als Graphen darzustellen, um so lange Wege zu finden und zu eliminieren (Webdesignregel: Redundanz und kurze Wege)
  • Ruby mit mechanize oder evtl. auch einfach “wget -spider” nehmen, graphviz
• Drupal Scaffold Ein Ruby Skript, welches mir, ähnlich dem scaffold von Rails, ein Datenmodell in ein (MySQL) Schema gießt, und auch gleich einen (einfachen) Adminsetter dazu liefert (eine Seite unter admin/settings/%name mit der Option, ein neues Objekt anzulegen und alte anzuschauen.

Wer viel mit drupal arbeitet und gerne gedit nehmen möchte, sollte sich mal diese Snippet und Mimitype Collection auf github anschauen.

Einfach z.B. “hook” eingeben, <tab> und schon hat man eine Auswahl aller hooks, welche nach Auswahl gleich eine ordentliche Portion Quelltext mitbringen – UND – gleich den Modulnamen beinhalten (abgeleitet aus dem Datennamen).
Fazit: Massig Zeit gespart :)

Wermutstropfen: Seit dem Upgrade von Ubuntu Jaunty auf Karmic Koala geht das mit dem Modulnamen nicht mehr. Ich Habe beim Autor auf github mal einen Bugreport verfasst, in der Zwischenzeit kann man folgende Shellkommandos ausführen um die Snippets dennoch lauffähig zu bekommen. (Ich gehe davon aus, dass die Snippets bereits importiert sind, ansonsten das sed Kommando auf die “drupal.xml” im git-Verzeichnis ausführen)

1
2

cd ~/.gnome2/gedit/snippets/
sed -i 's/\$GEDIT_BASENAME/\$GEDIT_CURRENT_DOCUMENT_NAME/g' drupal.xml