Blog

Drush ist extrem hilfreich beim Administrieren einer Drupalseite. Ohne Drush nichts los. Wir Windows user ist es schwer gewöhnungsbedürftig. Es mag ein wenig abschreckend und gefürchtig wirken, wenn man plötzlich seine Drupalseite ohne Benutzeroberfläche administrieren sollte. Ja es ist komisch, aber nur am Anfang. Also, warum lohnt sich der Umstieg und die Einarbeitungszeit?

• Zeit sparen: Neue Module können mit einer Zeile Code runtergeladen und entpackt werden und mit einer zweiten Zeile Code installiert werden. Und noch viele andere Features
• Module up to date halten. Dadurch, dass das aktualisieren so einfach und schnell geht, macht man es auch viel öfters. Resultat: sichere und bessere Seiten

Reicht das? Oky. Es gibt aber auch einen Nachteil: Auf einem Shared Hosting wird man nicht weit kommen, denn man braucht einen Shell Zugriff. Auf meinem Hoster ist das nicht möglich… vielleicht wen man nachfragt?! Müsste ich wohl mal machen.

Für alle, welche jedoch im professionellen Umfeld mit Drupal Arbeiten ist Drush unumgänglich und wird so manches Problem vereinfachen.

Ach ja, noch einen kleinen Tipp. Drush wird über die Kommandozeile von Linux ausgeführt. Das heisst, PHP wird mit dem Kommandozeilenbenutzer ausgeführt. Es gibt jedoch eine php.ini für den normalen Webbenutzer und eine für den Kommandozeilenbenutzer. Standardmässig sind die auf 16 oder 32 MB gesetzt, was natürlich für Drupal ab einer bestimmten Grösse bei weitem nicht ausreicht. Dann wird der Wert in php.ini heraufgesetzt und alles funktioniert. Will man jetzt mit Drush arbeiten hat man sehr schnell ein Problem, weil hier ein anderer Wert gilt -> es gibt einen Fehler. Unter /etc/php5/cli/php.ini muss auch noch der entsprechende Wert angepasst werden.

Weiterführende Links:

http://www.drupal.org/project/drush Dort ist vor allem die Doku sehr sehr hilfreich!

Der Drupal Cache ist super! Und dazu auch noch sehr einfach zu verwenden. Drupal setzt diverse Cachings ein, welche default mässig implementiert sind. Wenn man jedoch selber ein Modul schreibt, muss man selber danach schauen. Kleines Beispiel:

Das Modul Fast Gallery. Wenn man eine Seite anschaut, dann müssen die ganzen Bilder aus der DB geladen werden, HTML gerendert werden usw. Dabei ändert sich auf der Fotoseite eigentlich gar nicht so viel, bzw. sie schaut für alle gleich aus. Eine super Möglichkeit, um den Cache zu verwenden und dazu noch so trivial:

1. Abfragen, ob bereits etwas im Cache ist.
2. Falls ja, dann dieses zurückgeben
3. Falls nicht die Operation durchführen
4. Fertigen Daten im Cache fürs nächste Mal speichern

Lullabot gibt eine super Erklärung ab, wo erklärt wird, wie man ihn einsetzt. … Es ist wirklich keine Hexerei. Das Schwierige ist wohl, wie und wo man ihn effizient einsetzt.

Ich such eine paar Tester, welche sich mal die neue Fast Gallery Version für Drupal 7 anschauen. Es gibt sicher noch ein paar Bugs und es wäre ja eigentlich schön, wenn so bald wie möglich eine stable Version verfügbar ist, so dass mit dem Release von D7 auch gleich richtig gestartet werden kann.

Es ist auf jeden Fall interessant, mal einen Blick in Drupal 7 zu werfen. Das wäre doch die Gelegenheit.

Die Slides meiner Präsentation sind auch noch hier verfügbar. … Hat Spass gemacht.

So, ich sitze am Flughafen und warte auf meinen Flieger. Auch der zweite Tag, hat sich einem Ende geneigt. Es waren ein paar ausgezeichnete Präsentationen dabei. Ich hoffe, meine gehörte auch zu denen.

Besonders gut gefallen hat mir die Case Study bezüglich Deployment und Development Prozesse sowie die Präsentation über Performanceoptimierung für Drupal. Ich persönlich habe hier sehr viel mitgenommen und hoffe, dass sich mit dem neuen Wissen und Ansichten die Prozesse bei der Previon weiter optimieren lassen. Auch bei vielen anderen Präsentation gab es hier und da immer wieder nützliche kleine Informationen (z.B. das Modul Vertical Tabs!!).

Es war auch interessant, ein paar "Berühmtheiten" aus der Drupalszene mal Live zu erleben… ist ganz anders, als wenn man nur einen Nickname und ein paar IRC Kommentare sieht. Auch konnte ich ein paar Leser meines Blogs antreffen 🙂 lustig. Tut mir leid, wenn ich mich nicht immer gerade an die Kommentare und Beiträge erinnern konnte.

Fazit

Das Camp war sehr gut organisiert und die Präsentationen sehr aufschlussreich. Schade war, dass es keinen zentralen Raum war, mit Sofa und so, um zwischendurch ein wenig zu hangen und zu plaudern. Schön zu sehen ist ja, dass es Confs überall in Europa gibt. Müsste eigentlich auch mal wieder etwas in der Schweiz geben?! … Interesse? Oder hat es einfach so viele Camps, dass eh niemand kommen würde. … oder mal anstatt eines Camps, ein Code Sprint organisieren….? So Zeit zum Boarden.

Der erste Tag ist vorbei. Ich muss sagen, ich bin ko. Viele Leute den ganzen Tag und jetzt geniesse ich die Ruhe. Sorry… after Show Party ohne mich, aber ich hoffe, es rockt trotzdem für alle die, welche dort sind. Es war noch erstaunlich zu sehen, dass Teilnehmer aus halb Europa angereist sind.

Fotos

Stimmung war sehr gut. Mir haben zwei Sessions sehr gut gefallen, welche eigentlich nicht direkt mit Drupal zu tun haben:

• Agile Development with Scrum
• Reaching your Audiencen with an Accessible CMS

Wie gesagt, direkt mit Drupal haben diese beide nichts zu tun, bzw. beziehen sich auf alles was irgendwie mit der Webentwicklung zu tun haben.

Accessibility

Irgendwie habe ich mich da immer ein wenig drum herum geschlängelt, mit dem Gedanken, dass es eigentlich nicht mein Problem/Verantwortung ist. Ich bin zudem immer davon ausgegangen, dass Accessibility Blinde und Taube meint. Ja, die gehören auch dazu, aber sind wohl eher die kleine Gruppe. Accessibility heisst: Die Webseite ist so einfach wie möglich nutzbar:

• Wie wird die Navigation gemacht?
• Ist die Seite konsistent?
• Sind Alt und Title Tags korrekt gesetzt?
• Können auch weniger geübte Leute mit der Seite zu recht
• usw…

Ich habe gerade letzte Woche mit einem Redaktor ein Gespräch, in dem er mir mehr oder weniger von diesen Punkten "vorgejammert" hat. Dabei ging es um kleine Dinge, wie "Aussagekräftige Titel für Links, damit man weiss, was dahinter ist" usw.

Also… ein wenig Aufmerksamkeit und schon wird die Seite einiges Zugreiflicher. Und ich habe jetzt auch angefangen hier im FCK Editor Headings einzusetzen (bisher habe ich für zwischenüberschriften einfach <strong> eingesetzt. Ist natürlich vollkommen falsch 🙁

Scrum

Ein langes und äusserst interessantes Thema. Danke Philipp. Die einzelnen Teile davon sind eigentlich trivial und für jeden verständlich. Dazu gehören Prinzipien wie:

• Ein Team bilden, welches sich ausschliesslich um ein Projekt kümmern kann.
• Den Kunden Committen, aussagekräftige User Stories zu formulieren: "As [role], I want [functionality] to achieve [goal].
• Sprints gemeinsam planen, dazu Story Points (SP) einsetzen.

Es gibt noch diverse andere Sachen. Ok, in Theorie hört es sich relativ einfach an, in Realität ist der Wechsel aber nicht ganz trivial, besonders, wenn die Projekte nicht extrem gross sind, so dass mehrere Leute über mehrere Monate 100% daran arbeiten können und nebenbei immer noch andere Dinge zwischendurch machen müssen.

Sonstiges

Die Knowledge Management Präsentation war eigentlich auch ganz super, nur war ich da schon ziemlich müde und die Komplexität der Gedankengänge doch nicht zu unterschätzen. Zudem habe ich als Developer gerade andere Sorgen … wäre auf jeden Fall interessant für unser Management.

Wiener Schnitzel sind echt nicht schlecht. War ein riesen Ding. Schade, dass das mit dem W-Lan nicht ganz so klappt wie es sollte. Zwischendurch ist es immer mal rausgeflogen. Lag wohl daran, dass einfach zu viele Leute im Saal waren.

War interessant, mal wieder ein paar "Online" Leute zu treffen: dereine, sirfichi, flobruit, halligalli und co. (sorry, die die ich vergessen habe… Ich bin schlecht im Namen merken). Zudem habe ich bekanntschaft mit Pressflow gemacht, dank den Jungs von Cocomore. Äusserst interessant, würde ich auch gerne besser kennenlernen… aber irgendwie bleibt einfach keine Zeit um alles zu wissen und zu können.

Bin mal auf morgen gespannt. Schaut ja nach einem sehr vollen Programm aus.

Wenn man eine Seite entwickelt, ist man meistens als User 1 unterwegs (der Superadmin schlechthin). Es gibt eigentlich keine Berechtigungsrestriktionen. Daher werden Zugriffsberechtigungen meistens übersehen. Letzte Woche hatten wir folgendes Szenario:

• Ein Benutzer hatte die Berechtigung alle Page Inhalte zu bearbeiten.
• Es wurden Artikel importiert.
• Dieser User konnte die Artikel nicht bearbeiten (obwohl er eigentlich die Berechtigung dazu hatte)

Selbst wenn man ihm mehr Berechtigungen gegeben hat (edit content types usw.) hat alles nichts gebracht. Es kam immer ein "Access Denied". Mist. Es blieb somit nichts anderes übrig, als mehr und mehr Permissions zu geben um zu schauen, welche Berechtigung es schlussendlich war. Und sie kam zum Vorschau: "Administer Filters"

Warum gerade diese?
Der Node hatte ein Textfeld, welches auf Full HTML gesetzt war. Der User hat jedoch nur Zugriff auf filtered HTML. Das führt dann dazu, dass der ganze Node gesperrt bleibt. Es lässt sich darüber diskutieren ob es Sinn macht oder nicht, aber es ist nun einfach so. Sobald jetzt dieser User auch Zugriff auf Full HTML hatte, war alles geritzt. It's just so easy!

Das war bereits das 2. Mal, dass mir so etwas passiert ist, nur konnte ich mich nicht mehr an das Filter Zeugs erinnern 😉 -> das nächste Mal werde ich jedoch bestimmt.

Drupal wird eigentlich relativ schnell ziemlich träge, wenn man es auf einem billigen shared hoster verwendet und dazu noch möglichst viele Module einschalten möchte. Damit sage ich aber nicht, dass Drupal per se langsam ist. Es gibt nämlich sehr viel, was sich machen lässt:

• Drupal Cache einschalten
• Javascript und CSS Aggregator

Damit kommt man schon sehr weit. Wer jedoch noch weiter gehen will, der muss mal das Boost Modul installieren. Damit kann man der Webseite wahrlich einen Boost verschaffen. Was richtig cool ist, ist der statische Cache. Dabei speichert Drupal in einem Verzeichnis die komplette HTML Version der Webseite als HTML ab und liefert dann diese direkt an den Benutzer aus -> keine DB Abfragen mehr nötig.

Was wird dadurch bewirkt? Ganz einfach: Der HTML Code, welcher schlussendlich im Browser ankommt muss mühsam zusammengebaut werden: Jedes Modul hat ein wenig was zu sagen, bis schlussendlich der fertige HTML Code bereit ist, ausgeliefert zu werden. Das Boost Modul speichert diese fertige HTML Ausgabe in einem HTML File ab und gibt diese dann direkt an den Benützer aus.

Ich habe das mal hier auf meinem Blog installiert und finde die Geschwindigkeit super! Wenn ich mit Firebug schaue, dann ist es Google Analytics, welches bremst und diverse andere Dinge… sicher jedoch nicht mehr Drupal.

Ein kleiner Wehrmutstropfen: Das Ganze funktioniert eigentlich nur für den anonymen User -> was hier im Blog eigentlich auch nicht weiter störend ist.

-> Das Modul: Sehr empfehlenswert!

Ein Node ist die Grundlage von Drupal. Alles ist ein Node. Wer noch nicht weiss, was ein Node ist, soll mal Google fragen. Also, ich gehe davon aus, dass der Leser weiss, was ein Node ist. Nodes können programmiererisch sehr einfach verändert werden. Dazu gibt es den hook_nodapi. Dieser hook wird immer aufgerufen, wenn Operationen am Node durchgeführt werden. Beispiel:

• Ein Benutzer erstellt einen neuen Blogeintrag. Es wird zuerst der $op = presave, dann $op = insert aufgerufen. Jedes Modul, welches hook_nodeapi implementiert kann also darauf einfluss nehmen. Ich könnte also folgendes machen:

function mymodule_nodeapi(&$node, $op) {  
  if ($op == 'presave') {
    $node->title = trim($node->title);
  }
}

Dadurch würde jetzt jedes mal wenn ein Node gespeichert wird, der Titel getrimmt (sprich Leerzeichen am Anfang und am Ende entfernt). Es ist dabei nicht nötig, irgend einen Wert zurück zugeben, da der $node als Referenz (dafür ist dieses & Zeichen) mitgegeben wird. Änderungen, welche am $node Objekt gemacht werden werden direkt übernommen. -> Grosse Flexibilität!!!

Manchmal ist es auch notwendig einen Node zu laden. Auch das ist denkbar einfach: Die Funktion node_load:

  $node = node_load(array('nid' => $nid));

Hier wird zuerst der Node aus der node Tabelle geladen und dann wird der hook_nodeapi mit $op = load aufgerufen. Auch hier könnte ich jetzt einfluss drauf nehmen und dem node noch zusätzliche Attribute mitgeben:

function mymodule_nodeapi(&$node, $op) {  
  if ($op == 'load') {
    $node->hello_world = 'Hello World';
  }
}

Oky, wenn ich jetzt nodeload aufrufe, dann wird diesem Node ein kleines «Hello World» hinzugefügt. Zusätzlich kann ich dort auch auf die ganzen CCK Informationen und einfach alle Infos, welche zu einem Node gehören auslesen (werden automatisch über nodeload() geladen.

Ein kleines Wort zur Performance. Wenn der Node nicht aus dem Cache kommt, dann kann diese Funktion sehr teuer sein, besonders wenn viele Module installiert sind, welche alle den Node mit irgendwelchen Daten anreichern wollen. Wenn dann dazu noch mehrere Nodes auf einer Seite sind, für welche alle noch ein node_load ausgeführt wird… teuer. Die gute Nachricht jedoch: Drupal hat einen Cache (falls eingeschalten) und so geht das Ganze doch ziemlich rassig.

Fast Gallery Übersicht.

Fast Gallery geht ziemlich schnell voran. Das Admin Interface sieht sehr ähnlich aus, wie in der Drupal 6 Version. Die folgenden Funktionen sind vorhanden:

• Aliase
• Titel für Galerie
• Mehrere Galerien
• Auswahl zwischen verschiedenen Engines
• Breadcrumbs

Im Frontend sieht es dann so aus (eigentlich aus gleich).

Die eigentlichen Änderungen sind unter der Haube: Die Storageengine kann beliebig ausgetauscht werden. Entwickler können eigene Storageengines schreiben, welche ohne Probleme sich einklinken können. So können reichhaltigere featurereichere Engines geschrieben werden. Die default Engine hat nur einige wenige Features, so dass sie jedoch überall funktioniert, einfach, schnell und stabil. Zum Experimentieren können dann weitere Engines geschrieben werden.