Manchmal kann es nötig sein, in der Funktion hook_preprocess_page das CSS zu manipulieren. Normalerweise wird ja CSS über drupal_add_css hinzugefügt. In der preprocess_page Funktion ist es dafür jedoch bereits zu spät.

Auch über das Array $vars['css'] ist es nicht mehr möglich -> drupal_add_css macht eigentlich genau das. Es ist natürlich aber trotzdem möglich:

<!–?php
function ekd_lebensbuch_preprocess_page(&$vars, $hook) {
$path = implode("/",arg());
$ar = explode("/",drupal_get_path_alias($path));

$vars['styles'] .= " ";
}
?>

Oky, damit ist es dann auch schon gemacht. Es ist halt nicht ganz so elegant, weil man den HTML Markup selber schreiben muss, aber ein wenig Übung ist manchmal gar nicht so schlecht 😉

Heute habe ich mal wieder im Chat einen verzweifelten Drupal Anfänger getroffen. Es ist ja auch nicht ganz so einfach als Drupal Fortgeschrittener zu wissen, was Anfänger den beschäftigt und was die Schwierigkeiten sind.

Daher: Was sind Fragen eines Anfängers? So ganz Grundlegende Dinge? Aufgaben usw. Ich würde dann mal ein paar Tutorials, Screencasts und co. zusammenbauen. Also Fragen sind gefragt! Einfach das Kommentarform benützen und ich würde dann daraus ein wenig Inspirations schöpfen…

So, das Modul Advanced Blockqueue ist bereits als beta2 bereit zum getestet werden. Würde mich über Feedback sehr freuen. Wäre cool, wenn ein solches Prinzip in Drupal 7 umgesetzt wird.

Ich habe in den letzten zwei Tagen an einem verbesserten Blockmanagement für Drupal gearbeitet. Dieses Modul hat eigentlich zwei Ziele:

1. Flexibles und überschaubares Blockmanagement, mit der Möglichkeit die Blöcke auf jeder Seite manuell zu gestalten.
2. Möglichkeit der Vererbung

Hier schon mal ein paar Screenshots:

Auf jeder Seite erscheint dieses Icon (falls Berechtigung, um Blöcke zu administrieren)

1: bestehende Blöcke auf der Seite einfügen

2: Eine bestehende Nodequeue von einer anderen Seite einfügen

3: Einen Node als Block einfügen

Um das Aussehen des Nodes entsprechend anzupassen, gibt es eine .tpl Datei.

Wird bald möglichst als erste Beta veröffentlicht.

Auf dem Weg, Projekte agil umzusetzen, habe ich einen weiteren Meilenstein erreicht. Bisher sind Meetings immer sehr klassisch abgelaufen. Viel Bla bla, jemand macht ein paar Notizen, am Tag darauf wird das Protokoll verschickt, welches sowieso niemand liest und am nächsten Meeting ist man wieder gleich weit (natürlich ein wenig überspitzt).

Am heutigen Kick-Off Meeting für ein neues Projekt ist das alles ganz anderes abgelaufen: Bananascrum kam zum Einsatz. Es mag zwar nicht das Tool sein, welches am professionellsten ausschaut, aber es ist sehr funktional und praktisch.

Am Meeting wurde KEIN Protokoll geschrieben, sondern direkt ein Product Backlog in Bananascrum erstellt, am Beamer live vor und mit dem Kunden. Das hat einige super Vorteile:

• Missverständnisse verkleinern, da der Kunde sieht, was man aufschreibt
• Zeit sparen -> kein Nachbearbeiten von Protokoll
• Zeit sparen -> weniger Zeit um das initiale Product Backlog zu erstellen
• Führt den Kunden an das Tool heran und animiert ihn dazu, damit zu arbeiten

Der Kunde hat es auf jeden Fall als sehr positiv aufgefasst! Ich bin auf jeden Fall gespannt, wie es weiter geht. Hoffentlich weiterhin so positiv.

Mit Views 2 kann man einige super coole Dinge machen: Z.B. Felder in einer Views überschreiben. Das kleine Screencast zeigt, wie es geht.

Kaum zu glauben: Der IE (6 und 7) kann lediglich 30 CSS Stylesheets verarbeiten (http://support.microsoft.com/?scid=kb;en-us;262161&x=11&y=12)! Baut man eine grössere Seite, dann kommen schnell einmal 30 und mehr CSS Files zusammen. Lösung dazu:

• CSS Cache (Aggregator) anwerfen -> ist eigentlich sowieso Pflicht.
• @import Statement verwenden

Das spart vielleicht jemandem 2h Zeit, um den Fehler zu finden! Auf Drupal.org wird eifrig über einen Patch für D7 diskutiert.

Die Ladezeit von Drupal hängt von relativ vielen Dingen ab. Grundsätzlich kann man eine Webseite in zwei Dimensionen optimierung:

• Serverseitig
• Client Seitig

Serverseitige Optimierungen sind meiner Meinung nach aufwendiger als Client Seitige Optimierungen. Client Seitig gibt es relativ einfache Sachen:

• Bilder verkleinern -> Ladezeiten verkürzen
• CSS Dateien in ein File packen
• Javascript Dateien in ein File packen
• und noch mehr…

Jetzt kann man auch noch Zippen. Ich habe mir das ganze nicht im Detail angeschaut. Aber so wie ich es verstehe, werden Textfiles gezippt -> wodurch die Ladezeit weiter verkürzt wird. Einfach mal Testen:

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4.0[678] no-gzip

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary


Diesen Teil einfach mal ins .htaccess file kopieren. Es sollte jetzt eigentlich deutlich schneller laden!

Mit Drupal gibt es extrem viele Arten, eine Galerie zu erstellen. Ich habe hier mal wieder ein Miniscreencast, wie man so eine machen kann. Das coole an dieser Galerie ist, dass diese ein super cooles Order Feature hat!

Um die Grosse Version anzuschauen, einfach unten rechts aufs Vollbild Icon klicken

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!