Drupal Coding Standards – Warum sich Einhalten lohnt

Klint irgendwie ein wenig wie die Games Conventions ;) … Ich muss ehrlich gestehen, dass ich mich bis vor einigen Tagen noch nicht wirklich darum gekümmert habe. Coding Conventions gingen mir am A**** vorbei, weil ich bereits meine eigenen hatte. Bisher ist das auch ziemlich gut gegangen, bis vor einigen Tagen.

In der Issue Queue meines Exif Moduls, gab es einige Patches, welche schon seit geraumer Zeit aufs Committen warteten. Vor zwei Wochen habe ich damit angefangen. 1. Patch ging bestens. Der zweite Patch ging dann nicht mehr so gut, weil ja der Code verändert wurde, sprich dieser Patch musste neu erstellt werden, bzw. manuell eingepflegt werden. Meinem Aufruf in der Issue Queue, ob denn jemand den Patch neu erstellen würde, wurde sogleich auch folge geleistet, allerdings unter der Bedingung, die Drupal Coding Conventions zuerst hergestellt würden. So habe ich das mal gemacht.

Also, warum lohnt es sich?

Ich finde folgende Gründe:

  • Einheitlich, alle machen es gleich -> einfacher und übersichtlicher, wenn man ein fremdes Modul weiterpflegen will.
  • Patches erstellen. In vielen Editoren (z.B. auch Eclipse) hat man die Möglichkeit zum Autoformatieren. In meinem Eclipse hatte ich immer zum Einrücken Tabs verwendet (was nicht dem Drupal Standard entspricht). Wenn jetzt jedoch jemand kommt, den Code verändert/erweitert, seinen Autoformatter laufen lässt (welcher Leerschläge zum Einrücken verwendet) und dann einen Patch daraus macht, dann wird dieser Patch recht gigantisch aussehen, da ja die ganzen Leerzeichen auch veärndert wurde.
  • Gibt es noch mehr?

Die wichtigsten Coding Conventions:

<?php function meine_funktion($var) { //Abstand vor geschweifter Klammer if (1 == 1) { //Abstand nach if und vor geschweifter Klammer $text = $var .’ hallo welt’; //Abstand zwischen Variable und Punkt, kein Abstand zwischen .’ } $ar = array(1, 2, 4); //Abstand nach Kommas } ?>

Eclipse einstellen

Es ist eigentlich sehr einfach: Window > Preferences. Dann dort: General > Editors > Text Editors Display tab width: 2 Insert spaces for tabs: True Wer PDT installiert hat, kann es auch nur für PHP Files machen: Window > Preferences, Dann dort: PHP > Code Style > Formatter

Links

Foto Galerie mit Drupal – Teil 2

Pause war leider ein wenig länger als geplant… lag daran, dass der vorbereitete Blogeintrag plötzlich irgendwie verschwunden war. Jetzt geht es aber weiter. Im Teil eins haben wir mittels CCK die Bildererfassung gemacht. Dieser Teil ist für den Besucher der Galerie eigentlich noch nicht relevant. Im zweiten Teil werden wir die Galerie entsprechend darstellen. Dazu brauchen wir die folgenden Module:

  • Views
  • Lightbox

Nachdem die Module installiert sind, fügen wir zuerst einmal eine neue Ansicht (views) hinzu.

Wir geben der Views einen entsprechenden Namen “galerie” und eine kleine Beschreibung. Besonders, wenn man viele Views hat, kann diese noch recht nützlich sein. Zusätzlich können wir die Views taggen -> ist wiederum nützlich, wenn man viele Views hat.

Jetzt kommen wir auf den Views Builder. Views ist eigentlich lediglich ein Tool, um SQL Abfragen zu bauen, sozusagen SQL für Jedermann (und Frau). Es gibt diverse Bereiche und Einstellungsmöglichkeiten. Für uns relevant ist lediglich “Fields” und “Filter”. In Fields können wir angeben, welche Felder des Nodes dargestellt werden sollen. Diese Felder haben wir ja vorher mittels CCK angelegt. Beim Filter geben wir an, welche Nodes rausgefiltert werden.

Wir fügen also ein Feld zum Anzeigen hinzu -> logischerweise wollen wir ja das Bild anzeigen. Wir wählen also field_bild aus. Beim Weiterklicken haben wir noch ein paar Konfigurationsmöglichkeiten, nämlich wie das Bild dargestellt werden soll.

Da wir ja Lightbox aktiviert haben, gibt es noch ein paar zusätzliche Möglichkeiten. Wir wählen also hier einfach die entsprechende Option aus -> alles hier kann auch wieder geändert werden.

Jetzt müssen wir noch einen Filter angeben, da wir ja nur die Nodes anzeigen wollen, welche auch ein Bild enthalten.

So, jetzt haben wir unsere Standardabfrage gebaut. Die ist wie gesagt nur Standard. Jetzt müssen wir noch definieren, wie die Views angezeigt werden soll, als Seite, als Block oder gar in einem Panels. Wir klicken also auf “add Display”.

Jetzt hat aber unsere Seite noch keinen Pfad. Wir definieren also noch einen Pfad unter welcher unsere Galerie erreichbar sein soll.

Und zuletzt, aber am Wichtigsten: Das ganze Speichern. Es kommt immer wieder vor, dass dieser Schritt vergessen wird. Ist einfach ein wenig eine gewohnheitssache. Aber vom Office sollte man das ja eigentlich kennen, dass man fleissig speichern sollte.

Jetzt haben wir eigentlich bereits eine hübsche Galerie. Die Anforderung war jedoch, dass sie nach Datum gruppiert werden soll. Kein Problem. Dafür fügen wir noch ein weiteres Feld hinzu, nämlich das Post Date (Beitragsdatum). Wir wollen das Feld jedoch nicht anzeigen, daher setzen wir die Checkbox “Exclude from display” und geben aber trotzdem das Format an, wie es dargestellt werden sollte.

Fast geschafft. Noch ein letzter Schritt. Beim Style klicken wir auf das kleine Zahnrad für die Einstellungen und geben an, dass wir unsere Nodes nach dem Post date gruppieren wollen. That’s it.

Jetzt haben wir eigentlich eine ziemlich hübsche Galerie. Sie sieht zwar in Garland noch nicht ganz so elegant aus, aber das lässt sich eigentlich relativ einfach mit ein wenig CSS nachbessern und aufhübschen.

Advanced Theming in Drupal

Drupal ist ja bekanntlich sehr flexibel. Die Flexibilität hat jedoch auch ihren Preis. Will man fortgeschrittene Theme Arbeiten machen, wird man nicht um PHP kommen. Wenigstens die Fähigkeit PHP zu lesen ist ein Muss. Wie funktioniert das Drupal Theme System? Und wie geht man vor? In einem Drupal Modul werden Theme Funktionen meistens wie folgt aufgerufen:

theme('image','sites/default/files/myimage.jpg');

Diese Funktion hat als Rückgabewert <img src=’sites/default/files/myimage.jpg’ />. Was soll jetzt daran besser sein, als gerade direkt den img Tag zu schreiben, was unter Umständen einfacher und schneller wäre? Ganz einfach: Ich kann in meinem Template die Themefunktion theme_image überschreiben. Warum möchte ich das machen? Weil ich z.B. allen Bildern automatisch eine Klasse mitgeben möchte. Theme_image Funktion überschreiben Wenn ich nach http://api.drupal.org gehe und dort nach theme_image suche, dann bekomme ich die Funktion zurück. Die Funktion sieht wie folgt aus:

function theme_image($path, $alt = '', $title = '', $attributes = NULL, $getsize = TRUE) {
if (!$getsize || (is_file($path) && (list($width, $height, $type, $image_attributes) = @getimagesize($path)))) {
$attributes = drupal_attributes($attributes);
$url = (url($path) == $path) ? $path : (base_path() . $path);
return ''. check_plain($alt) .'';
}
}

Jedes Bild, das generiert wird, wird also über diese Funktion erstellt (sofern die Module richtig programmiert sind). Wenn ich jetzt also jedem img Tag eine spezielle Klasse hinzufügen möchte, dann könnte ich:

  1. Die Theme_image Funktion aufbohren und die Sachen gleich dort reinschreiben. HALT! Nein. Dann müsste ich das, wenn ich das nächste Mal Drupal aktualisiere wieder machen, also Finger weg.
  2. Ich überschreibe diese Theme Funktion in meinem template.php File im Theme.

Das Vorgehen für das Überschreiben ist eigentlich denkbar einfach: Einfach die Originalfunktion kopieren und in das eigene template.php einfügen und dazu die Funktion von theme_image in myTheme_image (wobei myTheme der Name des eigenen Themes ist) umbenennen und dann in dieser Funktion die entsprechenden Änderungen vornehmen:

<!–?php
function myTheme_image($path, $alt = ”, $title = ”, $attributes = NULL, $getsize = TRUE) {
if (!$getsize || (is_file($path) && (list($width, $height, $type, $image_attributes) = @getimagesize($path)))) {
$attributes['class'] .= ‘ myClass’; //hier wird die Klasse jedem Bild angefügt.
$attributes = drupal_attributes($attributes);
$url = (url($path) == $path) ? $path : (base_path() . $path);
return ‘'. check_plain($alt) .'‘;
}
}
?>

Es stellt sich dann halt einfach die Frage, welche Theme Funktionen aufgerufen werden. Dazu ist der Theme Developper extrem nützlich!! Folgende Theme Funktionen werden häufig verwendet:

  • theme_image – Bilder
  • theme_item_list – Listen
  • theme_table – Tabellen
  • theme_breadcrumb

Es gibt noch seeeeehr viel mehr solcher Funktionen.

Multisite mit Drupal aufsetzen

Was ist überhaupt eine Multisite? Dafür müssen wir kurz den Aufbau einer Drupalseite anschauen:

  1. Es gibt Code. Dazu gehört Drupal Core, die Themes, die Module und die Dateien. Diese Dateien sind für alle Drupalsites identisch.
  2. Es gibt die Datenbank. Dort sind die ganzen Informationen bezüglich Inhalt und Konfiguration drin. Diese Daten sind für jede Drupalsite unterschiedlich.

Wenn eine Seite aktualisiert wird, dann werden dazu die neuen Dateien auf den Server geladen und dann auf der Drupalsite update.php ausgeführt. Falls updates vorhanden sind, dann werden die entsprechenden Veränderungen an der Datenbank vorgenommen. Hat man also 3 Drupalsites und führt diese eigenständig, dann hat man eine grosse Redundanz, denn die Codebasis ist überall vollkommen identisch. Daher die Multisite:
Viele Drupalsites greifen auf die gleiche Codebasis zurück, haben jedoch jede eine eigene Datenbank und ein eigenes Files Verzeichnis. Dadurch ist die Wartung einfacher.

Voraussetzungen für eine Multisite
Damit eine Multisite überhaupt erst möglich ist, müssen gewisse Voraussetzungen vorhanden sein:

  • Es muss möglich sein, mehrere Domains auf das gleiche Verzeichnis zeigen zu lassen. Das heisst: www.site1.ch und www.site2.ch zeigen auf die gleichen Dateien. Das kann z.B. über VirtualHosts gelöst werden. Eine Weiterleitung reicht nicht aus! Nicht alle Hoster bieten diese Möglichkeit an. Bei Hostorama musste ich explizit nachfragen, danach hatte ich jedoch die Option :)
  • Das ist es dann eigentlich auch schon.

Multisite installieren

  1. Vor dem Installieren sind ein paar kleine Schritte notwendig:
  2. Den Ordner sites/site1.ch erstellen
  3. Den Ordner sites/site1.ch/files erstellen
  4. im Ordner sites/default gibt es ein File (default.settings.php), dieses in den Ordner sites/sites1.ch kopieren und in settings.php umbenennen.
  5. site1.ch besuchen und Drupal installieren.
  6. Auf site1.ch, unter settings > filesystem den Pfad entsprechend einstellen, so dass er nicht mehr auf default… zeigt sondern auf sites/site1.ch/files zeigt.
  7. Für die zweite Seite (und jede weitere) kann jetzt genau gleich vorgegangen werden.

Spezialitäten einer Multisite
Eine Multisite hat einige kleine Spezialitäten:

  • Module, welche unter sites/all/modules sind, sind für alle Sites sichtbar. Das heisst, hier kommen die Module hin, welche für alle Sites verwendet werden. Analog dazu sites/all/themes
  • Module und Themes aus sites/site1.ch/modules sind ausschliesslich für die site1 sichtbar
  • Beim update zu beachten!!! Auf jeder Site der Multisite MUSS update.php ausgeführt werden, ansonsten kann es unter Umständen manchmal zu kuriosen Fehlermeldungen kommen.

That’s it. Ist eigentlich also trivial, vorausgesetzt, eine Multisite ist überhaupt möglich.

Lehren aus einem Drupalprojekt

Ich bin wohl noch verhältnismässig Jung in der ganzen Projektwelt. Seit Mai 2009 bin ich jetzt bei der Previon als Drupal Software Engineer tätig. Und habe so einige Erfahrungen gesammelt, besonders im Rückblick auf das jüngste (fast abgeschlossene Projekt). Hier eine kleine Sammlung mit Erfahrungen, welche ich gemahct habe, die ich im nächsten Projekt garantiert NICHT mehr so machen werde:

  • E-mail Verkehr. Es gibt einfach schlauere Sachen, als E-mail. Change Requests per E-mail führen -> extrem schlecht!! Nachträgliche Nachvollziehbarkeit ist praktisch nicht möglich. ZWINGEND von Anfang an dem Kunden ein Tool aufzwingen, an welches er sich halten muss (irgend ein Bugtracker oder irgend sonst ein System), welches für beide Parteien einsehbar ist und welches immer klar darlegt, was noch offen ist (ist einfacher gesagt als getan in der Praxis).
  • Datenmigration: Diese ist definitiv nicht zu unterschätzen! Frühzeitig durchführen, damit der Kunde diese prüfen kann und gegebenfalls Fehler finden kann, damit das Script verbessert werden kann. Mit Drupal und seiner node_save Methode ist es relativ einfach, aber diese Migrationssachen haben halt einfach ihre Tücken.
  • Kunden zu Meilensteinen verpflichten. Vom Entwickler wird eigentlich immer erwartet, dass alles Termingerecht fertig ist, der Kunde kann ruhig mal ein paar Tage Verspätung haben -> nein! Nur wie verpflichtet man den Kunden dazu… klaro, für den Endtermin ist das einfach, aber für “kleine” Zwischenmeilensteine ist es nicht ganz so einfach. Wahrscheinlich müsste man visuell irgendwo festhalten, wann Meilensteine erreicht wurden, damit der Kunde auch sieht, wenn er einen verpasst hat und dadurch der Entwickler einen anderen Meilenstein nicht mehr einhalten kann.
  • Grosszügig schätzen. Es ist und bleibt oftmals eine sehr vage Schätzung, aber es gibt einfach Dinge, welche ein Drupalprojekt komplexer und somit aufwändiger gestalten, dazu gehören unter anderem:
    • Mehrsprachigkeit
    • Shopfunktionen
    • Multsites/Single Sign-on
  • Jeder einzelne dieser Punkte erhöht die Kosten pauschal um einen gewissen Prozentsatz, da sie einfach von Natur aus Probleme mit sich bringen: Mehrsprachigkeit: Fehlende Übersetzungen und Module, welche nicht mit der Mehrsprachigkeit zurechtkommen usw.

Würde ich wieder machen
Natürlich gibt es auch einige gute Dinge, welche ich beim nächsten Projekt wiederholen werde:

  • Sehr früh den Kunden bereits auf einen Prototypen loslassen und anhand des Prototypen weitere Funktionen entwickeln. Spekulationen im luftleeren Raum bringen nichts.
  • Drupal für Projekte einsetzen
  • Den Kunden regelmässig über Budget informieren. Optimal wäre natürlich, wenn dies gleich in den Bugtracker/ die Todoliste integriert wäre, damit zu jederzeit klar ist, wieviel Geld verbraucht wurde, und was es noch zu machen gibt.

Ehrlich gesagt… so online Projekte sind nicht ganz trivial und von der Uni aus lernt man es eigentlich anders, aber der Zeitdruck ist enorm gross und daher ist es auch nicht ganz so einfach hier den “Lehrbuchweg” zu finden. Das war ja hoffentlich nicht mein letztes Projekt und so bleibt doch noch ein wenig Zeit zur Verbesserung :)

Nicht alles ist Gold was glänzt in Drupal

Open Source mag sehr viele Vorteile haben, aber es gibt halt manchmal auch ein paar Nachteile. So habe ich in den letzten Tagen eine Multisite aufgesetzt. Diese ist insofern ein wenig speziell, als dass alle Sites einen gemeinsamen Benutzerstamm haben. Das lässt sich in Drupal sehr einfach machen, führt jedoch dazu, dass die Datenbank ziemlich aufgebläht wird (520 Tabellen in einer Datenbank). Zusätzliche Schwierigkeiten (eigentlich war das Vorherige keine wirkliche Schwierigkeit) war die Mehrsprachigkeit. Viele Modul werden von Amerikanern geschrieben… Mehrsprachigkeit ist dort nicht so entscheidend, wie dies hier in der Schweiz der Fall ist, daher gibt es immer wieder Konflikte mit Modulen, welche nicht für Mehrsprachigkeit ausgelegt sind.

Single Sign-on – Mit Tücken
Für das Szenario (gemeinsame Usertabelle) gibt es eigentlich ein hübsches kleines Modul, welches als stabile Version vorhanden ist. Single Sign-on bedeutet, dass sich der User auf einer Site einloggen kann und dann automatisch auf allen anderen Sites eingeloggt bleibt… eigentlich ziemlich praktisch aber funktioniert leider nicht ohne weiteres, da Drupal jeweils ein Cookie für den Login anlegen muss und dies dann natürlich für alle Domains angelegt werden muss.

Modul installiert, … schaut eigentlich alles gut aus. Doch dann: Etwas scheint nicht zu klappen. Und es klappt definitiv nicht. Cache 100x leeren, cron laufen lassen… alles mögliche, aber nichts scheint zu klappen :(
Ein Blick in die Issue Queue des Moduls… scheint aktiv zu sein, aber wird leider nicht gepflegt. Immerhin 1000+ Installationen und eine stabile Version, man könnte meinen, dass das Modul sicher funktionieren sollte… tut es aber definitiv nicht. Ich finde einen ersten fix in der Issue Queue… scheint eigentlich genau das Problem zu beheben, tut es aber nicht :( Verzweiflung pur. Wie weiter? Ein eigenes Modul entwickeln? Nach einer richtigen Single Sign-on Lösung umsehen? Vielleicht gibts einen Konflikt mit einem anderen Modul? Fragen über Fragen… und vor allem Ratlosigkeit.

Nach 2-3 Stunden wahlloser Fehlersuche reisse ich mich nochmals zusammen und fange von vorne an mit Debuggen und installiere mir dazu eine lokale Multisite mit gemeinsamer Usertabelle. Single sign-on funktioniert wunderbar. Kein Problem, keine Fehler. Debugge mit xDebug, um die Logik zu verstehen, welche relativ kompliziert ist! Debugger hilft nicht wirklich weiter.

Zu guter letzt! Debuggen auf die traditionalle Art: print $vars. Langsam arbeite ich mich vor. Das geht, das geht, in diese Schleife geht er auch rein, hier auch gut…. o? Was ist hier los?

<!–?php
$op = isset($_POST['op']) ? $_POST['op'] : ”;
if (function_exists(‘t’) ? $op == t(‘Log in’) : $op == ‘Log in’) {
// User is in the middle of logging in. Can’t do the master/slave
// checking yet because the login process happens after this module
// called. Set a flag telling us to do the master/slave checking
// once the login process is done.
$_SESSION['singlesignon_just_loggged_in'] = true;
return;
}
?>
Scheint eigentlich auf den ersten Anblick alles ok zu sein, ist es aber nicht. Die Funktion t kann gar nicht aufgerufen werden, da diese noch gar nicht geladen ist. Daher wird einfach $op mit ‘Log in’ vergleichen (das ist der default Value des Login Knopfes). Aber was passiert bei einer Multisite??? Ha. Ja genau, dort ist natürlich der Login Knopf Einloggen oder etwas ähnliches. Tja, das war es dann auch schon gewesen. Diesen Fehler behoben, Cookies gelöscht und schon funktioniert es einwandfrei :)

Fazit
Was lernen wir daraus? Vieles:

  • Wenn auf drupal.org ein Modul als stable markiert ist, heisst das noch lange nicht, dass es auch einfach so ohne nichts funktioniert! Es mag immer noch Situationen geben, die vom Maintainer nie ausprobiert wurden. Zudem kann ein Modul Maintainer jederzeit eine Version erstellen. Es gibt keine Qualitätskontrolle in dem Sinn, bzw. Qualitätskontrolle passiert durch die Community, aber das kann halt manchmal dauern… Entweder man setzt das Modul nicht ein, oder man muss halt selber ran an den Speck.
  • Mehrsprachigkeit erhöht die Komplexität und dadurch den Aufwand massiv! Es gibt wahrscheinlich immer irgendwo ein unerwartetes Problem, bzw. eine Herausforderung ;)

Zum Glück konnte das Problem noch behoben werden, bevor ich schlafen gegangen bin… ich hätte glaube ich sonst noch Alpträume gehabt und die ganze Zeit nach einer Lösung gesucht. Ich habe wirklich schon an mir gezweifelt… aber, es lebe Drupal. Man lernt schlussendlich jeden Tag ein paar neue Sachen und Lernen ist ja nicht gratis… leider.

Schöne, einfache Bilder Galerie mit Drupal – Teil 1

Es gibt wohl die verschiedensten Möglichkeiten, eine Bildergalerie zu machen (z.B. auch Fast Gallery). An dieser Stelle möchte ich jedoch zeigen, wie sich mittels CCK, Views und co. sehr einfach eine hübsche Galerie erstellen lässt. Diese schwarze Menu oben am Bildschirm ist das “Admin Menu”. Die folgenden weiteren Menus werden benötigt:

  • CCK (Content Construction Kit)
  • Imagefield
  • Filefield
  • Lightbox
  • Views
  • Views UI (ist ein Teil von Views)
  • Imagecache

1. Neuer Inhaltstyp anlegen

Diesen nennen wir am Besten bild. Das Body Feld löschen wir, da wir dieses hier so nicht brauchen und gegebenfalls mittels CCK ein neues Feld hinzufügen können.

Jetzt haben wir lediglich einen Inhaltstyp erstellt. Dieser besteht im Moment nur aus einem Titelfeld. Wir müssen also noch die Möglichkeit schaffen, ein Bild hinzuzufügen. Diese Möglichkeit verschafft CCK und seine vielen Zusatzmodule.

2. Inhaltstyp erweitern

Jetzt fügen wir also ein Imagefield hinzu:

Auf der Konfigurationsseite unseres neuen Imagefieldes müssen wir noch einige Dinge vornehmen:

Hilfetext: Den können wir für unsere Seite weglassen.

Permitted upload file extensions: Hier geben wir jpg und png ein

Path settings: Können wir auf /galerie setzen -> dadurch werden unsere Bilder unter sites/all/files/galerie gespeichert.

Required: Aktivieren wir am Besten, da wir ja wollen, dass zwingend ein Bild hochgeladen werden muss.

Jetzt können wir schon mal ein paar Bilder hochladen. Was wir jetzt jedoch haben sind einfach Nodes, welche erstellt werden, aber noch keinen Zusammenhang haben. Dafür ist jetzt Views zuständig. Mit Views können wir die ganzen Bilder Nodes entsprechend gruppieren. Zuerst aber noch ein wenig “Kosmetik”.

3. Imagecache einrichten

Imagecache erlaubt es, Bilder auf dem Server zu verändern, ohne dabei das Original anzutasten. Das coole dabei ist, dass die veränderte Version nicht immer on-the-fly erzeugt wird, sondern im Drupal Cache gespeichert wird. Dazu müssen zuerst die richtigen Bestandteile von Imagecache installiert werden.

Jetzt müssen wir zuerst einen neuen Preset hinzufügen. Ein Preset gibt an, was mit dem Bild gemacht werden soll. Wir legen also für unser Beispiel zuerst mal einen Preset für die Thumbnails an:

Jetzt sagen wir dem Preset, dass das Bild skaliert und gegebenfalls beschnitten werden soll, damit es schöne 120×100 Pixel gross wird. Dazu auf “Add scale and Crop” klicken Und dort bei der Höhe 100 und bei der Breite 120 eingeben. Das sollte dann so aussehen:

Jetzt fügen wir noch einen weiteren Preset ein und zwar “big”. Als Aktion fügen wir bei diesem jedoch nur ein Scale hinzu, da wir nicht wollen, dass das Bild beschnitten wird. Wichtig ist, wenn wir auf Scale gehen, dass nur ein Wert (entweder Breite oder Höhe) notwendig ist. Wir können also gut sagen, wir wollen einfach alle Bilder maximal 800 Pixel breit.

So, jetzt haben wir zwei Imagecache presets.

4. CCK und Imagecache

Nur ganz kurz dazwischen. Wenn wir wieder auf unseren Bild Inhaltstypen gehen und dort auf Display fields, können wir noch angeben wie dieser Inhaltstype angezeigt werden soll.

Wenn wir jetzt einen der hochgeladenen Nodes anschauen, dann wir entweder das kleine Thumbnail (wenn wir im Teaser sind) angezeigt oder aber das Grosse, wenn wir die Vollansicht des Nodes anschauen.

Damit ist jetzt auch alles parat um mit Views und Lightbox das ganze richtig schön und cool zu machen. Fortsetzung folgt.