Making of progblog.de

Das Folgende ist ein länglicher Beitrag, den ich ursprünglich für den "Showroom" auf drupalcenter.de erstellt habe und der außer Drupal-Benutzern nicht allzu viele interessieren dürfte - Leser, die keine Drupal-Geeks sind, können ihn also gefahrlos ignorieren.

"The Making of progblog.de"

Bevor ich das Blog auf Drupal migrierte, wurde progblog.de mit Serendipity a.k.a. s9y betrieben, einem sehr guten, einfach zu installierenden und betreibenden Blog-System, das diesen Dienst fast vier Jahre lang tadellos verrichtet hat. Da ich aber in den letzten Monaten zum Drupal-Fan geworden bin, wollte ich aus Spaß-an-der-Freude das Blog umstellen und gleichzeitig "pimpen", auch um die vielfältigen Möglichkeiten auszutesten und vorzuführen, die Drupal bietet.

Dafür, dass es sich eigentlich "nur" um ein persönliches Blog handelt, benutzt progblog.de deshalb eine fast obszöne, auf jeden Fall unvernünftig hohe Anzahl an Nicht-Core-Modulen: 79, um ganz genau zu sein (wobei in dieser Zahl Submodule aus Modul-Packages mitgezählt sind), was für die Performance der Seite nicht unbedingt förderlich ist. Da es aber keine registrierten Benutzer gibt und die Inhalte sich nicht mehrfach am Tag ändern, fängt das natürlich aktivierte Drupal-Caching dieses mögliche Problem zum größten Teil ab. Wegen der vielfältigen benutzten Module handelt es sich auch um eine Drupal-5-Website, da etliche der verwendeten Module damals und auch immer noch nicht in Drupal-6-Versionen zur Verfügung standen bzw. stehen.

Weiter unten werde ich den Großteil der benutzten Module auflisten, gruppiert nach Funktion. Zu den Modulen, die ich explizit erwähnen werde, kommen noch ein paar weitere, auf die andere Module angewiesen sind, wie z.B. das token-Modul, das von audio und pathauto benötigt wird, oder auch jquery_update, das für einige der JavaScript-Spielereien gebraucht wird. Von den meisten Modulen sind jeweils die aktuellsten Dev-Versionen installiert. "Stable"-Versionen laufen eigentlich nur, wenn es keine auf der Projekt-Seite verlinkte Dev-Version gibt oder wenn ich mit der Dev-Version wirklich Probleme hatte, was aber die Ausnahme ist.

Das Theme ist ein Zen-Subtheme, das überwiegend via CSS gestylt wird und nur einige wenige Änderungen in den verschiedenen .tpl-Dateien und der template.php enthält. Es gibt fünf Content types, die aber alle die gleiche node.tpl.php benutzen, und nur für einen wird ein ConTemplate-Template benutzt.

Für die Migration der alten Daten (immerhin mehr als tausend Blog-Einträge sowie ein paar hundert Kommentare) aus der s9y-Installation habe ich ein kleines Custom-Modul geschrieben, das die Beiträge, Kommentare und Kategorie-Zuordnung aus der s9y-Datenbank ausgelesen und als Drupal-Nodes/-Comments mit zugehöriger Taxonomy-Information in die Drupal-Datenbank geschrieben hat. Über ein weiteres Skript habe ich anschließend die internen Links vom s9y-typischen Format in korrekte neue drupalinterne Links umgeschrieben. Dies läuft aber über den Umweg eines kleinen Custom Moduls, das ich bereits für eine andere Website geschrieben hatte: Einen Drupal-Filter, der im Prinzip nur einen Wrapper für Drupals l()-Funktion darstellt. Den Filter benutze ich statt direkter <a>s, da durch den Weg über die l()-Funktion die Links auch dann korrekt bleiben, wenn sich der Autopfad des Ziel-Nodes ändert.

Modulgruppen:

Inhalts-Aufbau und -Präsentation:

Unvermeidlich sind dafür natürlich CCK und Views. Views werden benutzt, um fast alle Archiv-Listen sowie etliche Blöcke auf der Seite zu generieren. CCK kommt bei zwei Inhaltstypen zum Einsatz, speziell die Image Field-Feldart, die Link-Feldart und in einem Content Type auch ein Text-Feld.

Für die Hörbespiele meiner Band wird das Audio-Modul benutzt. Die Bildergalerien sind ein CCK-Typ mit einem Mupliple-Values-Imagefield, woraus mit ImageCache und dem Imagefield Gallery-Modul automatisch eine Lightbox-Galerie erzeugt wird.

Das kleine, aber feine External Links-Modul sorgt schließlich via JQuery dafür, dass Links zu externen URLs auch als solche gekennzeichnet werden.

Kommentare:

Dass ich das Kommentar-Feld auch ohne Angst von Spam-Müll für anonyme Benutzer offen lassen kann, dafür sorgt Dries Buytaerts Mollom-Service und -Modul, das bisher tadellos funktioniert. Trotzdem möchte ich es gerne mitbekommen, wenn es zu einem Beitrag neue Kommentare gibt. Das erledigt Notify mit E-Mail-Benachrichtigungen. Damit meine (wenigen...) Stammleser ihre Daten bei wiederholtem Kommentieren nicht erneut eingeben müssen, ist auch Comment Info installiert.

Navigationshilfen:

Um dem Benutzer verschiedene Möglichkeiten anzubieten, sich durch's ProgBlog zu hangeln, laufen einige nicht überlebensnotwendige, aber doch nützliche Module:

Für den "Archiv"-Block mit Auflistung der Monate sorgt der Archive View, der Teil des Views Bonus Packs ist.

Da die Kategorie-Struktur der Einträge über Taxonomy geregelt wird, erzeugt Taxonomy Breadcrumb eine passende Krümelspur. Ein weiteres Taxonomie-Vokabular ist für Freetagging vorhanden, woraus Tagadelic eine Tag-Cloud generiert.

Der Backlinks-Views-Filter erzeugt einen Block, der zu jedem Node diejenigen anderen Nodes auflistet, in denen zum aktuellen Node gelinkt wird; das ergibt im Effekt etwas wie "interne Trackbacks". Ergänzend dazu gibt es einen Block, der vom "Related Links"-Modul erzeugt wird und anhand von Content Type und Taxonomy Term Links zu vermutlich "ähnlichen" bzw. "verwandten" Nodes anzeigt.

SEO / Suchmaschinen-Optimierung:

Damit Google und Co. progblog.de auch lieb haben, sind einige Module zur Search Engine Optimization installiert.

XML Sitemap erzeugt eine sitemaps.org-konforme Sitemap, die via Cron an verschiedene Suchmaschinen-APIs übermittelt wird, wenn neue Inhalte eingepflegt wurden. Das Modul Meta Tags erzeugt automatisch Meta-Descriptions und -Keywords aus den Node Teasers und Taxonomy Termen.

Das unvermeidliche Pathauto-Modul (natürlich nur mit eingeschalteten Clean URLs) erzeugt lesbare, suchmaschinenfreundliche Pfade, und Global Redirect sorgt dafür, dass alle Seiten unter genau diesem einen Pfad erreicht werden (zusammen mit der in Drupals .htaccess beschriebenen mod_rewrite-Direktive, die alle Zugriffe auf progblog.de zum entsprechenden Pfad mit der Domain www.progblog.de weiterleitet).

Damit Google auch die neuen URLs der Blog-Einträge verkraftet, ohne den Page Rank abstürzen zu lassen (und obendrein Links zu speziellen ProgBlog-Einträgen auf externen Websites gültig bleiben, um also Link rot weitestgehend zu vermeiden), habe ich außerdem ein kleines Custom Modul geschrieben, dass sich in hook_init() einklinkt, checkt, ob die Request-URI ein "alter" Pfad ist, falls ja den richtigen neuen Pfad sucht und dorthin via drupal_goto() einen 301-Redirect macht.

Editing-Erleichterungen:

Mein HTML ist zwar OK, aber man muss sich das Leben ja nicht schwerer machen, als unbedingt nötig :-). Deshalb benutze ich auch einige Hilfsmodule für die Erstellung und das Bearbeiten von Beiträgen, sowie einige weitere Module, die generell das Drupal-Leben etwas angenehmer machen.

TinyMCE kommt als Rich-Text-Editor zum Einsatz; nicht, weil ich TinyMCE jetzt im Vergleich zu anderen RTE-Alternativen den besten finde, sondern weil dafür einige weitere Drupal-Module praktische Plugins zur Verfügung stellen. Wie z.B. das Asset-Modul, mit dem ich Medien-Dateien, natürlich vor allem Bilder, in den Node-Text halbwegs bequem einbinden kann. Damit solche via Asset eingebundenen Bilder auch automatisch via Lightbox verlinkt werden, habe ich einen kleinen custom formatter für Asset geschrieben, der Imagecache-Varianten von Inline Asset Images via Lightbox V2 mit ihrem Original verknüpft. HTML Corrector stellt sicher, dass auch bei komplexeren Einträgen der von Drupal automatisch erzeugte Teaser-Text keine inkorrekten Tag-Schachtelungen enthält.

Damit ich ohne umschalten zu müssen ungefiltertes HTML in meinen Postings benutzen kann, bei Kommentaren aber standardmäßig das "Filtered HTML"-Format eingestellt bleibt, ist auch Filter Default installiert. Damit ich Änderungen an meinen Beiträgen auch im Nachhinein (man wird nicht jünger) nachvollziehen kann, zeigt Diff mir die Unterschiede von Revision zu Revision an. Suggested Terms bietet mir beim Anlegen/Bearbeiten die meistbenutzten Tags zum Anklicken an und erspart dadurch oft ein wenig Tipperei (Faulheit ist eine Tugend ;-)).

Dafür, dass ich Einträge auch in einem Entwurfsstatus abspeichern sowie zeitgesteuert veröffentlichen kann, sorgen Workflow und Actions. In Workflow habe ich zwei "states" namens "Entwurf" und "Veröffentlicht" definiert. Beim (evtl. zeitgesteuerten, also via Cron ausgelösten) Übergang von "Entwurf" zu "Veröffentlicht" wird eine "Publish node"-Action abgefeuert, beim umgekehrten Übergang eine "Unpublish node". Außerdem habe ich einen View definiert, der alle Beiträge mit dem Status "Entwurf" auflistet.

Schließlich erleichtert das sehr schmucke und komfortable Modul Super Nav die Navigation durch Drupals viele, viele Admin-Bereiche.

Suche:

Für die Suche benutze ich das exzellente "Faceted Search"-Modul, das auf Drupals mitgelieferte Suchfunktionalität aufsetzt, es aber ermöglich, eine Stichwort-Suche durch sukzessive Anwendung weiterer Kriterien (die "Facets", "Facetten") systematisch einzuschränken, etwa durch Einschränkung nach Taxonomy-Terms, Erstellungsdatum oder Content Type der Ergebnis-Nodes.

Spielereien:

Zum Abschluß ein paar Funktionalitäten, bei denen eher das Spielkind in mir durchgegangen ist (das "Kid in a candy store"-Syndrom...), als dass sie wirklich kriegsentscheidend wären.

Das ehrfurchtgebietend großartige "Panels 2"-Modul, zusammen mit dem Tabs Panel Style, wird eingesetzt, um die Startseite aufzupeppen und über mehrere "Mini panel"-Blocks auch auf den Inhaltsseiten Platz zu sparen. Ein Klick auf eines der angezeigten "Tabs" tauscht dynamisch den Inhalt im Bereich darunter aus: Auf der Startseite werden die fünf aktuellsten Beiträge durch verschiedene Listen mit weiteren Beiträgen ersetzt, in der rechten Navigationsleiste kann man auf Inhaltsseiten so zwischen der Tag Cloud und dem "Neue Kommentare"-Block umschalten oder unter den Beiträgen in einem Block zwischen Listen der neuesten Beiträge in drei verschiedenen Inhaltstypen (Blog-Einträge, Bilder-Galerien und Audio) wechseln.

Ebenfalls auf der Startseite kommt Views Slideshow zum Einsatz, ein View-Typ, der die einzelnen Elemente eines Views nacheinander automatisch aus- bzw. einblendet, in diesem Fall über einen List View Photos aus meinen Bildergalerien, die zur entsprechenden Galerie-Seite linken.

Eine letzte Spielerei ist das JavaScript-Karusell ganz unten, in dem man sich durch Screenshots von und Links zu weiteren meiner Websites scrollen kann. Dies ermöglicht das Modul Node Carousel, das auf eine Node Queue zugreift, die festlegt, welche Nodes im Karussel in welcher Reihenfolge anzeigt werden.

Abschließend:

Drupal rockt :-)

An alle Core- und Modul-Entwickler, aber auch an alle Dokumentationsschreiber und alle, die in den verschiedenen Foren und Blogs Tipps und Trick weitergeben oder nur Fragen beantworten: Danke!