Blog

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.

Was ist ein Node? Node = Knoten. Was soll das mit Drupal zu tun haben. Ich habe gerade eben einen Kommentar eines enttäuschten Drupal Users gelesen und mir gedacht, dass ich mich mal wieder den Basics widme. Ohne das Verständnisses des Nodes wird man mit Drupal nicht sehr weit kommen.

Die Node Analogie

Am Besten erklärt es sich anhand einer Analogie: Die Dateien auf dem Computer: Es gibt .jpg Dateien (Bilder), .doc (Word), .avi (Video), .ini (System) usw. Es gibt wahrscheinlich hunderte von verschiedenen Dateien. Was haben all diese Dateien gemeinsam?

• Namenskonvention -> die Endung gibt den Dateityp wieder
• Erstellungsdatum
• Einen Ersteller
• Eine Grösse
• Ein veränderungsdatum
• Einen Pfad
• …

Wenn ich mir jetzt diese Daten in einem Filebrowser (z.B. Windows Explorer) anschaue, dann kann ich diese nach bestimmten Kriterien sortieren. Obwohl alle Dateien verschieden sind, kann ich alle gleich behandeln.

Der Node

Der Node ist eigentlich genau gleich. Ein Node ist ein Inhalt. Ein Node hat verschiedene Ausprägungen, welche für jeden Node (egal welcher Typ) gleich sind:

• Author
• Erstellungsdatum
• Veränderungsdatum
• Eine ID (nid)
• Eine Versions ID (vid)
• Einen Status
• Eine Sprache
• Einen Type
• …

Standardmässig hat ein Node als Eingabefelder einen Titel und ein Body (Textkörper). Damit lassen sich einfache Seiten, Blog usw. machen. Soweit so gut. Die wahre Power des Drupal Node Systems kommt jedoch erst mit dem Einsatz von CCK

Drupal CCK

Content Construction Kit. Ein sehr mächtiges Tool! Damit lassen sich neue Nodetypen anlegen und erweitern! Ich habe die folgenden Inhaltstypen:

• Fotogalerie
• Blogpost

Das Blogpost kommt gut mit dem Titel und dem Body aus. Diesen Inhaltstyp können wir gut in rohform lassen. Aber die Bildergalerie?? Dazu wird der Fotogalerie Inhaltstyp mit einem Bildfeld erweitert (Imagefield). Zum standardmässigen Titel und Bodyfeld kommt jetzt noch ein Feld hinzu, mit welchem sich Bilder hochladen lassen.
Inhaltstypen können beliebig erweitert werden. Es gibt mittlerweile wohl schon hunderte von Erweiterungen: Feld für Youtube, Bilder, Videos, Audio, Flickr, Links usw.
Diese Nodes mögen äusserlich ganz anders aussehen, es bleibt jedoch bei den grundsätzlichen gemeinsam Eigenschaften.

Was ist der Vorteil?

Der Vorteil liegt auf der Hand. Da jeder einzelne Inhalt in Drupal eine grundsätzliche Gemeinsamkeit hat, kann man die verschiedenen Nodes einfach kombinieren und die Ausprägung den Gegebenheiten anpassen, ohne dass für jeden Nodetyp etwas eigenes gemacht werden muss.
Wer CCK sagt muss auch Views sagen. Mit Views lassen sich "Windwos Explorer Ansichten" bauen. Ich kann also z.B. eine Auflistung aller Nodes machen (das ist möglich, weil alle Nodes einen Titel, einen Author usw haben). Die liste kann also z.B. diese Felder als Tabelle auflisten mit Sortiermöglichkeiten enthalten.

Wie weiter

Drupal ist damit noch nicht erklärt und viel Dokumentation auf drupal.org ist in Englisch verfasst. Evtl. lohnt sich die Anschaffung eines Drupal Buches, z.b. O'Reillys Basics: Praxiswissen Drupal 7

Es gab in den letzten Tagen irgendwie Probleme mit meinem RSS Feed. Das Feed an und für sich war schon ok, aber sobald es von Feedburner "geburned" wurde, dann war es kein Feed mehr, sondern ein abgemagertes HTML.

In einem von meinen letzten Posts, habe ich über htaccess Redirection Rules geschrieben. www.rapsli.ch wurde nach rapsli.ch weitergeleitet. Es scheint jedoch, als würde diese Redirection Rule nicht mit Feedburner zusammenspielen 🙁

So wird es halt in Zukunft wieder ohne Redirection gehen müssen… ausser jemand hat irgendwie noch einen guten Tipp, wie man die Redirection Rules entsprechend zurecht biegt…

CMYK und RGB Bilder unterscheiden sich insofern, als dass CMYK Bilder 4 Kanäle haben, RGB lediglich 3. Daraus folgt, dass CMYK Bilder grundsätzlich eine bessere Qualität haben, dadurch jedoch auch grösser sind. (Siehe die Kommentare dazu…) CMYK Bilder werden vor allem im Printbereicht verwendet. Im Web leben RGB Bilder. Daher kann es sehr wohl mal vorkommen, dass man ein CMYK Bild in ein RGB Bild umwandeln muss.

Image API

In der Image API gibt es eine Qualitätsoption. Diese ist per Default auf 75 gestellt. Die Bilder werden jedoch nicht automatisch verkleiner. Nehmen wir also an, es gibt noch ein Imagefield in unserem Nodetypen. Dort lässt sich eine maximale Grösse des Bildes definieren. Sobald das hochzuladende Bild grösser ist, wird es über die Image API entsprechend verkleinert. -> CMYK Bilder werden dann ganz automatisch in RGB Bilder umgewandelt. Es bleiben jedoch zwei Probleme übrig:

1. Was passiert mit Bildern, die kleiner sind als die maximale Grösse und daher nicht verkleinert werden müssen?
2. Was passiert mit den Farben?

Problem 1

Dieses Problem lässt sich so nicht lösen. Es gibt sonst keine Möglichkeit, das Bild gleich gross zu belassen und nur die CMYK zu RGB Umwandlung durchzuführen. -> No Go. Wenn nicht das Original Bild benutzt wird, kann mittels ImageCache ein Workaround durchgeführt werden. Mit dem Einsatz von ImageCache wird das Bild automatisch in ein RGB Bild umgewandelt.

Problem 2

Die Farben werden verfälscht. Wenn keine zusätzlichen Parameter angegeben werden und das Bild von CMYK in RGB umgewandelt wird, dann werden die Farben verfälscht. Das kommt daher, dass in CMYK 4 Kanäle vorhanden sind, in RGB lediglich 3. Die neuen Bilder sehen dann so ein wenig Neonfarbig aus, bzw. so als hätten sie ein wenig mehr Kontrast. Kann unter Umständen schöner sein, aber auf jeden Fall ist es eine Abweichung vom Originalbild.

Lösung – Rules

Die Lösung ist eigentlich gar nicht so schwierig und lässt sich mit einer Zeile PHP Code durchführen! Zuerst muss das Rules Modul installiert werden. Mittels Rules lassen sich Workflows abbilden. Es handelt sich bei Rules nicht um das Standard Rules aus Drupal Core!!! Ein kleinese Tutorial zu Rules vielleicht zu einem späteren Zeitpunkt.

Dort wird jetzt eine neue Regel angelegt, welche beim erstellen eines Nodes ausgeführt wird. Als Filter kann man noch den Nodetyp angeben, welcher das Imagefield beinhaltet. Als Action gibt man Custom PHP Code an. Mittels PHP kann man jetzt auf das Kommandozeilen Programm ImageMagick zugreifen (sofern der Hoster das erlaubt)

<!–?php
$path = $node->field_image[0]['filepath'];
$cmyk = "/path/to/lib/adobe_icc/USWebCoatedSWOP.icc";
$rgb = "/path/to/lib/adobe_icc/AdobeRGB1998.icc";
exec("convert -profile $cmyk -profile $rgb $path $path");
?>

Diese .icc Files können von Adobe heruntergeladen werden und müssen auf dem Server hinterlegt werden (oder sie sind bereits irgendwo auf dem Server vorhanden). Zusätzlich können natürlich auch noch weitere Angaben für ImageMagick mitgegeben werden:

<!–?php
exec("convert -profile $cmyk -profile $rgb -quality 75 -scale 3000×3000 $path $path");
?>

Dadurch, dass $path zwei mal gleich ist, wird das Original Bild überschrieben, wass wir ja auch wollen. Die beiden Parameter -quality und -scale reduzieren die Qualität auf 75 resp. skalieren das Bild auf maximal 3000×3000 Pixel. Das mit diesen Profilen hat mich einige Stunden gekostet 🙁 … dafür weiss ich es jetzt bis an mein Lebensende!

Das Menusystem in Drupal kann manchmal ein wenig verwirrend sein, aber hier möchte ich doch mal in ein paar wenigen Schritten zeigen, wie es jedem gelingt, eine Menu in Drupal zu bauen.
Per Default wird man dort bereits einige Menus finden. Für uns wichtig sind vorerst mal das "Navigation" Menu und das "Primary Link". Diese beiden Menus sind oftmals auch bereits im Theme eingebetet:
Navigation: Dieses Menu enthält eigentlich alle Links, um Drupal zu bedienen. Wenn man neue Modul installiert, dann ist deren Funktionalität dort sichtbar. Je nach Berechtigung fällt das Menu grösser oder kleiner aus. Als Admin tut man jedoch gut daran Admin Menu oder etwas vergleichbares zu installieren, da es einfach viel komfortabler ist.
Primary Links: Ist ein leeres Menu. Im Theme ist meistens ein Plätzchen für die Primary Links vorgesehen.

Seite hinzufügen – Wie?
So, ich habe also eine Page geschrieben. Jetzt möchte ich diese Seite im Menu verlinken. Grundsätzlich gibt es zwei Möglichkeiten:

1. Den Menueintrag direkt an die Seite koppeln
2. Den Menueintrag manuell erstellen

1. Menueintrag an eine Seite koppeln
Beim Erstellen einer Seite gibt es eine Option "Menu settings". Dort kann direkt ein Menueintrag gemacht werden.

Wenn man jetzt in die Menuübersicht für Primary Links geht wird man sehen, dass es dort den entsprechenden Eintrag gibt. Zudem wird man dort wo die Primary Links platziert sind, den entsprechenden Eintrag finden.

2. Menueintrag manuell erstellen
Dies funktioniert eigentlich sehr ähnlich: Die Seite wird zuerst erstellt ohne eine Angabe zu den Menueinstellungen zu machen. Jetzt wechseln wir wieder zu den Primary Links und klicken dort auf "Add Item".

Pfad und Menulink Title angeben und schon ist das Menu gemacht. Wichtig: Der Pfad muss bereits existieren! Ich kann also nicht einfach mal ein paar Menu Items anlegen und dann im nachhinein die Seiten dazu anlegen.

Menus und Views – Vorsicht!
Menus und Views ist so eine Sache… Wenn man eine Views erstellt, hat man auch dort die Möglichkeit, ein Menu gerade automatisch hinzuzufügen, was eigentlich auch eine ziemlich coole Sache wäre. Was passiert nämlich: Es wird ein Menueintrag angelegt, welcher jedoch direkt mit der Views verbunden ist, will heissen, wenn ich die entsprechende Views lösche, dann lösche ich auch den Menueintrag.
Es kann jedoch manchmal sehr komische Auswirkungen haben: Die Views wird gelöscht, der Menueintrag jedoch nicht. Da jedoch die Views und somit der Pfad nicht mehr vorhanden ist, erscheint das Menu nicht mehr in der Auflistung in dem jeweiligen Menu -> das Menu ist zwar noch in der Datenbank, kann aber nicht mehr bearbeitet werden. Wenn ich jetzt eine neue Views anlege, welche unter dem gleichen Pfad liegt, dann erscheint der Menupunkt plötzlich wieder.
Bei nur wenigen Views und Menupunkten, wird man schon Wege und Lösungen finden, wenn jedoch viele Views vorhanden sind, dann empfinde ich es als sehr verwirrlich. Ich habe mir daher angewöhnt, dass ich für Views die Menueinträge immer von Hand mache, damit ich auch die volle Kontrolle drüber habe. Ist vielleicht nicht ganz so elegant und ein wenig aufwändiger, dafür weiss ich genau was passiert.

Einige Klassikerprobleme mit dem Menu
Von denen gibt es eigentlich zwei:

1. Ich habe ein mehrstufiges Menu, aber das Menu klappt nicht auf, wo es sollte.
2. Ich habe ein Menu, aber der aktive Pfad wird nicht richtig angezeigt.

Zugfahrt ist zuende… Vortsetzung folgt. Es ist aber nicht so schwer, wie man denken könnte.

Endlich, endlich ist es soweit. Ich habe einen neuen Maintainer für Fast Gallery gefunden!!! Aufgrund meiner beruflichen Belastung habe ich in den vergangenen Monaten nicht wirklich die Zeit gefunden/genommen, um das Modul entsprechend weiter zu entwickeln. Die Aktuelle Version hat noch einige Fixes nötig.

Es lebe Opensource!!! Endlich habe ich einen Co-Maintainer gefunden, welcher die verantwortungsvolle Aufgabe weiter übernimmt und das Modul weiterentwickelt. Ich hoffe, dass dadurch endlich wieder eine stabile Version rauskommt.

Es ist schon wieder viel zu spät, aber irgendwie ist die Musik gerade gut, und die Codezeilen strömen aus den Fingern. Nachdem ich mich in den letzten Monaten relativ intensiv mit Agilen Projektmethoden beschäftigt habe und darüber auch einige Blogeinträge geschrieben habe und vor allem gesehen habe, wie chaotisch agile Projekte werden können, habe ich am Samstag beschlossen ein kleines "Scrumtool" zu schreiben.

Scrum verfolgt ja eine ganz eigene Philosophie, welche meiner Meinung nach relativ schwer umsetzbar ist. Bei uns in der Previon ist eine grosse Hürde die festen Teams, welche sich ausschliesslich auf ein Projekt konzentrieren können.

Es gibt jedoch noch das Kanban System, welches meiner Meinung nach viel einfacher umsetzbar ist. Es gibt da sicher viele Bücher, aber zusammengefasst ist der Unterschied von Kanban und Scrum, dass bei Kanban keine eigentlich zeitlichen Sprints geplant werden, sondern die Aufgaben fortlaufend durchgeführt werden.

p>Da es meiner Meinung nach nicht wirklich schwer sein kann so ein Tool zu schreiben und ich schon mal etwas in Drupal umgesetzt habe und es ein regnerischer Samstag war, habe ich mich mal an die Arbeit gemacht und irgendwie hat es mich immer mehr reingezogen 😉

Ziel war eigentlich:

• So einfach wie möglich zu bedienen
• Schnell zu bedienen
• Eine öffentliche API
• Ein Desktop Client

Was mittlerweile steht:

• Ein User kann beliebig viele Projekte anlegen, welche nur für Teammitglieder sichbar sind
• Ein User kann in beliebig vielen Projekten sein
• Status sowie Priorität können nur mit klicken verändert werden
• Eingabeformulare sind start vereinfacht, so dass Eingaben schnell gemacht werden können
• Über Kommentare kann Veränderunge festgehalten werden

Hier ein paar Screenshots

[Nicht mehr verfügbar]

Ich muss noch ein paar Anpassungen machen, dann werde ich es mal veröffentlichen, falls jemand interesse hat. Besonders auf die API freue ich mich schon mal und auf den Air client. Der macht dann das ganze auch wirklich bedienbar. Ich finde allgemein bräuchte die Welt für solche Tools mehr Air clients.

Heute durfte ich einem ca. 2h Usability Test beiwohnen. Es ist immer wieder sehr bereichernd zu sehen, was man als Entwickler alles falsch bzw. zu wenig gut macht. Die Momentane Plattform, verbindet einen Redaktionellen sowie einen Community Teil. In der Planung werden Ideen und Gedanken ausgetauscht und schlussendlich werden diese vom User gar nicht akzeptiert. So war der ursprüngliche Gedanke, Community und Newsbereich strikte zu trennen -> wurde vom User klar verworfen.

Es waren auch bedenken an diesem Usability Test: "Das Portal ist noch sehr unfertig, ist der Usability Test nicht zu früh." Zugegeben, das waren auch meine Bedenken. Es hat sich heute jedoch herausgestellt, dass der Test überhaupt nicht zu früh war sondern zur genau richtigen Zeit. Zwar gab es diverse Meldungen, welche klar waren, aber es kam auch sehr konstruktive Kritik zurück, welche die weitere Entwicklung der Plattform sehr positiv beeinflussen wird.

Zugegeben: Die Tester waren der Plattform eigentlich wohlgesinnt. Von daher war die Kritik nicht ganz so vernichtend ausgefallen, wie es auch hätte passieren können.

Fazit

• Usability Tests früh genug ansetzen. Je früher, desto "wohlgesinnter" sollte der Tester jedoch sein.
• Eine Gruppendiskussion kann sinnvoll sein: Die Tester haben alle parallel getestet und zum Schluss gab es ein Gespräch. Es war interessant zu sehen, wie Gegenteilig zum Teil die Auffassungen waren.
• Nach einem frühen Beta-Test -> nicht verzweifeln, auch wenn noch viel Arbeit ansteht.
• Usability Tests durchführen!!!!!!

Lediglich die Laien geben www.rapsli.ch ein (die ganz faulen geben sogar http://www.rapsli.ch ein, oder irgend eine andere Domain). Ich persönlich gebe immer nur rapsli.ch ein. Chrome ergänzt das normalerweise automatisch mit www, andere Browser hingegen suchen die Domain dann unter http://rapsli.ch.

Dabei treffe ich immer wieder Domains an, welche ohne www nicht erreichbar sind! Wirkt nicht gerade professionell.

Gut ist, wenn die Domain sowohl mit als auch ohne www erreichbar ist, allderings entweder von der einen oder der anderen einen redirect macht. Ansonsten besteht das Problem von doppeltem Inhalt, da sowohl www.rapsli.ch als auch rapsli.ch den gleichen Inhalt anbietet (www wird als Subdomain wie blog.rapsli.ch behandelt).

In Apache lässt sich das spielend leicht lösen. In der .htaccess Datei lediglich folgende zwei Zeilen einfügen.

RewriteCond %{HTTP_HOST} ^rapsli.ch$ [NC]  
RewriteRule ^(.*)$ http://www.rapsli.ch/$1 [L,R=301]  

Sobald jetzt jemand via rapsli.ch auf den Webserver kommt, wird dieser via 301 Redirect auf www.rapsli.ch umgeleitet. Problem gelöst.

Sowohl der Besucher als auch die Suchmaschine wird dankbar für diese kleine Anpassung sein.

Die Multisite ist etwas extrem praktisches. Mehrere Seite laufen auf der gleichen Codebasis. Das hat vor allem den Vorteil, wenn man Modul aktualisieren muss -> dort liegen aber eben gerade auch die Tücken. Zuerst kurz: Was ist eine Multisite?

Multisite

Nehmen wir an, wir haben zwei Seiten: www.rapsli.ch und www.schaerwebdesign.ch. Man könnte jetzt für diese beiden Seiten je eine Drupalinstallation einrichten. Dazu muss man zwei Mal die ganzen Files auf den Server hochladen, zwei Datenbanken einrichten und zweimal Drupal installieren.

In einer Multisite lädt man lediglich einmal die Drupaldateien auf den Server und richtet dann unter sites/ folgende Ordner ein:

sites/

• all
• rapsli.ch
• schaerwebdesign.ch

Dort kommt jetzt die settings.php rein, welche jeweils auf eine andere Datenbank zeit. Natürlich muss jetzt das ganz jeweils zwei mal installiert werden. Die Module und Themes welche im all Ordner liegen, können von allen Seiten benützt werden.

Update einer Multisite

Beim Update werden jetzt einfach die Dateien der Module hochgeladen. Hier ist der Vorteil: Es gilt lediglich 1x das Ganze hochzuladen und nicht 2x (oder bei 10 Sites eben 10x). Jetzt muss lediglich noch auf JEDER Seite einmal update.php besucht werden.

Die Tücken einer Drupal Multisite…

… ist auch bereits hier. Nehmen wir an, eine Multisite wird von mehreren Leuten betreut. Person A betreut Site A, Person B die Site B. … Person B beschliesst, ein Update zu machen -> funktioniert wunderbar -> seine Seite funktioniert bestens. Person A schaut irgend wann mal auf seine Seite und erlebt das blaue Wunder. Seite funktioniert nicht mehr und es ist extrem schwierig herauszufinden, warum es nicht klappt. Ein Besucht auf update.php und schon ist alles gelöst.

Fazit

Reden, reden, reden. Beim Update ALLE Sites updaten und über den Tellerrand blicken. Drush könnte hilfreich sein. Multisites sind trotzdem eine super coole Sache!