BeamMachine ist derzeit eine native Entwicklung, soll heißen, fast vollständig selbst gebaut. Nur der Presentation-Layer („Präsentations-Schicht“), also die Ausgabe der einzelnen Seiten, geschieht per Smarty. Das ist ein Template-System mit toller Caching-Unterstützung und sehr empfehlenswert.

Neben BeamMachine laufen bei uns gerade ein paar Drupal-Installationen und weitere werden entwickelt. Gerade während der Entwicklung fühle ich mich manchmal regelrecht in der Drupal-Hölle. Was meine ich damit? In ein paar Punkten möchte ich die großen Nachteile der aktuellen Drupal-Version 7 aufführen, um Einsteigern einen Überblick über die Risiken und Probleme dieses eigentlich sehr mächtigen und umfangreichen CMS zu bieten. Im Übrigen sind diese Probleme nicht auf Drupal 7 beschränkt, sondern waren auch schon bei Version 6 gegenwärtig und werden auch bei 8 noch nicht vollständig ausgeräumt sein – so lehrt es uns jedenfalls die Erfahrung.

Nodes, Kommentare, Entities

Content in Drupal ist entweder eine Node, ein Kommentar oder das, was ein Modul-Autor sich gerade ausgedacht hat. Mit Drupal 7 steht den Modul-Entwicklern die Entity-API bereit, die alle Inhalte auf standardisierte Weise anderen Komponenten verfügbar macht. Entities und Fields (ehemals das CCK) versprechen deutliche Vorteile, denn nun stehen alle Daten bis zum letzten Feld fast überall zur Verfügung.

Was bis zur siebten Drupal-Version versäumt wurde: es wird noch immer zwischen Comments und Nodes unterschieden. Beide Datentypen werden grundsätzlich unterschiedlich behandelt. Das bedeutet auch, dass viele andere (grundlegende) Module ignorieren, dass Nodes und Kommentare gleichwertiger Content sein können. Flags, Rules, Views… wer eine komplexe Website aufsetzt, muss viele Rules und Flags anlegen. Und er muss es doppelt machen, nämlich für Nodes und Comments getrennt.

Doch es wird noch schlimmer. Die Felder (CCK-Fields) von Kommentaren sind Node-Typ-spezifisch. Soll heißen: wenn ich 20 Content-Types habe und deren Comments alle ein bestimmtes gemeinsames Feld haben, dann muss dieses Feld in allen Content-Types angelegt werden. Was soll es, man hat ja sonst nicht viel zu klicken und Zeit ist eh nicht so kostbar, wie alle behaupten! 😉

Soll heißen: im Prinzip sind Entities ein großer Wurf, allein sie bringen in Drupal 7 kaum eine Verbesserung.

Stable Release bei Drupal…

…heißt, dass ein stabiles Blog (vergleichbar mit WordPress ohne alles) bereits möglich ist. Ich will ja Drupal nicht schlecht machen. So viel kostenloser Leistungsumfang und Code sollte gewürdigt werden. Doch was die Entwickler-Community mit jeder neuen Generation verschweigt ist, dass einfach noch nichts fertig ist.

Diese Erfahrung habe ich bei der Release von Drupal 6 genau so gemacht, wie bei Drupal 7. Letztere ist bereits seit einem Jahr verfügbar. Als Core wohlgemerkt. Und auch da noch teils mit erheblichen Bugs. Und wie sieht es bei den Modulen aus? Schlecht. Selbst heute noch. Die meisten Module sind noch im Beta- oder RC-Status. Sie laufen zwar. Doch versuchen Sie bloß nicht, mehr als ein Blog oder eine private Homepage damit zu bauen, mit Bedarf an etwas krasseren Features.

Meine liebsten Beispiele:

  • Rules: keine Kommentare in den Rules, Actions und Conditions. Das heißt, dass sich die teils komplexen Regelwerke nicht ordentlich dokumentieren lassen. Zudem schlechtes Handling von Variablen-Typen, die sich gerade mal in der Beta umwandeln lassen. Man stößt deshalb ständig an die Grenzen des Machbaren. Dazu gibt es Probleme beim Sortieren und Importieren von Rule-Sets, vermutlich wegen zu intensiver Gültigkeitsprüfung (Import und Speichern scheitert, wenn ungültige Regeln vorliegen – nützliche Fehlermeldungen bleiben aber aus).
  • Flags: vollständige Rules-Integration, wobei – oops – man hat vergessen, Flag-Zähler für Rules verfügbar zu machen. Als einziger Umweg bleibt das manuelle Auszählen mit Loops, was sicher einen riesigen Performance- und Entwicklungs-Nachteil mit sich bringt.

Viele weitere Modules sind einfach noch nicht reif. So verbringe ich momentan viele Stunden damit, verständliche Issues für die Drupal-Community zu formulieren oder die Bugs im Code selbst zu fixen. Letzteres unter dem Risiko, dass meine eigenen Bugfixes später von der Community übergebügelt werden, wenn mal wieder (wie so oft) ein Update kommt. Hoch lebe das lokale SVN, das mir helfen wird, diese später garantiert auftauchenden Probleme zu erkennen und beheben.

I18n …wenn Entwickler sprechen…

Die Lokalisierung (spricht „Übersetzung“) der Drupal-Oberfläche ist sehr weitreichend und umfangreich. Fast alle Textpassagen sind übersetzt. Man merkt aber leider deutlich, dass die Community nicht nur aus erfahrenen Übersetzern oder guten Deutschschülern besteht. Im Gegenteil. Gefühlte 50% der Übersetzungen haben grammatikalische oder orthographische Fehler. Kurzum, man kommt bei keiner deutschen Installation umher, viele Textpassagen anzupassen bzw. zu korrigieren.

Na und?

Genau! Na und, Drupal ist kostenlos, umfangreich, mächtig und es wird immer besser. Das ist schon einmal sicher. Dennoch finde ich es wichtig, dass man sich vor dem Start bzw. dem Umbau eines Projektes in Richtung Drupal intensiv fragt, ob man es leisten kann und will. Und ob es nicht ein anderes CMS gibt, das professioneller und mit weniger Reibungsverlusten angewandt werden kann.

Ich will wirklich nicht meckern, sondern ein bisschen warnen und den Heiligenschein von Drupals Open-Whatever-Grundsätzen liften. Heads-Up ist die Devise. Schauen Sie einfach genau hin und reduzieren Sie eventuell die Ansprüche. Vielleicht ist ein Typo-3 oder der Einsatz einer erfahrenen Drupal-Agentur doch besser, als Ihr eigenes Team zu lange mit Drupal zu binden.

In diesem Sinne

Ihr BeamMachine-Admin