Suchmaschinenfreundliche URLs erhält man bei Drupal am einfachsten, wenn man neben dem Core-Modul Path auch Pathauto und Token einsetzt. Im Zusammenspiel mit Taxonomy lassen sich sehr schöne suchmaschinen- und benutzerfreundliche URLs erzeugen. Allerdings lauert hier eine Falle, die man unbedingt kennen sollte, um keine unangenehme Überraschung zu erleben.

Ein View kann verschiedene Ansichten bereitstellen, zum Beispiel einen Block, eine Seite oder einen Anhang, den man wiederum an einen Block oder eine View-Seite anhängen kann. Eine solche View-Seite läßt sich zusätzlich mit Kopf- und Fußtexten ergänzen. Was aber, wenn man einen View - beispielsweise eine Terminliste - in eine anderen Seite - z.B. eine Node mit einer Kursbeschreibung - einbinden will? Das ginge zum Beispiel mit einem iFrame, aber das ist keine besonders elegante Lösung. Besser geht es mit dem Modul Insert View .

Je nach Anzahl der Autoren oder Redakteure die eine Website betreuen kann es schonmal passieren, dass zwei gleichzeitig ein und den selben Beitrag bearbeiten wollen. Der übliche Drupal-Mechanismus ist in diesem Fall, dass derjenige, der zuerst seine Änderungen speichert, das Rennen gewinnt und der andere - der gerade den gleichen Inhalt bearbeitet - eine Fehlermeldung bekommt, wenn er seinerseits diesen Beitrag zu speichern. Das ist ebenso lästig wie ärgerlich, vor allem wenn dabei die mühsam eingegebenen Änderungen verloren gehen.. Besser wäre es, wenn Drupal in so einem Fall den zweiten Benutzer schon vor dem Öffnen des Beitrags darauf hinweisen würde, dass dieser zur Zeit bearbeitet wird und ihm den Zugriff verweigert. Bei Joomla wird diese Methode angewendet und ich finde das ist die bessere Lösung.

Einen solchen  Mechanismus implementiert das Modul Checkout.

Es gibt in Drupal zahlreiche Funktionen und Module, die in der Lage sind E-Mails an einzelne User oder ganze Gruppen zu versenden, sei es als Newsletter oder zur Benachrichtigung über bestimmte Ereignisse. Nun kann es sein, dass man während der Entwicklungs- oder Testphase einer neuen Website, bereits mit realen Daten arbeiten (muss), die der Kunde geliefert hat. Da kann es dann leicht passieren, dass unerwünschte, automatische E-Mails an reale Empfängeradressen versendet werden. Dies läßt sich mit Hilfe des Moduls Advanced Mail Reroute vermeiden.

In Joomla gibt es in der Inhalteverwaltung eine Kopierfunktion. Wählt man einen Artikel aus und klickt auf den Copy-Button, so wird eine Kopie des Artikels erstellt. Nützlich, weil damit alle Einstellungen des Originals übernommen werden und man nur noch den Inhalt ändern muss.

Bei Drupal gibt es eine solche Funktion standardmäßig nicht. Sie läßt sich aber leicht nachrüsten mit dem Modul Node Clone. Sobald man es installiert hat, fügt es bei jedem oberhalb eines Beitrags einen neuen Tab "duplizieren" hinzu. Klickt man auf diesen, so erstellt es eine Kopie des Beitrages. Dieser wird im Titel mit dem Zusatz "Duplikat von" als Kopie gekennzeichnet und übernimmt alle Inhalte und Einstellungen des Originals. Nun kann es aber Fälle geben, wo man bei der Kopie die Einstellungen auf Standardwerte zurück setzen möchte. Dies kann man in der Konfiguration von Node Clone für jeden Inhaltstyp separat einstellen. Das ist angenehm, wenn man z.B. jeden Artikel erst einmal auf "unpublished" haben will, damit er nicht versehentlich veröffentlicht wird, obwohl man nur einen Entwurf abspeichern will, der noch überarbeitet werden soll. Außerdem gestattet Node Clone, die Kopierfunktion bei jedem Inhaltstyp abzuschalten. Das ist zum Beispiel bei Inhaltstypen sinnvoll, die nur ein Bild enthalten. Hier bringt eine Kopie keine Arbeitsersparnis. Natürlich kann man in den Benutzer-Berechtigungen auch einstellen, welche Rolle Zugriff auf diese Funktion erhalten soll.

Alles in allem ein sehr praktisches Modul, dessen Funktionalität gerne Einzug in den Drupal Core halten dürfte.

Zum Testen einer Website auf Drupal-Basis (aber natürlich auch bei jedem anderen CMS) gehört im Regelfall auch, die Seite mit den jeweils erstellten Benutzerrollen zu prüfen. Denn nur so läßt sich feststellen ob alle User die korrekten Berechtigungen besitzen - nicht zu wenige, da sonst die Funktion nicht gewährleistet ist, aber auch nicht zu viele, weil sonst Sicherheitslücken entstehen können. Der normale Weg - ausloggen, als Testuser mit einer anderen Rolle wieder einloggen - ist das Mittel der Wahl, wenn man einen umfangreichen Testlauf durchführt und viele Funktionen in einem Durchgang prüfen möchte. Alternativ kann man natürlich auch mit einem zweiten Browser arbeiten und sich dort mit der jeweiligen Testrolle einloggen. Will man aber nur mal schnell zwischendurch in eine andere Rolle schlüpfen, um z.B. ein vom Kunden berichtetes Fehlverhalten zu prüfen, oder um mit anderen Rechten etwas vorzuführen, so ist das aus- und wieder einloggen ebenso mühsam wie das Starten eines neuen Browsers. Hierfür bietet das Drupal-Modul Masquerade eine komfortable Lösung: es stellt verschiedene Optionen zur Verfügung, um zwischen verschiedenen Benutzern hin und her zu schalten. Zum einen bietet es einen Link "Masquerade as (Benutzername)" auf der Profilseite jedes Benutzers an - natürlich nur, wenn man die entsprechende Berechtigung zum "Maskieren" hat! Klickt man diesen an, sieht man die Website ab sofort mit den Rechten, die mit der Rolle dieses Benutzers verbunden sind. Gleichzeitig erscheint im persönlichen Menü ein Eintrag "Switch Back", mit dem man genauso schnell zurück wechseln kann. Zusätzlich gib es einen Eintrag (oder auch mehrere) der einen schnellen Wechsel zu einem festgelegten (Default-)Benutzer gestattet, sowie einen Block, wo man nach Benutzernamen suchen und dann in dessen Rolle schlüpfen kann.

Jeder Rollenwechsel wird übrigens von Drupal in der Log-Datei protokolliert, so dass man diese später nachvollziehen kann. Sobald die Website online geht, empfiehlt es sich, Masquerade wieder zu deinstallieren.

Drupal muss in regelmäßigen Abständen bestimmte Arbeiten für die Systempflege erledigen. Dazu gehören zum Beispiel das Erfassen neuer Inhalte im Suchindex, der Versand von E-Mails oder das Prüfen auf neue Updates für Drupal und seine Module. Am besten erledigt man dies natürlich durch einen Cron-Job.Dazu trägt man in der Crontab seines Servers einen Eintrag ähnlich diesem ein:

45 * * * * /usr/bin/lynx -source http://example.com/cron.php

Damit ruft der Cron-Dämon den - auf fast jedem Linux installierten - Textbrowser Lynx auf, der seinerseits die gewünschte Drupalseite aufruft und dort die Datei cron.php ausführt. Diese arbeitet dann alle anstehenden Arbeiten. Aber was tun, wenn man keine Möglichkeit hat für seine Website einen Cron-Job einzurichten? 

Drupal bietet umfangreiche Möglichkeiten, um den Zugang zu Inhalten in Abhängigkeit von der Benutzerrolle zu regeln. Neben den Möglichkeiten die im Drupal-Kern existieren, gibt es zahlreiche Erweiterungen, wie zum Beispiel Taxonomy Access Control. Hiermit wird aber stets der Zugang zum gesamten Inhalt einer Node den Betrachtern gestattet oder verboten. Möchte man dagegen nur bestimmte Textteile ein- oder ausblenden, so ist Restricted Text ein geeignetes Werkzeug.

Es sorgt dafür, dass bestimmte Texte, die mit den Markierungen [restricted] und [/restricted] umschlossen sind nur für bestimmte Rollen sichtbar werden. So kann man z.B. auf einer Ankündigungsseite für eine Online-Schulung  die Zugangsdaten in den für alle sichtbaren Text schreiben. Durch die Markierung als "restricted" werden sie erst sichtbar nachdem sich der Besucher eingeloggt hat, so dass der Zugang beispielsweise auf zahlende Mitglieder beschränkt bleibt.