Menu UI verbessern

Problematik: Das Menusystem ist unvollkommen, bzw. diverse Module müssen eingesetzt und an verschiedenen Stellen konfiguriert werden, um die gewünschte Funktionalität zu erreichen. Im Konkreten bereiten folgende Usecases Probleme:

  • Views mit Argumenten als Toplevel URL. Z.B: www.bsp.ch/politik und www.bsp.ch/leute. Dafür müssen zwei Views angelegt werden, obwohl 1 Views mit Taxonomy Argumenten vollkommen ausreichend wäre.
  • Welcher-Menu-Punkt-ist-aktive-Problematik. Über das Modul “Menu Trails” ist das grundsätzlich möglich, setzt jedoch voraus, dass eine gewisse Struktur vorhanden ist (z.B. die Taxonomy): Führt dazu, dass jedoch Menu und Taxonomy doppelt gepflegt werden.

Grundsätzlich: Das Menusystem dient als zentrales Element um die Inhalts-/ Seitenstruktur zu verwalten. Daher wird als GUI das standard Menu Interface als Ausgangslage dienen. Das folgende Mockup soll zur Illustration dienen.

[not available anymore]

Ausser Pfad und Titel sind alle Angaben optional. Im folgenden werden die optionalen Elemente kurz erläutert:

Views: Es kann eine Views gewählt werden, welche unter dem gewählten Pfad ausgegeben wird. Je nach Views können entsprechende Argumente gewählt werden. Damit kann z.B. unter dem Pfad “leben” und unter dem Pfad “people” die gleiche Views (jedoch mit unterschiedlichen Argumenten) eingesetzt werden. Über hook_menu_alter wird dies durchgeführt.

Key/Value: Das Standardverhalten kann übersteuert werden. Ein klassischer Fall wäre eine eigene Callback Function. Dafür wird als Key “Callback” eingegeben und der Value ist z.B. hallowelt(1, “Weri”). Über hook_menu_alter, wird hier der entsprechende Eintrag gesetzt. Weitere Mögliche Anwendung wäre das mitgeben von globalen Parameter (z.B. die Seitenfarbe, Menu Icon usw.). Wie das genau in der Praxis eingesetzt wird muss sich noch zeigen.

Taxonomy: Standardmässig wird ein Taxonomyeintrag gemacht. Das Vokabular heisst gleich wie das Menu. Jeder Menupunkt entspricht einem Term. Zusätzlich wird die Termid und die Menu Id verknüpft, so dass die Verbindung eindeutig vorhanden ist. Ein Node kann dann einem Term hinzugefügt werden. Grund dahinter: Sicherstellen, dass der richtige Menupunkt aktiv ist, wenn ein Node betrachtet wird.

Drupal Rules – Zeitbasiertes publizieren

Ich habe hier eine Rules zu bieten, welche beliebige Inhalte zeitgesteuert veröffentlicht und wieder zurückzieht. Dazu gibt es auch das Scheduler Modul, dieses hat jedoch einen gewichtigen Nachteil: Wenn ich jetzt einen Inhalt schreiben und diesen erst in 2 Wochen veröffentlichen will, so klappt das. Habe ich jedoch ein Feed, welches nach Zeit sortiert ist (z.B. node created), dann wird dieser Artikel nie erscheinen.

Voraussetzungen für die Rules:

  • CCK Feld: field_publish_date (am Besten ein Datetime Feld)
  • CCK Feld: field_unpublish_date (am Besten ein Datetime Feld)
  • Inhaltstyp “article”

Die folgenden Regeln sind enthalten.

Triggered Rules:

  • Schedule publishing by CCK field (Update). Ein Node vom Typ “article” wird editiert und dabei ein Scheduling Datum gesetzt. Der Node muss auf unveröffentlicht gesetzt werden und wird beim Speichern “gescheduled”.
  • Schedule publishing by CCK Field (insert). Ein Node vom Typ “article” wird neu erstellt und mit einem Scheduling Datum versehen. Published Flag muss auch hier auf False sein. Node wird “gescheduled”.
  • Set correct publishing date. Ein Node vom Typ “article” wird normal (nicht zeitgesteuert) veröffentlicht. Dabei wird das Feld “field_publish_date” auf das aktuelle Datum gesetzt.
  • Schedule unpublishing by CCK field: Ein Node vom Typ “article” wird zeitgesteuert zurückgezogen.

Rule Sets:

  • Publish content {Scheduler}. Scheduler, welcher einen Node zu einem bestimmten Zeitpunkt veröffentlichen.
  • Unpublish content {Scheduler}. Scheduler, welcher einen Node zu einem bestimmten Zeitpunkt zurückzieht.

Natürlich können/müssen die Regeln den örtlichen Gegebenheiten angepasst werden. Besonders der Inhaltstyp muss entsprechend angepasst werden.

Zudem müssen die Views so angepasst werden, dass das Sortierdatum nicht mehr Node created oder die Node Id ist, sondern das field_publish_date.

Noch eine kleine Anmerkung: Diese Rules habe ich nicht auf einer produktiven Site im Einsatz, sondern dienten mir lediglich zu ausbildungszwecken, werden jedoch sicher im nächsten Projekt drin sein. Feedback und Verbesserungen sind stets erwünscht.

Das Drupal Rules Modul

Eigentlich habe ich das Rules Modul schon lange gekannt, aber irgendwie aus irgend einem Grund habe ich es nie richtig eingesetzt. Dabei gäbe es extrem viele Einsatzmöglichkeiten:

  • Zeitgesteuertes Publizieren von Artikeln (ja es gibt den Scheduler, aber dann gibt es halt gewisse Einschränkungen)
  • Workflows abbilden (ja es gibt das Workflow Modul, aber dann gibt es halt gewisse Einschränkungen)
  • Irgendwelche Reaktionen auf Events (Status verändern usw.)

Ich bin noch ein wenig am Herumprobieren, wie und wo man es am Besten einsetzt, aber bei meinem letzten Projekt, hätte ich einen klassischen Fall für das Rules Modul gehabt. Jetzt ist es halt mit einer eigenen Action und ein paar Zeilen Code gelöst… obwohl das Rules Modul so oder so installiert ist.

Die “Triggered Rules” sind sehr einfach zu verstehen. Die kann man erstellen und dann funktionieren die auch schon. Man gibt ein Trigger an (also ein Event, welches die Rule auslöst) und dann eine entsprechende Action.

Die Rule Sets sind nicht ganz so einfach. Hier kann ich am Besten ein Screencast empfehlen. Rule Sets haben keinen Trigger, sondern sind einfach Actions, welche ausgeführt werden. Die Rule Sets werden z.B. über VBO oder über normale Triggered Rules angesteuert.

Ich werde sicher hier mal die eine oder andere Rule als Feature posten.

Drupal 7 Alpha 3

Eine Runde weiter. Drupal 7 ist als Alpha 3 Version erhältlich. Unter den Änderungen sind unter anderem:

  • JQuery 1.4.2 und JQuery UI 1.8
  • API Änderung für AJAX Aufrufe
  • IE Bug geflickt, damit IE auch mehr als 31 CSS Stylesheets anzeigt
  • Passwort wurde als plain text gespeichert
  • Diverse Performance und Sicherheitsissues

Die grosse Frage ist ja immer, wann wird Drupal 7 stable sein. Die Antwort ist relativ einfach: Wenn es keine kritischen Issues mehr gibt. Im Moment hat es noch 144 davon.

Zusammenkunft mit Edipress, Amazee und Anolim

Heute hatten wir eine kleine Zusammenkunft mit einem Entwickler von Edipresse, Amazee und Anolim und natürlich wir von Previon. Edipresse hat bereits diverse Projekte mit Drupal umgesetzt (z.B. le Matin). Amazee ist eine grössere Kollaborationsplattform.

Thema war vor allem Drupal und Performance. Eigentlich ging es Querbet durchs Thema: Cloud Hosting mit Amazon, Opcaches, Memcache, InnoDB vs MyIsam, Varnish und Boost. Es war sehr aufschliessreich zu sehen, was andere machen, wo Probleme liegen und vor allem auch wo Know-How vorhanden ist.

Ich bin ja immer noch auf der Suche nach Drupalianern hier in der Region Basel, aber meine Suche war bisher erfolglos. Die Drupal User Gruppe in Zürich ist mir einfach ein wenig zu weit, als dass ich mal einfach so schnell ein Bsüächli abstatten würde.

Drupal Themes – Seven – Review

Seven ist ein herrliches Admin Theme, welches eigentlich ursprünglich für Drupal 7 entwickelt wurde, aber jetzt auch für Drupal 6 verfügbar ist. Ohne einige zusätzliche Module wie z.B. admin_menu,adminteleport, or navigate ist es jedoch nur halb so spassig. Für die ursprüngliche Entwicklung des Themes waren Lisa Reichelt und Mark Boulton verantwortlich. Sie waren damit beauftragt, das User Experience in Drupal 7 angenehmer zu gestalten.

Ursprünglich haben wir als Admin Theme immer Garland eingesetzt. Leider haben sich damit nicht immer alle zurecht gefunden und es ist einfach nicht ganz optimal. In einem neueren Projekt haben wir Seven als Admintheme eingesetzt. Die Redaktore kommen damit viel besser zurecht.

Seven Theme - Übersicht

Besonderheiten

  • Es gibt keine Sidebars links und rechts! Daher nicht erschrecken, wenn man das Theme frisch installiert und dann die Seite ein wenig kurios ausschaut. Einfach alle Blöcke für seven deaktivieren.
  • Lokale Tasks (diese Tabs) werden sehr hübsch dargestellt.
  • Hübsche Fieldsets. Wenn man das Theme auch für die node/add Seiten verwendet, hat man eigentlich sogar das Gefühl, als wären auch komplexe Masken übersichtlich.
  • Da keine Blöcke vorhanden sind, ist die Navigation ohne Zusatzmodule sehr schwierig, mit Admin Menu aktiviert jedoch eine wahre Freude (und wer hat das schon nicht aktiviert).

Themes Seven - Fieldsets

Fazit

Als Admin Theme top, als normales Drupal Theme flop. Am Besten gleich am Anfang in die Drupal Installation nehmen und installieren.

Review – Drupal 6 Performance Tips

Ich habe vor Kurzem das Buch Drupal 6 Performance Tips gelesen, die anfängliche Euphorie hat sich ziemlich schnell gelegt, denn die ersten Kapitel haben überhaupt nichts mit Performance zu tun, sonder wie man eine Drupal 5 Seite zu Drupal 6 migriert. Dann kommen ein paar Seiten darüber wie man Backup macht… Performance? … und wenn schon über Performance, dann geht es am Schnellsten über die Konsole und nicht über phpmyadmin. Phpmyadmin ist extremsten langsam.

Ab der Hälfte des Buches geht es dann endlich los mit Performance, aber auch hier eher dürftig. Es werden nicht wirklich Grundlagen und Konzepte vermittelt, sondern irgend welche Moduleinstellungen erklärt.

Bezüglich der Performance geht es dann eigentlich hauptsächlich um Boost. Ja, Boost ist ein geniales Modul, das sollte sicher jeder mal angeschaut haben, aber könnte man hier nicht einfach die Doku dazu lesen?

Es wird dann noch ein kurzer Blick auf Cacherouter und Authcache geworfen. Wers noch nie gehört hat für den ist es sicher interessant.

Es ist mir nicht ganz klar, für welches Zielpublikum das Buch geschrieben wurde. Ein Laie wird sich eh nicht mit der Thematik beschäftigen, bzw. hat zuwenig Vorkenntnisse und Verständnis (und es ist auch nicht seine Aufgabe, sich um solche Fragen kümmern zu müssen). Für einen Fortgeschrittenen Benutzer ist es meiner Meinung zu wenig tiefgründig.

Ich habe mich die letzten Wochen/Monate immer wieder mit Performancesachen beschäftigt und diverse Module ausprobiert (Authcache, Boost, cacherouter usw.) zudem habe ich diverse Serverseitige Dinge ausprobiert. Darunter unter anderem: Varnish, APC, Memcached und eAccelerator. Von daher war ich ein wenig enttäuscht, denn ich hätte mir doch ein bisschen mehr vom Buch erwartet.

Sicher, wer komplett neu ist und keine Ahnung von den Caching Modulen hat (oder wer seine Seite updaten will… aber hier gibt es sicher bessere Bücher), der wird sicher viel neues entdecken, für alle anderen: es gibt nicht wirklich was Neues im Buch.

Ich habe das Buch in ca 60 Minuten durchgelesen.

Drupal – PHP Performance

Drupal lässt sich auf vielen verschiedenen Ebenen optimieren: Datenbank, Apache, Server, Architektur und PHP Code.

Auf einige Parameter haben wir als Entwickler weniger Einfluss, auf andere mehr. Auf den PHP Code und dessen Qualität haben wir vollen Einfluss. Die Seite “The PHP Benchmark” hat ein paar interessante Tests durchgeführt. Am interessantesten ist der folgende:

Is it worth the effort to calculate the length of the loop in advance?

for ($i=0; $i < $size; $i++)
Im Vergleich zu
for ($i=0; $i < sizeOf($x); $i++)

A loop with 1000 keys with 1 byte values are given

Das Resultat ist ziemlich klar und für jeden verständlich. Fall 2 sollte daher definitiv verbannt werden!

Drupal Best Practice Guidelines – Reviewer gesucht

Das Handbuch kommt langsam aber sicher voran. Damit die Qualität auch entsprechend ist, würde ich mich freuen, wenn es ein paar Reviewer gäbe. Die folgenden Seiten sind eigentlich soweit mal bereit:

Also, hoffe, es gibt ein paar Rückmeldungen. Einfach die Kommentarfunktion zur entsprechenden Seite verwenden.