Blog

Hier ein paar interessante Punkte aus den Keynotes von Dries:

• CVS wird durch GIT abgelöst werden
• Mehr Distributionen, damit Drupal auch für kleine Seite attraktiv bleibt/wird
• Drupal als Pusher für das Semantic Web, so dass es vom akademischen Umfeld zu den normalen Benutzern kommt.
• Grosse Firmen starten Drupal zu verwenden:
  • IBM
  • Capgemini
  • Accenture
  • Microsoft (SQL Server soll mit Drupal funktionieren)
• Drupal now powers more than 1% of the web! Dem Acquia Webcrawler zufolge.
• Drupal 8: Usability verbessern, mehr Features für Enterprise Kunden und gleichzeitig besser auf die Low-End Kunden eingehen (durch Distributionen), zusätzlich bessere Staging Unterstützung.

Drupal ist gesund und macht seinen Weg… cool. Das erste Mal, dass ich Dries live gesehen haben. Ist ein guter Präsentierer. Interessant zum Zuhören.

Die Halle hier ist riesig… naja, es müssen auch 3000 Leute reinpassen.

Jeff Eaton. Präsentation war besser als jede Samstag Abend Comedy show. Es ging vor allem um eine Highlevel Sicht auf die Drupal Architektur. Dabei war mir gar nie bewusst, wieviele APIs Drupal Core eigentlich hat:

• Menus
• Database Abstraction
• Session Handling
• Output Filtering
• File Storage
• Localization
• Theming
• Forms & Processing
• Image Manipulation
• Caching
• Batch Processing
• Email
• Module System
• Update System
• XMLRPC
• Unicode Utilities

Alle Module hängen davon ab. Vor dem Einsatz von vielen Modulen überlegen, welches System von Drupal verwendet werden muss, um Funktionalität xyz zu erreichen

Strukturen in Drupal

Drupal kennt keine Strukturen. Alles ist in einem grossen Topf drin. Alle Nodes sind gleichberechtigt. Es gibt viele verschiedene Möglichkeiten in Drupal Inhalt zu strukturieren. Daher: Vor dem Entwickeln überlegen, wie der Inhalt strukturiert werden soll!!!! Ein Screenshot reicht nicht, sondern es müssen Regeln vorhanden sein, welche definieren, welche Kriterien einen Node strukturieren und welche Kriterien bestimmen, wo und wann auf einer Seite ein Node erscheint. Erst dann sollte man sich überlegen, welche Hilfsmittel dazu benötigt werden.

Rollen in einem Drupalteam

• Architect
• Builder (Configuration)
• Developer (Code the custom bits)
• Designer
• Themer
• Migration Mule

Verschiedene Personen können verschiedene Rollen haben.

Nach einigen Tagen Ferien in den Vereinigten Staaten, bin ich in San Francisco gestrandet. Wahrscheinlich werde ich einer der wenigen Europäischen Drupalianern hier an der Drupalcon sein. Tut mir leid für alle anderen… und ist natürlich ein Ansporn für mich, ein paar gute Blogeinträge zu schreiben.

In den kommenden drei Tagen wird hier im Blog auf jeden Fall wieder einiges mehr laufen…

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.

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.

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.

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,admin, teleport, 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.

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).

Fazit

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

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 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!