Das Problem: Für eine Firmenwebsite soll eine Möglichkeit geschaffen werden, dass eingeloggte Kunden Beiträge schreiben können, an die sie Dateien (hier Sprachdateien in den Formaten mp3, wav u.a.) anhängen können. Diese Dateien sollten dann überarbeitet werden und die Arbeitsergebnisse wieder an den Beitrag agehängt werden, damit der Kunde sie sich wieder herunterladen kann. Da die Dateien natürlich vertraulich sind, soll jeder nur seine Dateien sehen und herunterladen können. Nach dem Einrichten des privaten Modus in Drupal kann zwar jeder seine Dateien hochladen und an die Beiträge hängen, aber keiner kann eine Datei herunterladen – nicht einmal der Admin! Stattdessen erscheint nur die Fehlermeldung "Zugriff verweigert. Sie haben keine Zugriffsberechtigung für diese Seite."

Die meisten Blogs gestatten es ihren Besuchern, dass man Kommentare schreiben kann ohne sich dafür anzumelden. Das geht auch bei Kommentaren auf einer Drupal-Webseite. Allerdings wird dann hinter dem Namen des Kommentarautors stets ein "(nicht überpüft)" angehängt. Dieser Text erscheint auch in der Liste der neuesten Kommentare, wenn man den entsprechenden Block aktiviert hat.

Schön ist dieser Eintrag nicht und bis einschließlich Drupal 6 gibt es auch für den Admin keinen Schalter, um ihn loszuwerden. Ab Drupal 7 kann man immerhin in den Theme-Einstellungen die Anzeige des User-Status' deaktivieren, womit der Text verschwindet. Bei früheren Drupal-Versionen muss man dagegen mehr oder weniger aufwändige Eingriffe in der PHP-Dateien des Themes vornehmen (Achtung: Bitte niemals die Drupal-Core-Dateien oder die Dateien der mitgelieferten Themes ändern, sondern immer eine Kopie des Themes in ../sites/all/themes erstellen und diese anpassen!).

Eine andere Lösung gibt es für Drupal 6 (und 7), in Form des Moduls Submitted By. Damit kann man, in Verbindung mit dem Token-Modul, die gesamte Zeile die unterhalb eines Kommentares (aber auch einer Node!) erscheint nach belieben gestalten. Wer schon mit dem Token-Modul gearbeitet hat, wird keine Schwierigkeiten haben, seine Autorenzeilen anzupassen.

Und so gehts:

Es gibt viele Anwendungen, bei denen es Sinn macht, Ortsangaben auch für die Anzeige in einer Karte zu verwenden. So erleichtert man seinen Kunden das Auffinden einer Filiale oder visualisiert Anbieter-Verzeichnisse, Standorte von Mietfahrzeugen etc.

Drupal bietet hierfür einige sehr interessante Module. So kann man mit Hilfe des Moduls "Location" nicht nur eine Suche nach Geo-Koordinaten durchführen, sondern auch nach Postleitzahlen. Durch seine Integration mit "Views" und "CCK" lassen sich sehr flexible Lösungen gestalten. So lassen sich gefundene Standorte direkt in einer Karte von GoogleMaps oder Bing anzeigen.

Und so geht's:

Benötigt werden die Module

Views (das sollte sowieso in keiner Drupal-Installation fehlen)

Location (ab Version 6.x-3.1)

GMap Module

Einen Schwachpunkt gibt es bei Drupal, der auch in der aktuellen Version 7 noch nicht behoben wurde: Grundsätzlich weiß Drupal über die Zugehörigkeit von Inhalten zu bestimmten Menüpunkten nur dann Bescheid, wenn die jeweilige Node direkt mit diesem Menüpunkt verknüpft ist. Werden Nodes nun auf einer Übersichtsseite zusammengefasst (z.B. in verkürzter Form mit „Weiterlesen“-Link zum vollständigen Beitrag), die einen eigenen Menüpunkt besitzt und man klickt eine dieser Nodes an um den vollen Text zu lesen, fehlt die Information, welcher Menüpfad (engl. menu trail) dabei aktiv bleiben soll.
Ein Beispiel soll die Problematik verdeutlichen:

Wir haben eine Taxonomy mit den drei Taxonomy-Terms ProjektA, ProjektB und ProjektC.

Die Nodes mit den Inhalten sind wie folgt den Taxonomy-Terms zugeordnet:
Node1: 1. Beitrag ProjektA >> ProjektA
Node2: 2. Beitrag ProjektA >> ProjektA
Node3: 1. Beitrag ProjektB >> ProjektB
Node4: 2. Beitrag ProjektB >> ProjektB
Node5: 1. Beitrag ProjektC >> ProjektC

Dazu gibt es eine Menüstruktur nach folgendem Muster:

Menüpunkt1
Menüpunkt Projekte
>> Menüpunkt ProjektA
>> Menüpunkt ProjektB
>> Menüpunkt ProjektC
Menüpunkt3
...

Die drei Projekte-Untermenüpunkte zeigen jetzt per View alle Artikel an, die jeweils mit dem korrespondierenden Taxonomy-Term versehen sind. Wie man auf dem Screenshot sieht ist nach dem Klick auf auf den Menupunkt „Projekte>>Projekt A“ der entsprechende Menüpunkt als aktiv gekennzeichnet und die Seite zeigt alle Beiträge zu diesem Projekt an. Weiterhin zeigt die Breadcrumb korrekt „Startseite » Projekte“ an.

Bis hierher ist also alles in Ordnung.

Bis Drupal 6 konnte man "lesbare URL" (auch URL-Aliase genannt) sehr leicht mit Hilfe von Taxonomy-Terms nach diesem Muster erstellen:

[vocab]/[termpath]/[title]

Dabei ist [vocab] die Bezeichnung des Taxonomy-Vokaburlars, das einem Inhaltstypen zugeordnet ist, [termpath] der Taxonomiebegriff (ggf. mit übergeordneten Begriffen, bei einer Baumstruktur) und [title] der Titel einer Node (also die "Überschrift" eines Inhaltes). So ließen sich anstelle wenig aussagekräftiger URLs wie

meine.domain.de/node/1798

ansprechendere URLs wie diese automatisch erstellen (wobei der Begriff "hardware" ein Taxonomy Term ist):

meine.domain.de/magazin/hardware/reparatur-eines-scanners

In Drupal 7 wurde allerdings das Taxonomy-System geändert. Ein Taxonomy-Vokabular wird jetzt nicht mehr durch Auswählen der Inhaltstypen in "Vokabular bearbeiten" zugeordnet. Stattdessen muss man zunächst bei dem Inhaltstypen ein CCK-Feld erstellen. Diesem den Feldtyp "Referenz auf Taxonomy-Begriffe" geben und anschließend das gewünschte Vokabular auswählen.

Die Schritte dazu im Einzelnen:

Kleine Ursache, große Wirkung: Nach dem Liveschalten einer neuen Kunden-Webseite sollte noch geschwind ein View geringfügig geändert werden. Eigentlich eine Kleinigkeit, die sonst keine zwei Minuten dauert. Aber diesmal kam es anders. Beim Speichern der Änderung in der Eingabemaske (ein via Javascript erzeugtes Overlay) kam diese Fehlermeldung:

An AJAX HTTP request terminated abnormally.

Debugging information follows. http://die-kundendomain.de//admin/structure/views/ajax...

StatusText: error

ResponseText:

ReadyState: 0

Die einzige Möglichkeit aus dem Dialog wieder rauszukommen, war ein Klick auf das "Abbrechen"-Kreuz oben rechts in dem Overlay. Was natürlich ziemlich unpraktisch ist, da der View damit nicht bearbeitbar war und diese seltsame, nichtssagende Fehlermeldung an zahlreichen Stellen auftrat. Da die Views in der Entwicklungsversion fehlerfrei funktionierten,  alle Module auf dem neuesten Stand waren und auch PHP die gleiche Version hatte, war die Sache zunächst rätselhaft und konnte nur mit den letzten Arbeitsschritten nach dem Übertragen der Seite aus der Entwicklungs- in die Produktivumgebung zusammenhängen.

Nach etwas Suchen war der Fehler dann schließlich rasch gefunden: Auf der Liveseite war in der htaccess die Regel zum Umschreiben des Domainnamen auf "mit www." eingeschaltet worden, so dass aus die-kundendomain.de immer www.die-kundendomain.de wurde.

  # To redirect all users to access the site WITH the 'www.' prefix,<br />
# (<a href="http://example.com/" title="http://example.com/">http://example.com/</a>... will be redirected to <a href="http://www.example.com/" title="http://www.example.com/">http://www.example.com/</a>...)<br />
# uncomment the following:<br />
RewriteCond %{HTTP_HOST} !^www\. [NC]<br />
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]<br />

In der settings.php von Drupal stand jedoch noch

$base_url = 'http://die-kundendomain.de';  // NO trailing slash!

also ohne vorangestelltes "www". Nachdem das in

$base_url = 'http://www.die-kundendomain.de';  // NO trailing slash!

geändert wurde, waren die AJAX-Fehler verschwunden.

Drupal besitzt von Haus aus keine Möglichkeit, interne oder externe Links zu verwalten. D.h. es gibt keine automatisierte Prüfung, ob diese Links noch gülitg sind. Dabei kann es schnell passieren, dass ein Link zerbricht. Sei es, dass eine Seite gelöscht, verschoben oder durch einen andere ersetzt wird. Zumindest bei internen Links besteht dann noch die Chance, dass man die Links manuell ändert – sofern man sich noch an alle Verlinkungen erinnern kann. Bei externen Links bekommt man derartige Änderungen aber gar nicht erst mit. Schön wäre es daher, wenn es wenigstens eine regelmäßig Überprüfung aller Links gäbe und man anschließend alle gebrochenen Links aufgezeigt bekommt. Ob man diese dann ändert oder ganz entfernt ist dann jedem selbst überlassen. 

Drupal besitzt standardmäßig Funktionen, um ein Blog zu betreiben. Wer seine Seite mit den Standardeinstellungen installiert hat stellt allerdings sehr schnell fest, dass Drupal da doch einiges fehlt, dass Spezialisten wie Wordpress von Haus aus mitbringen. Wenn man beispielsweise ein Blogposting liest, so gibt es keine Möglichkeit, zum vorherigen oder nächsten Blogposting weiterzublättern. Man muss erst zurück auf die Übersichtsseite, um dort dann den nächsten Beitrag aufrufen zu können. Aber es gibt ja fast nicht, was man Drupal nicht nachträglich beibringen könnte. Und so gehts:

Joomla 1.0.x ist nun ja doch schon ziemlich in die Jahre gekommen und ein Upgrade einer Kundenseite auf Joomla 1.6 war eigentlich dringend angeraten. Aber da man mit Joomla nicht mehr richtig zufrieden war, sollte ein Wechsel zu Drupal geprüft werden. Das Ergebnis läßt sich mit einem Satz zusammenfassen: Es geht, ist auch gar nicht schwer, macht aber einige Arbeit.

Die Joomla-Installation war nicht besonders komplex, enthielt aber neben zahlreichen Artikeln in verschiedenen Sektionen und Kategorien eine Bildergalerie, einen Newsletter und diverse Webformulare. Für die Migration der User und Inhalte zu Drupal kam das Drupal-Modul "Joomla-to-Drupal Converter" zum Einsatz. Damit lassen sich alle User und Inhalte (auch der static content) nach Drupal migrieren. Die Bezeichnungen der Joomla-Sektionen und -kategorien werden dabei in einem Taxonomy-Vokabular abgebildet. Allerdings gibt es einige Fallstrick über die man stolpern kann, die sich aber bei richtiger Vorbereitung leicht meistern lassen.

Und so geht's:

Mit dem Modul Webform kann man in Drupal sehr einfach Formulare für seine Webseite erstellen. Das Modul ist sehr flexibel und mächtig, so dass auch sehr indiividuelle und umfangreiche Onlineformulare erstellt werden können. Zur Auswertung des Formulars war es sogar möglich eigenen PHP-Code an das Formular zu übergeben. Aus Sicherheitsgründen haben die Entwickler dieses Feature vor einiger Zeit stillschweigend entfernt.

Das führt bei einem Update älterer Webform-Installationen zu Problemen, wenn dort eigener PHP-Code unter "additional validation" eingetragen war, denn dieser wird von neueren Webform-Versionen nich mehr ausgeführt, was die Funktion des betroffenen Formulars beeinträchtigt oder dieses unbenutzbar macht. Um das Problem zu lösen, gibt es mehrer Möglichkeiten. Die einfachste - aber auch unsicherste - ist der Einsatz von  webform_php. Dieses Modul fügt das Feld "additional validation" wieder ein und der dort noch gespeicherte Wert bleibt erhalten, so dass das Formular sofort wieder benutzbar ist. Aus Sicherheitsgründen sollte die Benutzung dieser Funktion auf den Webmaster oder Admin der Seite beschränkt bleiben. Alternativ kann man Webform Validation benutzen. Dieses bietet diverse vorgefertigte Validierungsfunktionen. Zusätzlich können eigene Funktionen unter Verwendung des Hook hook_webform_validation_validators() programmiert werden. Da es Usern nicht möglich ist, direkt eigenen PHP-Code in ein Webformular einzutragen, bietet dieses Modul maximale Sicherheit.