Blog

Oftmals hört man von den Drupal Gegnern, dass Drupal einfach nicht genügend gute Themes hat. Das mag durchaus sein (leider). Soeben habe ich ein ein Post auf Smashing Magazin gelesen – 100 Excellent Free WordPress Themes. Ich muss sagen, wenn man die so sieht, dann kann man schon ein wenig neidisch werden. Auf der anderen Seite ist es auch eine Motivation für:

• Eine gute Liste mit Themes zu machen, denn es gibt sie auch, z.B. alldrupalthemes (die sehen eigentlich wirklich hübsch aus). Und ja, es gibt Listen, aber diese sind meiner Meinung zu klein, bzw. haben zuviel Müll drin.
• Ein paar Themes zu portieren. Eigentlich ist es ja wirklich nicht so eine Sache. Warum nicht einfach ein paar Joomla oder WordPress Themes nehmen und diese portieren?

Und wieder gibt es zwei Projekte mehr, an welchen ich gerne Arbeiten möchte, und wofür ich keine Zeit habe.

Update: Ok, ich habe doch mal einen ersten Schritt gemacht und ein Theme portiert und gleich eine Galerie erstellt.

Erst vor kurzem habe ich das Feed für die neuen Modulen entdeckt. Ich habe nicht schlecht gestaunt: für den heutigen Tag sind 3 neue Module dazu gekommen. Wenn das jeden Tag so ist, so gibt das doch eine beachtliche Menge. Warum das ganze? Nun, die meisten Module werde ich wohl nicht brauchen, aber wenn man etwas sucht, dann hat man vielleicht schon etwas entsprechendes gehört und weiss ungefähr wonach man suchen muss.

RSS Reader

Wer noch keinen RSS Reader hat, der sollte es wirklich ernsthaft in Betracht ziehen. So viele Websites bieten RSS Feeds an. Wer will schliesslich schon jeden Tag auf allen Webseiten vorbeischauen, zum sehen, ob es etwas neues gibt? Es gibt sie ja wie Sand am Meer: Thunderbird, Google, Firefox(zugegeben nicht der beste) und wie sie noch alle heissen. Ein Muss!

Vielleicht wird das mal noch ein richtiges Post.

Links

• Feed für neue Module
• Liste aller Module nach Namen sortiert
• Liste mit RSS Reader

Debuggen ist in PHP (und besonders in Drupal) nicht ganz so einfach. Wer aus der Java Ecke kommt, weiss wie angenehm es ist, mit Eclipse Schritt für Schritt durch den Code zu gehen. Mittlerweile geht es in PHP auch (z.B. mit dem Zend Studio), aber leider klappt das mit Drupal noch nicht, bzw. nur mit einzelnen Funktionen (vielleicht weiss ich einfach noch nicht wie).

Das Modul Debug hilft ein kleines bisschen

Über die Funktion debug

debug(label,$var1) 

können entsprechende Ausgaben gemacht werden. Sieht ganz hübsch aus und wird auf jeden Fall meine eigene debugger-Funktion ersetzen.

In den letzten Tagen habe ich mir überlegt, warum ich hier eigentlich dieses Blog über Drupal betreibe. Mir sind dabei folgende Gründe in den Sinn gekommen:

• Persönliches Wissensmanagement: Ich schaue immer mal wieder in meinem Blog nach, wie ich ein bestimmtes Problem gelöst habe. Da ich es selber geschrieben habe und selber mit Tags versehen habe, kann ich es relativ schnell finden.
• Werbung für meine kleine Firma, Schär Webdesign.
• Ein bisschen etwas an die Community zurückgeben.

Besonders Punkt eins ist für mich doch wichtig. So habe ich mir überlegt, dass eine noch bessere Informationsarchitektur vorhanden sein sollte. Leider habe ich bis anher noch nicht das passende Modul gefunden, bzw. weiss nicht, ob dieses überhaupt vorhanden ist. Das neue Modul sollte eigentlich das Modul "Similar Entries" durch manuelle Selektion unterstützen.

Ich stelle mir das wie folgt vor: Beim erstellen eines Blogeintrags gibt es ein Dropdownfeld, welches multiple Selection zulässt (oder ein auf AHAH-Forms basierendes Widget). Das neue Feld müsste irgendwie "Siehe auch" heissen. Es können somit alle verwandten oder weiterführenden Artikel selektiert werden.

Ein typisches Szenario wäre für mich ein mehrteiliger Artikel. Mit dem Modul Similar Entries hat man schlussendlich keine Garantie, dass ein ähnlicher Node auch gelistet wird, zudem ich die Anzahl auf 6 begrenzt habe. Im neuen "Siehe auch" Modul können jedoch direkt verwandte Nodes manuell selektiert werden.

Das Ganze könnte dann noch mit entsprechend angenehmen Suchmechanismen ausgeschmückt werden, so dass die entsprechenden "Siehe auch"-Nodes leicht und bequem gefunden werden können. Im Weiteren müsste ein Häckchen vorhanden sein, welche "Bidirektional" oder ähnlich heissen müsste. Ist dieses selektiert, so wird der Link auch vom Zielnode angezeigt.

Schon ein entsprechendes Modul gesehen? Weitere Ideen?

Die Diskussion bezüglich einer Fotogalerie mit Drupal scheint wirklich sehr aktuell zu sein. Der Counter von rapsli.ch zeigt an, dass täglich Besucher auf der Seite landen, welche nach drupal und Fotogalerie googeln. Wie ich den Gedanken ein wenig gewälzt habe, habe ich eine weitere Idee gehabt, wie man die Fotogalerien in Drupal leichter pflegbar machen könnte.

Mich persönlich stört es am Meisten, dass ich alle Fotos von Hand einzeln hochladen muss. Dies kann doch eher störend werden. Daher sollte man ein entsprechendes Batchsystem machen. Ich sehe das wie folgt:

1. Benuzter lädt Fotos via FTP in ein Verzeichnis hoch, z.B. files/galerie/galerie1
2. Cronjob oder Manuell durchsucht den ganzen Ordner (inkl. Unterordner) nach Fotos
3. Findet er ein Foto, so wird daraus ein neuer Node mit erzeugt. Titel wäre der Name des Fotos (oder Folder + Name). Falls der Node schon vorhanden ist, so passiert nicht.
4. Als Title Tag wird auch der Titel übernommen.

Dies würde meiner Meinung nach die Arbeit massiv erleichtern. Wird ein Foto auf dem FTP Server gelöscht, so wird der entsprechende Node beim nächsten Cronjob auch gelöscht. Was für Vorteile hätte ein solches System?

• Grosse Anzahl von Fotos kann leicht hochgeladen werden
• Erleichtert die Wartung einer Galerie

Nachteile

• Titel werden nicht sehr hübsch, da diese ja meistens irgendwie wie DSC_0003.jpg oder so ähnlich aussehen. Aber falls dies stört, dann könnte man den Titel immer noch von Hand bei jedem Node ändern gehen.

Leider habe ich im Moment gerade nicht so viel Zeit. Aber dies wäre auf jeden Fall ein guter Ansatzpunkt um Galerien für Drupal besser Wartbar zu machen. Vielleicht gibt es bereits ein entsprechendes Modul, dann würde sich die ganze Arbeit auch ergeben. Falls jemand also etwas kennt, so soll er doch bitte einen entsprechenden Kommentar posten. Wäre sehr freundlich.

Und falls jemand Lust und Zeit hat, ein entsprechendes Modul zu bauen… Feel free.

Das Thema Fotogalerie mit Drupal scheint doch einige Leute zu interessieren, weshalb ich hier das Thema von verschiedenen Blickwinkeln beleuchten will. Im Moment läuft zudem gerade eine angeregte Diskussion auf Drupalcenter, welche sich mit dem Thema beschäftigt.

Grundsätzlich taucht imer wieder die Frage auf, ob Drupal als Fotogalerie geeignet ist, oder doch lieber ein externes Skript genommen werden soll. Zum Beispiel gibt es das Modul Gallery, welches das einbinden von Gallery2 ermöglicht. Wahrscheinlich gibt es noch diverse andere sog. Bridges. Zudem bleibt natürlich auch immer noch die Frage auf, ob man seine Bilder nicht auf Flickr verwalten will. Was also?

Grundsätzlich sollte man sich zuerst folgende Fragen überlegen? Wieviele Fotos will ich verwalten? – 10, 100 oder 1000. Wie wichtig ist mir das aussehen? Muss es nahtlos in das bestehende Design reinpassen? Wie gut sind meine Theming/PHP Fähigkeiten? Diese paar Fragen helfen doch schon ein bisschen weiter:

1. Anzahl der Fotos. Drupal eignet sich super, um eine kleine Anzahl an Fotos zu verwalten. Je grösser die Anzahl jedoch wird, desto umständlicher wird es jedoch. Das mag eine persönliche Meinung sein, aber um tausende von Fotos zu verwalten, setze ich doch lieber auf externe Dienstleister, welche darauf spezialisiert sind und wo ich nach Möglichkeit auch gerade noch eine Desktopanbindung habe.
2. Sollte das Design nahtlos in Drupal überfliessen ist es natürlich einfacher, die Galerie auch mit Drupal zu gestalten, denn es gibt dann keine grossen Schwierigkeiten. Bei Fremdanbietern von Galerien ist es dann immer so eine Sache, die Details genau so hinzubekommen, wie man es gerne hätte. Zudem ist es ein fremdes System, in das man sich zuerst einarbeiten muss.
3. Eine Eigenentwicklung ist natürlich auf der anderen Seite auch immer mit entsprechenden personalisierten Änderungen verbunden. Der Teufel steckt oft im Detail und kann doch sehr Zeitaufwändig sein, bis man es so hinbekommt, wie man es gerne haben will. Daher sollte man sich ernsthaft fragen, wie gut die eigenen Skills sind. Kann ich meine eigenen Wünsche realisieren oder greife ich lieber auf eine Fertigversion zurück.

Eine weitere Frage, welche auch auftaucht ist die Flexibilität einer Drupallösung. Die Drupalgalerie basiert auf dem Node prinzip. D.h., jedes Bild wird als Node abgespeichert und wird dann mittels Views/Taxonomie entsprechend Kategorisiert und in Alben dargestellt. Es ist also relativ flexibel. Die Integration von Thickbox (oder Lightbox) macht zudem einen sehr hübschen Eindruck. So ist es eigentlich auch für eine relativ grosse Anzahl von Fotos gut geeignet (solange es darum geht die Fotos zu präsentieren und nicht zu verwalten, was ja immer öfters online gemacht wird). Zudem ist es nicht möglich Fotos online zu bearbeiten (zu beschneiden, umzudrehen usw.).

Will man Zusatzfeatures wie Kommentare usw. so funktioniert das Grundsätzlich gut, braucht jedoch noch einiges an Handarbeit. Zudem ist doch ein grosser Nachteil einer Drupallösung das Hochladen der Fotos. Dies muss alles in mühsamer Handarbeit (node für node) gemacht werden. Hier wäre es vielleicht man an der Zeit, etwas zu bauen.

Wie bei den meisten Fragen gibt es auch hier keine Universallösung. Es geht schlussendlich um den eigenen Geschmack und die eigenen Vorlieben.

Ein paar Galerie Module für Drupal:

• jCarousel -> weniger eine Galerie als ein Showcase. Sieht aber hübsch aus.
• Gallerix. Umfassende Galerie. Hat aber nicht diesen hübschen Thickboxeffekt 🙁
• Brilliant. Sieht noch ganz cool aus. Ist ganz anders. Basiert auf Lightbox.
• Flash_galerie. Sieht recht gut aus, aber ist halt nich auf dem Nodesystem basierend.
• Handbuch zum Gallery Modul.
• YAGM – Yet another Gallery Module.
• Imagefield Gallery. Nicht getestet.
• Gallery Addon Nicht getestet, klingt aber sehr interessant!

Und dann gibt es halt noch die Version CCK & Views.

Update 4.3.2008 – Eine Sammlung von Beispielen. Gibt vielleicht ein wenig Inspiration, was wie gemacht werden kann.

Wer sich mit der Entwicklung von eigenen Module beschäftigen will, wird nicht um die Drupal API herum kommen. In der Drupal API finden sich alle Funktionen, welche von Drupal bereitgestellt werden. Alternativ lässt sich das Modul auch auf dem eigenen lokalen Server installieren. Dies hat den Vorteil, dass dadurch auch eigene Funktionen ersichtlich sind.

Ok, wie funktioniert das ganze nun. Auf der Einstiegsseite ist zuerst einmal ganz wichtig, dass die richtige Version selektiert wird, da es zwischen den einzelnen Versionen doch ein paar Unterschiede gibt. Hat man eine Version selektiert (z.B. die Version 5), so erscheinen in der Mitte 3 Hauptkategorien und ganz wichtig, auf der linken Seite das Suchfeld.

"Components of Drupal" richtet sich eher an Anfänger, und Leute, welche sich zum ersten Mal mit der Modul entwicklung befassen. Das ganze wird dann noch abgerundet mit ein paar Beispielen. Ich persönlich brauche eigentlich sehr oft die "In-depth discussion" und hier besonders die Forms API reference. Diese gibt einen super überblick über die Forms API: Was für Attribute gehören zu einem Forms Element usw. … -> Sehr nützlich.

Ein weiterer nützlicher Teil ist die Suche. Z.B. drupal_add_js(). Die Autocompletion gibt dem Suchenden schon sehr bald eine kleine Übersicht über vorhandene Funktionen. So lässt sich auch bequem nach Funktionen suchen, auch wenn man nicht genau weiss, wie diese heisst. drupal_add_js() gibt eine Seite zurück. Dort werden zuerst die Argumente beschrieben, danach kommt je nach dem eine kleine Anleitung, eine Hilfe und dann wird die Funktion aufgelistet.

Einsicht in die genaue Funktion kann manchmal sehr hilfreich sein. Unter Umständen können hier auch Ideen für die eigenen Module gefunden werden und wie man ein gewisses Problem lösen kann.

Für den Google Analytics Counter gibt es ein eigenes Modul, es lässt sich aber auch ganz einfach in einen eigenen Block einbinden:

admin/build/block -> "Block hinzufügen". Dann im Feld Block Inhalt den Code vom Counter reinkopieren. Damit es auch klappt muss das Eingabeformat auf Full HTML gesetzt werden.

Damit fängt der Counter schon mal an zu zählen. Was jedoch jetzt das Problem ist: Jedes Mal, wenn man sich als Administrator auf der Seite bewegt, wird man gezählt. Dazu gibt es eigentlich 2 Möglichkeiten:

1. Man setzt einen Filter im Analytics Counter
2. Man lässt den Block nur für nicht Admins anzeigen

Die erste Methode ist eigentlich sehr sauber, nur leider funktioniert das bei den meisten DSL Anschlüssen nicht. Hier ändert sich immer Mal die IP. Das heisst man müsste den Filter im Google Analytics immer mal ändern gehen -> unbefriedigend.

Es kommt also nur die zweite Möglichkeit in Frage. Drupal hat hier bereits vorgesort: "Diesen Block nur auf den aufgelisteten Seiten anzeigen". Und dann hier auf den Experten Modus (PHP Modus) schalten:

uid == 1){
return false;
}
return true;
?>

Dabei das Ganze noch mit <?php und ?> umschliessen. Dieser kleine Schnippsel sendet false zurück, falls der Administrator unterwegs ist -> Der Block mit dem Analytics Counter wird nicht angezeigt. Im Normalfall wird true zurück geschickt, worauf der Block angezeigt wird, falls jedoch der Administrator sich einloggt, so wird der Block nicht angezeigt, worauf auch kein Hit im Counter gemacht wird.

Das Script könnte natürlich auch auf andere User ausgeweitet werden.

Da das Blog langsam wächst, habe ich mir überlegt, wie ich die Informationsarchitektur verbessern kann. So gibt es jetzt 3 Navigationselemente:

Tag Cloud

Diese ist mittlerweile bekannt und wird so auch auf vielen Seiten eingesetzt. Sie gibt eine gute Übersicht über vorhandene Tags und Inhalte, welche sich eventuell darunter verbergen könnten. Das Problem ist allerdings, dass nicht immer klar ist, welche Tags den persönlichen Geschmack treffen -> Was verstehe ich unter dem Tag "review" und was versteht der Besucher darunter. Ist nicht klar.

Beliebte Inhalte

Ein Block, welcher mit dem Statistikmodul kommt. Dieser hat jedoch das Problem, dass beliebte Inhalte noch beliebter werden und weniger beliebte noch weniger beliebt. Denn ein Beitrag welcher für den Benutzer X gut ist, muss nicht unbedingt auch für Benutzer Y gut sein.

similar entries

Dieses Modul soll in die Lücke springen. Es funktioniert wie folgt: Wird ein Node angeschaut, so wird in der Datenbank nach ähnlichen Nodes gesucht. Dabei wird die Taxonomy und der Titel berücksichtigt. Die ähnlichen Beiträge werden dann dem Besucher präsentiert.
Amazon hat ein ähnliches Konzept: "Besucher, welche dieses Buch gekauft haben, habe auch noch Buch X, Y und Z gekauft".
An dieser Stelle sei noch gewarnt: Das Modul muss etwas an einer Core Tabelle verändern. Hat jedoch bei mir nichts kaputt gemacht.

Das Phänomen, welches dahinter steckt ist der sog. Long Tail, worüber ich bekanntlich auch meine Bachelorarbeit geschrieben habe. Kurz: Es gibt wenige Hits (welche von vielen Leuten konsumiert werden) und es gibt einen langen Schwanz (Tail), welcher mit Inhalten gefüllt ist, welche nur wenig Leute interessieren. Die Summe der Inhalte des Schwanzes wird jedoch beachtlich gross. Dieses Phänomen wird wohl jedem bewusst oder unbewusst bekannt sein (YouTube, Google, ITunes usw.).

Es geht also darum, entsprechende Wege zu finden, um den Long Tail für den Benutzer transparenter zu gestalten. Similar entries und Tag Clouds sind eine Möglichkeit.

Das Grundgerüst von Drupal basiert auf Nodes. Jeder Inhalt ist ein Node. Dieser Node hat standardmässig verschiedene Eigenschaften (z.B. Title, body, published usw.). Mit CCK lassen sich diese Eigenschaften beliebig erweitern. Es könnnen neue Felder hinzugefügt werden wodurch ein eigener Node gebaut werden kann.

Daher kommt schnell einmal der Wunsch auf, dass diese Inhalte anders dargestellt werden sollen. Das Theming System von Drupal ist hier sehr flexibel:

1. Im Theme gibt es die Datei node.tpl.php. Diese enthält alle Informationen, wie der Inhalt eines Nodes angezeigt werden soll und bezieht sich auf jeden Node.
2. Diesen ganz einfach kopieren und wie folgt umbenennen: node-myType.tpl.php (wobei "myType" eben der Namen des neuen Inhalttypes ist).
3. Die Datei kann jetzt entsprechend angepasst und umgeändert werden.

Ein paar nützliche Funktionen dazu könnten sein:

• drupal_add_css()
• drupal_add_js()
• drupal_set_title()

Diese ermöglichen es CSS und js Dateien nur für diesen Nodetype einzubinden. Die Funktion drupal_set_title() setzt den Titel der Seite -> wäre auch die Möglichkeit, so den Titel auszublenden.

Natürlich ist CCK nicht notwendig dafür. Es reicht bereits node-blog.tpl.php um alle Blogseiten spezielle zu themen (oder: node-book.tpl.php, node-forum.tpl.php…).

Ausführliche Informationen zu node.tpl.php sind im Handbuch auf Drupal.org zu finden. Dort werden auch zur Verfügung stehende Variablen aufgelistet und zudem gezeigt, wie es auch möglich ist, einen einzelnen Node separat zu themen.