Das Modul Author Taxonomy  setzen wir gelegentlich bei Webprojekten ein. Da es bisher keine deutsche Sprachdatei gab, haben wir es schnell selber übersetzt. Die beiden po-Dateien haben wir dem Autor des Moduls zur Verfügung gestellt, so dass sie vielleicht beim nächsten Release im Paket enthalten sind. Bis dahin stellen wir Sie hier zum Download zur Verfügung.

Nicht immer möchte man die Taxonomy-Begriffe (Taxonomy Terms) oberhalb einer Node angezeigt bekommen. Im konkreten Fall, hatte ein Inhaltstyp zwei solcher Vokabulare. Dabei sollten die Begriffe des einen Vokabulars über der Node erscheinen, die des anderen jedoch nicht. Leider gibt es erst ab Drupal 7  eine Steuerung für die Taxonomy-Begriffe. Bis dahin muss man entweder auf spezielle Module zurückgreifen , das Template ändern oder die Anzeige mit Hilfe von CSS unterbinden. Das Modul Taxonomy Hide ist eine Möglichkeit die Sichtbarkeit von Taxonmy Terms zu beeinflussen. Es bietet für jedes Vokabular einen Schalter, um die Ausgabe der Begriffe zu unterdrücken. Diese Einstellung gilt dann allerdings für alle Inhaltstypen, denen dieses Vokabular zugeordnet ist.

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.

Das Forum-Modul von Drupal ist für sich alleine genommen eher nicht das, was erfahrene Forum-Benutzer erwarten. Installiert man dazu jedoch das Modul Advanced Forum, so sieht das ganze schon anders aus. Natürlich kann es vom Funktionsumfang nicht mit Spezialisten wie vBulletin, Simple Machines Forum oder phpBB3 mithalten - das ist einfach eine andere Zielgruppe - aber dafür ist das Forum nahtlos in die Website integriert (vBulletin kann man zwar recht gut mit Hilfe von Drupal vB anbinden, aber nahtlos integriert ist es bei weitem nicht) und einfach zu bedienen und zu administrieren.

Eine Sache fehlte dann aber kürzlich auf einer Kunden-Website doch: eine Navigation nur für das Forum. Zwar gibt es auf der Website die Breadcrumb, aber die war für Forumbesucher doch eher ungewohnt und nur schwer als Navigationshilfe erkennbar. Statt dessen sollte direkt über der Forenliste, bzw. den Threads eine Navigation in Form von Buttons erscheinen. Im Gegensatz zur Breadcrumb allerdings ohne den führenden "Home"-Link. Wenn die Breadcrumb also so aussah

Home » Forums » Forum A » Forum-Thread

so sollte die Navigation im Forum diese Form haben

[Forums] [Forum A] [Forum-Thread]

Dazu müssen zwei Dateien des "Advanced Forum"-Moduls angepasst werden:

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.

Wer mit PHPlist nicht nur reine Text-Mails, sondern auch solche im HTML-Format versenden möchte, wird gerne auf den mitgelieferten FCKEditor zurückgreifen wollen. Leider funktionert dies auch in der aktuellen Version von PHPlist v2.10.12 mit dem darin enthaltenen FCKEditor Version 2.6.3 Build 19836 erst, nachdem man einige Anpassungen vorgenommen hat. Welche Arbeitsschritte notwendig sind, damit man problemlos HTML-Mails versenden kann, beschreiben wir Schritt für Schritt in diesem Beitrag.

1. Zunächst entpackt man das aktuelle PHPlist-Paket in einen lokalen Ordner - üblicherweise enthält der übergeordnete Ordner den Namen der jeweils aktuellen Version, momentan phplist-2.10.12. Anschließend erstellt man online eine MySQL-Datenbank und trägt Datenbankhost, Datenbankname, -user und -passwort, die daraus resultieren, in die Zeilen 22, 25, 28 und 31 der lokalen Konfigurationsdatei, die je nach Speicherort unter dem Pfad /phplist-2.10.12/public_html/lists/config/config.php zu finden ist, ein. Nun kann man PHPlist per FTP in seinen Webspace laden. Achtung: es genügt den Unterordner /public_html/lists nebst seinen Unterverzeichnissen hochzuladen! Alle anderen Dateien und Ordner sind für den Betrieb nicht erforderlich. Jetzt ruft man die PHP-Installation auf: http://meine-domain.de/lists/admin. Dort muss man zunächst die Datenbank initialisieren. Anschließend sollte man als erstes das Standard-Passwort für den Admin "phplist" in ein sicheres Passwort ändern. Die weiteren Einstellungen, die vorzunehmen sind, werden in der Dokumentation beschrieben, deshalb wollen wir uns hier auf die ergänzenden Schritte beschränken.

Eigentlich ist PHPlist ja ein schönes Tool um E-Mails, z.B. Newsletter, auch an eine große Zahl von Empfängern zu senden. Allerdings ist die Konfiguration ein bisschen hakelig. So werden beispielsweise die Pfade nicht automatisch so gesetzt, dass in Mails eingebettete Bilder auch wirklich von der Website des Absenders geladen werden. Stattdessen stehen in der Mail nur relative Pfade der PHPlist-Installation. Hat man sich da aber erstmal durchgearbeitet ist die Benutzung recht einfach. Noch eine letzte Test-Mail, um zu sehen, ob die Mails sowohl als Nur-Text- als auch als HTML-Mails ankommen und schon steht dem Newsletter-Versand nichts mehr im Wege.

Bis dann der Hilferuf des Kunden kommt: "... ziemlich verzweifelt, weil das phplist keinerlei html emails verschickt ...". Ein Blick in den vom Kunden erstellten Newsletter zeigte nichts Ungewöhnliches. Alle Einstellungen waren korrekt, das Format stand auf HTML und bei den Testempfängern war HTML als bevorzugtes Format eingestellt. Aber tatsächlich fehlte bei den ausgehenden Mails der komplette HTML-Teil. Das Event-Log zeigt keine Auffälligkeiten - alles schien korrekt verlaufen zu sein. Ein rasch erstellter Test-HTML-Entwurf ging dagegen problemlos und im richtigen Format raus.

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.