Kategorie: Uncategorized

Ich habe mittlerweile schon einige Drupal Projekt umgesetzt. Davon auch einige grössere Projekte an denen ich im Moment arbeite. Wie sieht denn das optimale Drupal Projekt aus, bzw. wie sieht das Team aus, welches das Projekt umsetzt.

Schlussendlich kommt es immer ein wenig auf die Projektgrösse drauf an, aber auch in grossen Projekten werden nie alle zusammen an einem Stück Code arbeiten, sondern das Projekt wird in mehrere autonome Supprojekte unterteilt. In diesen kleinen Projekten finde ich es eine dreier Kombination am effizientesten:

1. Ein PHP Entwickler.
2. Designer/ CSS Guru
3. Product Owner/ Entscheidungsträger

Hier ganz kurz, wie ich denke, dass die Rollen am Besten verteilt sind, und was die Fähigkeiten der jeweiligen Person sein sollte:

1. PHP Entwickler

Seine Verantwortung liegt in der funktionalen Umsetzung des Projektes (oder Teilprojektes). Er weiss, wie man Drupal optimal verwendet, kennt die verschiedenen Module und wie man sie am Effizientesten einsetzt. Er weiss wann und wie man eigene Module schreibt. Er kennt sich im Theming aus und weiss, welche Funktionen überschrieben werden müssen, um gegebenfalls den Markup anzupassen.

2. Designer/ CSS Guru

Kann gut mit Photoshop umgehen und darauf basierend ein Design entwickeln, welches er dann auch in HTML/CSS umsetzen kann. Er ist dafür verantwortlich, dass das Design stimmt und dass der Markup, welcher vom PHP Entwickler ausgegeben wird hübsch ausschaut. Die beiden arbeiten somit eng zusammen: Designer sagt, wenn er speziellen Markup braucht, PHP Entwickler stellt sicher, dass dieser kommt. Die beiden Arbeiten Hand in Hand zusammen.

3. Product Owner/ Entscheidungsträger

Dieser muss dem Projekt möglichst nahe sein und den Überblick haben, damit er die beiden (Entwickler und Designer) lenken kann. Er ist die Anlaufstellen, falls unklar ist, wie etwas umgesetzt werden soll, und ob der "Drupal Way" bereits reicht, oder ob es weiter personalifiziert werden soll. Damit können Designer und Entwickler sehr agil sein, da der Product Owner die eigentliche Anforderungsspezifikation ist.

Fazit

Web Applikationen in einem solchen Team mit Drupal zu entwickeln macht extrem Spass!

Drupal verleitet irgendwie ein wenig zu Scope Creep, wenn man nicht wirklich aufpasst. Die Rahmenbedingungen: Im Rahmen eines grossen Projekts, kommt eine kleine Anforderung hinzu, für eine kleine Übergangsseite, bis das grosse Projekt fertig ist. Im Klartext. Es ist nicht wirklich eingeplant. Hier das Szenario.

"Hallo Rapsli, ich bräuchte eine Seite, wo die Benutzer ein Bild hochladen können. Dieses wird als unpublished gespeichert. Der Moderator kann die Bilder in eine Queue legen, so dass jeweils an jedem Tag ein unterschiedliches Bild auf der Startseite erscheint."

Umsetzung. Theme besteht bereits. Wird bisher so gemacht, dass es jeweils statische Seiten gibt, welche mit einem kleinen Scriptli jeweils umgeschalten werden. Das Theme ganz spartanisch für Drupal anpassen -> lediglich so, dass nur die Startseite gut ausschaut. Für alle anderen Seiten wird Garland verwendet.

Der Moderator kann Nodes auswählen, welche er dann in eine Nodequeue stellen kann, welche jeden Tag ein anderes Element der Queue anzeigt. Damit das Ganze ein wenig schneller geht: Views Bulk Operations.

"Hallo Rapsli. Ich komme überhaupt nicht draus."

Kleiner Usability Fehler. Jetzt sieht es eigentlich nicht schlecht aus.

"Hallo Rapsli. Wenn jetzt hier 100 Bilder sind, dann ist es nicht möglich, die Übersicht zu wahren, welche Bilder alle bereits auf der Startseite waren."

Ok. Ich baue noch ein Feld ein, welches den Status angeben, aufnehmen kann. In der Views, wo alle Bilder aufgelistet werden, gibts zudem noch einen Filter, welcher nach diesem Status Feld filtert.

"Hallo Rapsli. Jo, jetzt muss ich jedes Bild manuell, wenn es auf der Startseite ist, den Status ändern. Es wäre natürlich viel einfacher, wenn dieser Status gleich direkt ändert, wenn man es in die Nodequeue schiebt."

Ja natürlich. Du hast recht. Das wäre auf jeden Fall viel besser. ABER. Das Projekt ist nicht wirklich eingeplant. Frag doch den Projektleiter, ob das in Ordnung geht, dann können wir ein kleines neues Projekt machen.

"Na gut… ich kann mit der jetztigen Version leben…"

Man muss einfach die richtige Balance finden. Da es kein festes, detailliertes Pflichtenheft gibt (agile Entwicklung), müssen zwischendurch auch Dinge gemacht werden, welche nicht vorgesehen sind. Sprich eine gewisse Flexibilität muss da sein, sonst ist man eben wieder soweit, dass man ein super detailliertes Pflichtenheft erstellt. ABER, wenn es sich um einen Teil handelt, welcher nicht direkt mit dem Projekt zu tun hat, soll man früh genug die Bremse ziehen, denn das eine zieht das andere mit sich und aus dem kleinen Nebenprojekt wird ein riesiges Hauptprojekt, welches aber in der initialen Aufwandschätzung überhaupt nicht vorgesehen ist.

… es passiert schneller als einem Lieb ist. Persönliche Erfahrung.

Nodequeue ist ein ziemlich cooles Modul. Dadurch lassen sich Reihenfolgen manuell festlegen. Besonders für Startseiten von Newsseiten kann es sehr nützlich sein. Jetzt ist die folgende Anforderung: Ein Bereich auf der Seite soll wechselnden Inhalt haben. Dieser Inhalt soll einmal pro Tag wechseln (zu einem festgelegten Zeitpunkt).

Das ganze lässt sich mit Nodequeue super umsetzen:

1. Eine Nodequeue anlegen. Diese auf 7 Items beschränken (für jeden Wochentag einen).
2. Zu den Views gehen und dort die entsprechende Nodequeue Views bearbeiten.
3. Ein Argument hinzufügen ((queue) Nodequeue: Position).
4. Dann folgendes anwählen:
   • Action to take if argument is not present:

     Provide default argument

     PHP Code

Der PHP Code sieht wie folgt aus:

<!–?php
$date = new DateTime();

$weekday = $date->format("w");

$weekday = $weekday + 1;

$hour = $date->format("H");

if($hour < 10) { if($weekday == 1) { $weekday = 7; } else { $weekday–; } } return $weekday; ?>

Das wäre es dann auch schon alles. Dadurch kann man die Seite ohne Argument aufrufen, via PHP wird dann ein Default Argument generiert, welches abhängig vom Wochentag ist. Um 10 Uhr wird dann jeweils ein neuer Inhalt aus der Nodequeue genommen.

So simpel!

Wenn man mit Drupal herumspielt muss man sich eigentlich nicht gross um die Datenbank kümmern und wie diese Konfiguriert ist. Aber eben nur "nicht wirklich". Falls es auf Performance ankommt, muss man sich sehr wohl darum kümmern. Hier das Szenario:

Ein Nodetyp Kapitel und ein Nodetyp Zusammenfassung. Die Zusammenfassungen können von registrierten Benützern erstellt werden und werden via nodereference einem Kapitel zugeordnet. Ein Kapitel kann also n Zusammenfassungen haben.

Jetzt möchte man gerne die folgende Liste ausgeben:

"Gib mir alle Kapitel, welche keine Zusammenfassung haben." Klingt trivial ist es aber nicht ganz: Es muss ein Join über das node_reference Feld gemacht werden, und überall dort, wo es kein Resultat gibt, muss es ausgegeben werden. Query lässt sich mit Subquerys lösen (das ganze Szenario war noch ein wenig komplizierter, aber zur Veranschaulichung reicht es).

Gut, Query ausführen: Dauer ca. 15 Sekunden. Query umschreiben und optimieren: Nur noch 7 Sekunden. Ist einfach noch immer viel zu langsam, was dazu führt, dass die Leute immer mal wieder die Refreshtaste klicken, was den DB Server in die Knie zwingt.

Es stellt sich natürlich die grosse Frage, wo wohl das Problem liegt. Nach vielem Nachforschen, war es dann relativ offensichtlich. Auf dem nodereference Feld war kein Index angelegt worden. Ich bin kein DB Experte, aber ein Index ermöglich ein schnelleres darauf Zugreiffen. Legt man in der DB auf diesem Feld einen Index an, dann dauert der Query lediglich noch einige Millisekunden. -> Problem gelöst.

Fazit: Es gibt wahrscheinlich viele Dinge, Drupal zu optimieren. Dazu gehört eine gute Caching Strategie usw. ABER. Indexe am richtigen Ort zu setzen ist einfach Musik in den Ohren: Minimaler Aufwand aber unter Umständen maximale Performance-Steigerung!

Es ist jetzt ein knapper Monat her, seit ich bei der Previon als Entwickler angefangen und mich eigentlich hauptsächlich mit Drupal Projekten beschäftigt habe. Ich kenne Drupal bereits zwei Jahre, habe Erfahrungen im Theming, der Modulentwicklung und auch der Konfiguration und habe die vergangenen Jahren diverse Projekte auf Freelance Basis umgesetzt.

Wenn ich meine Lernkurve anschaue… mir wird fast schlecht, wenn ich an meine ersten Module zurückdenke. Das war überhaupt nicht gut, aber ich kannte die Drupal API kaum. Jetzt arbeite ich an Projekten, wo mehrere Leute entwickelt sind. Nun, was ist so der Eindruck? Es ist schon ein wenig anders.

Dabei ist mir folgendes bewusst geworden: Drupal Projekte verlangen einen agilen Entwicklungsprozess. Die folgende Grafik zeigt den agilen Entwicklungsprozess auf:

[Grafik von Microtool.de]

Die verschiedenen Phasen der Entwicklung werden also nicht starr abgewickelt, sondern es entsteht ein Zyklus bestehend aus den Phasen. Nach jedem Zyklus gibt es einen brauchbaren Prototypen. Durch das Verwenden des Prototypen entstehen dann die Anforderungen für den nächsten Zyklus.

Drupal ist prädestiniert für einen solchen Entwicklungszyklus. Dies hat die folgenden Gründe:

1. Drupal ist Open Source. Open Source Projekte werden von Natur aus sehr agil geführt. Es wird was gemacht -> Bereitgestellt -> Wird von der Öffentlichkeit verwendet -> Feedback -> Issue Queue -> neue Version.
2. Viele Dinge lassen sich in Drupal out-of the Box umsetzen. Dadurch wird ein gewisser "Standard" vorgegeben. Dadurch können zum Teil coole Zusatzfunktionen hinzugewonnen werden, aber unter Umständen müssen Wünsche ein wenig umgeändert werden. Ein agiler Prozess bietet sich an, weil eben nicht alles von Grund auf geplant werden muss.

Ich finde ein Drupal Projekt könnte nach dem folgenden Schema ablaufen:

1. Rohprototyp -> Was ist möglich mit Drupal, Drupal vorstellen, Funktionen vorstellen. Dieser Prototyp sieht sehr roh aus, ist ein Proof of Concept und kann wohl in einem halben Tag zusammengeklickt werden. Module ausprobieren.
2. Wichtige Funktionoen definieren und die Grundzüge der Architektur beschreiben. Dazu müssen Grundlegen Entscheide gefällt werden, z.B. für eine Community Seite, soll Organic Groups eingesetzt werden, oder was für wichtige Inhaltstypen sind vorhanden usw. Halt einfach Dinge, welche das Projekt entscheidend beeinflussen.
3. Einen neuen Prototypen nochmals von Grund auf bauen (neu daher, weil im ersten Prototypen unter Umständen viele Altlasten herumliegen) und dabei diese Kernelemente einbauen.
4. Theme bauen. Es muss nicht komplett fertig sein. Wahrscheinlich gibt es Leute, welche hier anderer Meinung sind, ich denke jedoch, dass es essentiell ist, weil: Der Kunde oder Testpersonen sollen so früh wie möglich auf der Seite testen. Wenn da nur ein Garland Theme mit den nackten Funktionen und Blöcken ist, dann wird er sich damit nicht zurechtfinden, wird es hässlich finden und sich fragen, was wir die ganze Zeit machen.
5. Einen Zugang für den Kunden einrichten. Der soll ruhig darauf herumspielen. Er muss sich halt einfach bewusst sein, dass die Seite "under construction" ist. (dazu ist das secure sites Modul sehr hilfreich).
6. Sehr nützlich wäre jetzt ein Bugtracker, ein Google Docs oder irgend ein System. Dort sind die Tasks aufgelistet, welche noch umgesetzt werden können und der Kunde kann Fehler und Änderungswünsche reinschreiben. Nicht schlecht wäre es natürlich, wenn der Kunde die Prioritäten der einzelnen Punkte bearbeiten kann. Der Entwickler arbeitet dann jeweils an den Tasks mit der höchsten Priorität -> was je nach dem Ändern kann.
7. Im nächsten Zyklus werden jetzt die Punkte aus dem Bugtracker genommen und daran gearbeitet, damit eine neue bessere Version besteht.
8. Immer Weiter und Weiter.

Es ist jedoch in der Praxis nicht ganz so leicht, das alles so umzusetzen aber es lohnt sich allemal und resultiert in zufriedenen Kunden und zufriedenen Entwicklern. Bugtracker sind auch ein super Ding!!! Warum. Das werde ich in einem folgenden Blogpost vielleicht mal erläutern.

Es scheint, als würde es vorwärts gehen. DrupalCon 2009 in Paris hat die "Geld Tore" schon mal geöffnet. Tickets können bereits gekauft werden. Ich hoffe mal, dass ich auch endlich mal dabei sein kann. Paris wäre ja nun nicht allzu weit weg…

Views 2 ist extremstens flexibel. Es kann eigentlich alles, aber ich muss zugeben, dass es auch extrem komplex ist 😉 Also, die Ausgangslage war eigentlich die Folgende:

Von einer Drupalseite sollen periodisch Einträge Nodes in eine andere Drupalinstallation exportiert werden.

Klingt eigentlich recht trivial ist es auch, mit ein paar Hürden vom Themen von RSS Feeds. Wie bereits erwähnt, wird das ganze mit RSS Feeds gemacht. Das heisst, Seite 1 stellt ein RSS Feed bereit, welches Seite 2 periodisch mittels Feed Api abfragt und importiert.

1. RSS Feed mit Views erstellen

Trivial. Neues Views anlegen (in den meisten Fällen mit Nodes, aber geht sicher auch mit Usern oder Files). Dann ein paar Filterregeln und Sortierregeln zusammenstellen und eine neue Ansicht "RSS" hinzufügen.

Das ist es eigentlich bereits. Sehr simpel. Leider gibt es hier nicht die Möglichkeit, Felder zu definieren, welche dann im RSS Feed erscheinen (CCK Felder z.B.). Man kann lediglich den Title und dann den eigentlichen Node Body ausgeben. Für ein einfaches RSS Feed wird das wohl auch alles sein, wenn man das Feed jedoch zum importieren und exportieren verwenden will, dann müssen die Daten im Feed klar strukturiert bleiben.

2. RSS Feed themen

Views 2 hat die super geniale Eigenschaft, dass man die tpl Dateien überschreiben kann. Per default kommt ein RSS 2.0 Feed raus. Die Feed Api und der dazu passende Field Mapper kann jedoch nur ein Atom Feed einwandfrei bearbeiten. Daher ist es notwendig, das Feed in ein Atom Feed umzuschreiben.

3. Herausforderungen

1. Es ist gar nicht so einfach ein Atom Feed manuell zu erstellen 😉
2. Leider wird in der tpl Datei das Node Objekt nicht bereit gestellt. Dieses muss relativ umständlich aus dem views Objekt herausgeholt werden.
3. Das Timing ist natürlich nicht ganz einfach. Nehmen wird mal an, auf Seite 1 entstehen pro Stunde 50 neue Nodes, welche exportiert werden müssen. In unserem erstellten Feed stellen wird jedoch lediglich 25 Nodes dar. Wenn wir jetzt den Cron Job auf Seite 2 lediglich alle 2h laufen lassen, dann verpassen wir Nodes, da diese dann nicht mehr in den Top 25 aktuellsten Nodes drin ist.
   Optimal wäre es, ein Flag zu setzen, wenn ein Node importiert wurde, aber das lässt sich mit diesen einfachen Mitteln nicht einfach so bewerkstelligen, daher bleibt wohl nichts anderes übrig, als einfach das Feed genügend lang zu machen und den Cron Job genügend oft aufzurufen.

Im Post von gestern habe ich kurz erklärt, worum es beim Cross Site Scripting geht. Jetzt geht es jedoch darum, das ganze noch ein wenig auszuweiten. Bisher ging es ja vor allem um triviale/offensichtliche Sicherheitslücken.

Es geht aber unter Umständen viel heimtückischer zum Beispiel mit Bildern. Z.B. das Bild unten von der netten kleinen Katze, aber diese Katze hat es in sich.

Schauen wir uns nämlich die Exif Daten dieses Bildes an, so werden wir sehen, dass es einen XSS Angriff enthält:

Würde ich jetzt auf meiner Applikation den Exif Wert "Camera Model Name" einfach so ausgeben würde, dann würde eine hübsche kleine Javascript Message Box mit xss erscheinen… oder es lassen sich eben auch noch andere Dinge machen. Das wäre eine massive Sicherheitslücke einer Applikation.

In Drupal verwendet man dazu am Besten die check_plain() Funktion, welche eben dafür schaut, dass keine bösen Sachen reinkommen. Beim Entwickeln von Anwendungen also nicht immer nur die offensichtlichen Sicherheitslücken beachten sondern auch weniger offensichtliche aber dennoch gefährliche.

Ich freue mich über Feedback.

Untitled from Raphael on Vimeo.