Blog

  • Es lebe Ubuntu 10.04

    Vor einem halben Jahr habe ich mit Wubi angefangen. Ich konnte weiterhin noch mein gewohntes Windows System drauf haben und hätte zur Not auch wieder wechseln können. Es hat sich dann gezeigt, dass ich immer wie besser mit Linux zurecht komme. Ich wurde sogar euphorisch. PHP Entwickeln und Ubuntu macht einfach mehr Spass und das Verständnis für das *nix System hilft massiv: SVN, Konsole, patches, Rechte usw. … bei Windows geht das irgendwie verloren.

    Nun, ja, ich habe ein halbes Jahr auf einer 12 GB halb virtualisierten Ubuntu Partition gearbeitet. Mit der Zeit wird der Platz ziemlich knapp und so habe ich jetzt endlich endlich den kompletten Umstieg gemacht, und dabei gerade auf Ubuntu 10.04 gewechselt… ich bin schwer schwer begeistert. Ist einfach super genial. Aufstarten braucht ca. 20 Sekunden und dann kann ich mit Arbeiten anfangen, runterfahren geht noch schneller. Super.

    Das Doklet unten ist noch recht cool 😉 … was soll ich sagen, ich kanns nur weiterempfehlen. Es lebe OpenSource!

  • Drupal Rules API

    Mittels Rules lassen sich herrliche Dinge machen. Es sind kaum Grenzen gesetzt, was Workflows und solche Sachen angeht. Mit Klicken kommt man schon ziemlich weit. Manchmal kann es aber notwendig sein, dass man eigene Actions für die Rules bereitstellt. Klaro, man kann praktisch alles mit eingebettetem PHP Code machen, aber das ist nicht wirklich eine glamurose Lösung. Hier ein kleines Beispiel:

    <!–?php
    /**

    • implementation of hook_rules_action_info()
      */
      function fast_gallery_rules_action_info() {
      return array(
      'fast_gallery_flush_caches' => array(
      'label' => t('Flush Fast Gallery Cache'),
      'module' => 'Fast Gallery',
      ),
      );
      }
      ?>

    Mit dem hook_rules_action_info sage ich dem Rules Modules, dass wir eine Action anbieten. fast_gallery_flush_caches ist die Callbackfunktion, welche aufgerufen wird, wenn die Action ausgeführt wird. Das Label ist der Text, welche im Dropdown aufgelistet wird.

    Folgendes Szenario wäre jetzt denkbar. Ich habe irgend eine spezielle Funktion. Ich möchte, dass jedesmal, wenn diese Aktion aufgerufen wird, der Fast Gallery Cache geleert wird. Ganz einfach: Einfach eine Rules mit dem entsprechenden Trigger machen und dann diese Action hinzufügen. Und schon klappt es wunderbar.

    Ich werde auf jeden Fall bei meinen zukünftigen Modulen immer schauen, dass solche Integrationen vorhanden sind. Features, Rules und Co. sind schon sehr hilfreich und je mehr Modulmaintainer Integrationen mit diesen Modulen haben, desto flexibler wird Drupal.

  • Eine Einleitung in Panels

    Panels kommt mit einigen Modulen daher. Bevor wir ernsthaft mit Panels anfangen, sollten wir wissen, welches Modul wofür zuständig ist:

    Chaos Tools Suite (CTools)

    Eigentlich ist die gar nicht so chaotisch, wie sie klingt 😉 Dort werden diverse Funktionen gebündet, welche in diversen anderen Modulen immer wieder gebraucht werden (hauptsächlich Panels und Views). Dazu gehören unter anderem: Diese Overlays, Exportmöglichkeiten und das Pluginsystem.

    Page Manager

    Dieser gibt uns die Möglichkeit Templates für Seiten zu erstellen und ersetzt dadurch verschiedene node.tpl.php Dateien. Es gibt zum Beispiel die Möglichkeit folgende Seiten anzupassen: Taxonomy Term Template, User profile Template, Node Template, Node add/edit Form Template.

    Die Vorgehensweise ist denkbar einfach: Template editieren, Layout auswählen Inhalte einfügen… schon gemacht. Ausführlicheres Tutorial kommt noch.

    Views content panes

    Wenn man ein Panels erstellt, dann lassen sich gewisse Elemente in die sog. Panes einfügen: Blöcke, Nodes usw. und eben auch Views. Diese lassen sich natürlich via Blöcke einfügen, aber es ist eigentlich besser diese als Views Panes einzufügen (ein Views Pane kann in der Views hinzugefügt werden, gleich wie Block, sobald man das Modul aktiviert hat). Warum ist ein Views Pane besser als ein Views Block? Es lassen sich diverse Zusatzangaben machen.

    Panels

    Nur Panels macht nicht viel. Hier wird die Grundfunktionalität gebündelt, aber wenn man nur Panels aktiviert, dann hat man noch nicht sehr viel gewonnen, bzw. kann nicht sehr viel damit machen.

    Panels Nodes

    Damit lassen sich Nodes als Panels erstellen. Unter "Inhalt erstellen" wird ein neuer Inhaltstyp erscheinen (Panel). Ich kann ein neues Panel erstellen und dann genau gleich für dieses ein Layout wählen und die Panes mit entsprechenden Inhaltselement füllen (auch normaler Text).

    Mini Panel

    Ist ähnlich wie Panels Nodes, nur dass sich damit "panelisierte Blöcke" erstellen lassen. Layout auswählen, Panels mit Inhalt befüllen und dann habe ich einen neuen Block, den ich in eine Region legen kann.

    Dann gibt es noch ein recht cooles Zusatzmodul

    Panels Everywhere

    Damit lässt sich der Page Manager erweitern. Im Page Manager lassen sich nur die Elemente bearbeiten, welche im page.tpl.php als $content ausgegeben werden, es lässt sich nicht jedoch das ganze Seitenlayout mit Panels gestalten. Panels Everywhere erlaubt das jedoch.

    Folgendes Usecase wäre somit möglich: Ein Theme erstellen, welches keine Regions hat und dafür ein Seitenlayout mit Panels Everywhere erstellen und dort entsprechendes Layout wählen (z.B. Content mit einer rechten Spalte) und jetzt dort entsprechend Blöcke einfüllen und in der Content Spalte den Content ausgeben.

    … etwas abstrakt, wenn ich mal dazukomme, werde ich ein paar ausführlichere Tutorials machen.

  • Building Drupal Blocks

    Views und CCK kennt jeder. Sie gehören schon fast zu einer Webseite und das wird sich in Zukunft noch verstärken, da CCK Teil von Drupal Core ist. Niemand zweifelt an diesen Modulen, viele kennen und verstehen sie und wissen, wie sie eingesetzt werden müssen. So auch ich.

    Meiner Meinung nach gibt es noch andere Module, welche eine ähnliche Wichtigkeit haben und welche man genau so verstehen sollte: Panels/Display Suite, Rules und Features.

    Ziel von Drupal oder auch einem jedem anderen Framework sollte sein, die Webseitenerstellung zu abstrahieren und zu vereinfachen (eigentlich so, wie das Frontpage mal gemacht hat). In Drupal gibt es dazu die folgenden Module:

    CCK

    Ist unser Datenmodell-modelier-tool. Damit können wir definieren, wie unsere Inhalte ausschauen, wobei ein zentrales Interface vorhanden ist (der Node). Bespiele müssen an dieser Stelle nicht erwähnt werden.

    Views

    Ist Datenmodell-abfrage-tool bzw. unser Query-Builder. Es lassen sich mit Views relativ komplexe Queries bauen. Zusätzliche Features ist der eingebaute Templatingmechanismus, sowie die Cachingmöglichkeiten. Das Gute daran: Views und CCK spielen ausgezeichnet zusammen.

    Panels/Display Suite

    Die Seite gestalten. Weder Views noch CCK sind dazu geeignet. Eine gängige Möglichkeit sind die .tpl Dateien aus dem Theme, aber dann wiederum hat man das Problem, dass gewisse Strukturen ans Theme gebunden sind, was nicht immer wünschenswert ist. Im Weiteren ist es aufwändig diese solche Seiten zu warten und die Flexibilität ist auch nicht die beste (komplexe Sites können eine beachtliche Anzahl an tpl Dateien erfordern). Was also sonst? Eben Panels oder/und Display Suite.

    Ich habe immer ein wenig eine Abneigung gegen Panels gehabt. Keine Ahnung warum. Seit ich mich jedoch ein bisschen eingängiger damit beschäftigt habe, bin ich schwer begeistert. Die Display Suite ist super einfach, aber nicht ganz so umfangreich. Sie bezieht sich auf Nodes, Kommentare, Users usw. Panels dagegen geht weiter, es lassen sich ganze Seiten damit gestalten, dazu lassen sich auch Beziehungen zwischen Nodes abbilden… super! Vielleicht mache ich hier mal wieder ein kleines Screencast oder Tutorial

    Rules

    Aktionen. Workflows abbilden oder irgendwelche sonstigen Ereignisse. Rules ist dein Freund. Ein super mächtiges Werkzeug, welches auch Zeitsteuerung erlaubt (aber das ist leider nicht ganz so eingängig).

    Features

    Und zu guter letzt: Mein Freund Features, der das Leben so viel einfacher macht. Glücklicherweise unterstützen all diese Module Features. Features erlaubt es, Funktionalität/Struktur zu bündeln und somit auf anderen Seiten wieder einzusetzen. Ich könnte also z.B. ein Bildergalerie Feature basierend auf Views und CCK und Display Suite machen und dann das in ein Feature bündeln und auf einer anderen Seite wieder verwenden.

    Kennt man all diese Module und weiss wie damit umgehen, dann hat man schon seeeehr viel gewonnen!

  • certifiedtorock – Drupal Zertifizierung

    Drupal-Zertifizierung. Immer wieder hört man etwas davon, aber geben tut es nicht wirklich etwas. Irgendwie passt es auch nicht so richtig in die Drupalwelt, und wenn schon, dann müsste es von Acquia kommen. Wiejedoch misst man etwas? Rein nur gute PHP-Kenntnisse reichen nicht, auch die Community-Fähigkeiten gehören zu einem guten Drupalianer.

    Es gibt ja eigentlich nichts einfacheres. Einfach mal das Profil auf drupal.org anschauen oder auch auf drupalcenter.de und schon weiss man ziemlich viel über die Aktivität einer Person.

    Greggles hat ein lustiges/interessantes Tool gebaut: Certified to Rock. Die Skala geht von 0 – 11. Dries ist bei 11, ich (rapsli) immerhin bei 5. Niemand weiss so genau, was es auf sich hat und wie der Algorithmus genau funktioniert.

    Gebt doch im Kommentarformular an, was für ein Ranking ihr habt… würde mich interessieren

  • Drupal User Group in Basel

    Vor mehr als 1 Jahr war ich in Zürich mit dabei und habe mitgeholfen, dort die ganze DUG zu starten. Zürich ist mir jetzt einfach zu weit geworden. Seit Monaten schon habe ich mich immer ein wenig hier in Basel umgehört, ob es Leute gibt, aber nie wirklich ein Echo bekommen. Es scheint sich endlich etwas zu bewegen. Seit ein paar Tagen gibt es jetzt auch auf Drupal.org die Drupal User Group (DUG) Basel.

    Sind noch auf der Suche nach einer geeigneten Location. Falls jemand behilflich sein kann… bitte bei mir melden, ansonsten werden wir wohl dann im Starbucks anfangen.

  • Power Menu – Review

    Power menu. Für unsere Projekte hatten wir ein dauerbrennerproblem: Aktive Menupunkte. Michi hat ja bereits darüber berichtet. Sicher kennt jeder das Problem:

    1. Views anlegen, welche zum Beispiel alle Blogeinträge auflistet.
    2. Ein Menupunkt anlegen, welcher auf die Views linkt. Wenn ich auf der Views bin, dann wird der Menupunkt als aktiv markiert.
    3. Klicke ich jetzt auf einen Blogeintrag, dann ist der Menupunkt nicht mehr aktiv.

    Das ist eigentlich nicht wirklich so wie es sein sollte. Um das Problem zu lösen gibt es das Modul "Menutrails". Das erfüllt auch seine Dienste, aber ist leider nicht wirklich intuitiv. Denn, wenn ich einen neuen Menupunkt anlege, dann muss ich noch zu den diversesten anderen Orten gehen, um dort die entsprechenden Einstellungen zu tätigen. Dem Kunden zu erklären… äh… eher schlecht.

    Daher ein alternativer Ansatz: Die Einstellungen direkt bei der Erstellung des Menupunktes vornehmen:

    Ich kann ein Vokabular festlegen, welche die Navigationsstruktur abbildet. Es gibt auch ein Modul, welches erlaubt ein Menu aus einer Taxonomy generieren zu lassen. Das ist jedoch in vielen Fällen nicht sinnvoll, z.B. wenn ein Kontaktformular in der Navigation ist.

    Also, aus dem selektierten Vokabular, können Terms und Inhaltstypen angewählt werden. Sobald ein Node kommt, welcher vom entsprechenden Inhaltstypen ist, oder einem gewählten Term zugehörig ist, wird der Menupunkt aktiv gesetzt. Zusätzlich können hier direkt URL Aliase erstellt werden. Dies ist dann nützlich, wenn man auf eine Views verlinken will, ein Argument übergeben will, der Pfad jedoch als Top Navigation vorhanden sein sollte, z.B. meine-views/sport -> /sport und meine-views/fashion -> /fashion

    Um auf das Beispiel vom Anfang zurückzugehen. Ich könnte beim Erstellen des Menupunktes "Blog" den Inhaltstyp "Blog" anwählen.

    Mittlerweile werden auch die Breadcrumps entsprechend dem Menu gesetzt. Noch ist es nicht richtig getestet, also ich würde mich freuen, wenn ein paar Leutchen das Modul mal anschauen würden. Über Feedback bin ich froh. Sobald ein paar Installationen vorhanden sind, werde ich das Modul in den Beta Status verlegen.

  • Drupal Benchmark – Einfluss der Anzahl an Drupalmodulen

    Ich habe mich immer gefragt, wie die Anzahl an Modulen die Drupal Performance beeinflusst. Ich habe mich oft gefragt, ob es besser ist viele kleine Module zu haben, oder aber ein grosses. Endlich bin ich dazu gekommen einen kleinen Benchmark zu machen. Rein der Übersichtlichkeitshalber ist es eigentlich viel besser die ganzen Funktionalitäten in kleine Module zu unterteilen, was aber dann zur Folge hat, dass das Hook System stärker belastet wird.

    Der Testumgebung sah wie folgt aus:

    • Drupal 6.16
    • Drupal Core Module aktiviert (und nur diese, keine anderen), sprich das sind insgesamt 5 Module.
    • Cache deaktiviert.
    • Ubuntu 9.10
    • 11 Nodes im System, welche auf der Startseite erscheinen.

    Für die Startseite werden 14 Hooks aufgerufen (boot, init usw.).

    Der Test ist wie folgt durchgeführt worden: Mittels "ab", wurden 1000 Anfragen hintereinander durchgeführt, und die durchschnittliche Antwortzeit gemessen, dabei wurden bei jedem Testdurchlauf mehr und mehr Module aktiviert (10 bis 320).

    Hier mal die Resultate. Die Y-Achse ist die Antwortzeit in Milisekunden, die X-Achse die Anzahl an aktivierten Modulen, wobei jede Kurve einer anderen Art von Modulen entspricht.

    Empty Modules: Ein leeres Modul, kein Hook, nichts, lediglich "<?php" ist drin. Im Grundzustand braucht ein Seitenaufruf 25 ms, bei 100 leeren Modulen bereits 31 ms (Zunahme um 23%) und dies wohlgemerkt, obwohl überhaupt keine zusätzliche Funktionalität hinzugekommen ist.

    Simple 1000x Loop: Gleiches Szenario, wie vorher, aber diesmal ist der hook_init in jedem Modul implementiert, welcher einen einfachen Loop beinhaltet:

    $t=0;for($j=0;$j<1000;$j++){$t=$t*2;}

    Wie zu erwarten, steigt die Kurve linear, jedoch viel steiler, als vorher. Nach dem Einschalten von 100 Modulen, verlängert sich die Antwortzeit der Seite um 90%

    Simple 1000x Loop, with Comment: Jedes Modul, wurde mit Kommentar aufgefüllt (die Testmodules waren danach ca. 23 KB gross). In der Antwortzeit war dadurch keine allzugrosse Veränderung feststellbar. Interessanterweise, waren die Antwortzeiten sogar eher ein bisschen darunter. Keine Ahnung warum.

    Simple 1000x Loop, with Comment (no APC): Interessehalber, habe ich mal den APC abgeschalten. Die Antwortzeiten sind um ein vielfaches höher! Ist ja auch klar, denn die ganzen zusätzlichen Dateien müssen jedes Mal frisch geladen werden. Daher: Grosse Installationen brauchen unbedingt einen OPcode cache!!

    Fazit

    Ich bin mir ehrlich gesagt noch nicht ganz sicher, was diese Grafik aussagen soll, hier aber schon mal meine ersten Gedanken.

    Jedes Modul kostet Ressourcen, auch wenn es noch so klein ist. Ich bin jedoch der Meinung, dass die "Grundkosten" relativ gering sind, wenn wir von einer einfachen Seite ausgehen, sprich, wenn ich ein Modul habe, welches lediglich dem Administrator etwas bringt, dann ist die Performanceeinbusse auf Besucherseite relativ gering, aber nicht vernachlässigbar!

    Diese steigen natürlich weiter an, wenn es Module gibt, welche zusätzliche Hooks bereitstellen, denn jeder Hook, der "abgefeuert" wird, ist eine zusätzliche Belastung fürs System: Views zum Beispiel stellt zusätzliche Hooks zur Verfügung. Im aktuellen Testsetup werden 14 Hooks aufgerufen, um die Seite zu bauen. Interessant wäre zu wissen, wie sich die Antwortzeiten verhalten, wenn 28 Hooks aufgerufen werden.

    Alles in Allem: Je weniger Module desto schneller die Seite, je weniger komplex die Funktionen, desto schneller die Seite.

    APC (oder sonst ein OPcode cache) ist ein Muss!!

  • DrupalCon – Flexible Layouts und Design mit Display Suite

    Ein paar Gedanken aus der Display Suite Session. Display Suite.

    Display Suite

    In komplexen Seiten mit vielen Teaser musste man bis anhin immer eines an .tpl Files anlegen. Es wurde eigentlich relativ schnell sehr unübersichtlich. Ich kenne das Problem auf jeden Fall sehr gut.

    Die Display Suite scheint die Lösung dafür zu sein! Der erste Eindruck ist extrem gut. Also, was macht es (Voraussetzung ist, dass Display Suite und Node Display angeschalten sind) :

    Unter admin/ds/layout ist eine Liste mit zu finden mit den verschiedenen Ansichten eines Nodes (Vollständiger Node, Teaser, RSS usw.) Jetzt "edit" klicken und dann können die verschiedenen Elemente in entsprechende Regionen gruppiert werden (welche dann natürlich via CSS entsprechend angepasst werden können). Vom Interface sieht es ähnlich aus, wie das Blockinterface.

    Jetzt können die entsprechenden Layouts angepasst werden. Soweit so gut. Das coole ist jedoch, dass eigene sog. "Build Modes" hinzugefügt werden können, z.B. Frontpage. Dort kann ich dann wie gesagt wiederum die Nodefelder gruppieren. Jetzt kann ich die Views auf der Startseite nehmen und als Anzeige Modus "Display Suite" wählen und dann dort entsprechend Frontpage auswählen … schon werden die gewünschten Felder angezeigt.

    Ich könnte jetzt also für verschieden Views verschiedene Build Modes anlegen, ohne dass ich dafür ein .tpl anlegen müsste. Das coole daran ist, dass es sich dann auch extrem schnell ändern lässt, bzw. wenn neue Inhaltstypen hinzukommen, lassen die sich sehr schnell in das entsprechende Layout einpassen.

    Die folgenden hooks stehen zur Verfügung.

    • hook_ds_api()
    • hook_ds_fields()
    • hook_content_build_modes()
    • hook_ds_fields_alter()
    • hook_ds_buildmodes_alter()
    • hook_ds_default_settings() -> feature support
    • ds_build_fields_and_regions()
    • ds_render_content()

    Panels

    Bisher habe ich immer ein wenig Respekt vor Panels gehabt und noch nicht wirklich den passenden Usecase gefunden. Die paar Sachen, welche ich jedoch hier gesehen habe, sprechen schon für etwas entsprechendes und zwar vor allem aus dem Grund, dass sich Layouts viel flexibler ändern können, besonders, wenn man eigene Layouts anlegt.

    Mein Fazit ist auf jeden Fall, dass ich für zukünftige Projekt mehr Abklärungen im Voraus investieren werde, um den Einsatz von solchen Modulen zu überprüfen. Ich bin nachwievor der Meinung, dass Panels (und wohl auch DS) nicht die Lösung zu allem ist, aber doch zu einigen… und wichtig ist einfach nur, die richtigen Einsatzgebiete zu erkennen und es dann richtig einzusetzen.

    Offene Fragen:

    • Können Layouts angelegt werden mit eigenen Regions?
  • Drupal 7 – Body Tag modifzieren

    Da hat sich doch einiges ein wenig verändert mit Drupal 7. Wer etwas in der Bodyklasse oder im Head Bereich des Htmls verändern möchte, der sucht unter preprocess_page leider vergebens:

    In Drupal 7 gibt es neu noch ein html.tpl.php, wo diese ganzen Dinge drin sind, was eigentlich auch sind macht. somit kann man über preprocess_html die Daten verändern. Das folgende kleine Beispiel würde der Bodyklasse eine ID zuordnen:

    function geocaching_preprocess_html(&amp;$vars) {  
        $vars['attributes_array'] = array(
            'id' => 'test',
        );
    }
    

    `

    Ist trivial, man muss es halt einfach wissen. Das standard html.tpl.php befindet sich übrigens im system Modul.