comm-press: Your Drupal agency in Hamburg, Germany: Consulting, training, programming, service, webdesign and hosting

Erfahrungen DrupalDay Rostock . Roadtrip to Rostock. Der erste Drupal Day in Mecklenburg-Vorpommern.

von Ralf Hendel
am

Gestern morgen sind wir mit sechs Leuten von comm-press über die A20 nach Rostock zum ersten Drupal Day in Mecklenburg-Vorpommern gedüst, wo sich rund 50 Teilnehmer aus Norddeutschland zu einem eintägigen Drupalcamp getroffen haben. Das Ergebnis war ein toller Tag mit gemeinsamen Essen in einem Klub. Einige Teilnehmer haben in Rostock noch übernachtet und sich am nächsten Morgen zum Frühstücksbrunch getroffen.

Die Sessions verteilten sich auf zwei Räume, sodass ich nur über die Hälfte der Sessions etwas schreiben kann...

Node Reference

Nach einer kurzen Eröffnung hielt Ronald seine erste Session zu Node-Referenzen. Seine Session bezog sich nicht nur auf das CCK Feld sondern vielmehr auf Datenmodellierung im allgemeinen in Drupal und die Möglichkeiten, diese über Views verfügbar zu machen.
Er hat Lösungen für häufige Problemstellungen vorgeführt: Wie kann ich beim Editieren eines Eltern-Nodes gleich neue Kinder-Nodes erzeugen, die auf die Elternteile verweisen oder umgekehrt? Er hat einige Module vorgestellt - "Node Reference URL Widget" kannte ich noch gar nicht und muss es mir unbedingt genauer anschauen...

Thematisch passte die Session wunderbar zum anschließenden Panels-Training. Ging es bei Ronalds Vortrag um Datenmodelle allgemein, ging es bei den Panels darum, wie sich diese Node-Beziehungen für Besucher auf der Website gut zugreifbar darstellen lassen.

Panels Training - Theorie und Praxis

Für meine Session bekam ich einen doppelten Zeit-Slot zur Verfügung gestellt. Im wesentlichen habe ich das Panels Training von der Hamburger Drupal Usergroup wiederholt, hatte im Praxisteil aber sehr viel ausführlicher Gelegenheit um tiefer in Views einsteigen zu können. Der gesamte Komplex Panels ergibt ohne Views wenig Sinn. So konnte ich zum einen das Thema Argumenten in Panels sowie die Übergabe der Argumente von Panels an Views detaillierter vorstellen. Zum anderen die Möglichkeiten, mit dynamische Argumenten in der URL zu arbeiten und diese in Views auswerten zu lassen.

Wer die Session noch einmal selbst nachvollziehen möchte, kann sich hier eine vorbereitete Umgebung mit samt der Dokumentation dazu herunter laden.

In der anschließenden Fragerunde wurde nach deutschsprachiger Dokumentation von Panels und Views gefragt. Die beste Dokumentation liegt im Netz immer noch in englisch vor. An Quellen gibt es das >Support Forum auf Drupalcenter sowie den Freenode Drupal Chat im IRC. Ansonsten kann ich allen nur allen nahe legen, Usergroups zu besuchen oder zu gründen. Im direkten Erfahrungsaustausch lassen sich manche Sachen am besten klären. Möglicherweise wurde gestern sogar der Grundstein für eine Warnemünder Gruppe gelegt.

Als Rückmeldung gaben einige Teilnehmer an, sich in Zukunft stärker mit Panels beschäftigen zu wollen. Damit hat sich die Session für mich gelohnt und außerdem noch viel Spaß gemacht...

Vorstellung der Drupal Initiative von Stephan Luckow

Nach der Mittagspause hat Stephan Luckow, erster Vorsitzender des Vereins zur Förderung von Drupal in Deutschland, die Drupal Initiative vorgestellt. Im Kern lautete seine Botschaft: Macht mit, wenn Ihr Euch für Drupal interessiert.
Die persönliche Mitgliedschaft kostet übrigens nur 24,- EUR im Jahr...

Drush - Einführung in die Drupal Shell

Dirks Drush Session war sehr knackig. Drush - die Kurzform von "Drupal Shell" - ermöglicht viele Funktionen von Drupal über eine Kommandozeile ausführen zu können. Die einfachsten Funktionen, wie das Herunterladen und Aktivieren von Modulen sind den meisten sicherlich geläufig. Mit "drush up" lässt sich eine Drupalinstallation auf den neusten Stand von Modulen und Core bringen.

Dass sich mit Drush aber auch ganze Gruppen von Sites verwalten lassen, war mir bis gestern nicht bekannt. Ganze Websites lassen sich mit drush klonen, migrieren und stagen, z.B. um eine Kopie einer Live-Site zu erzeugen, auf der sich Änderungen zunächst testen lassen, bevor sie in die Live-Site ausgerollt werden.

Im Zusammenspiel mit Git, Drush-Make Skripten und Features lässt sich schon ein gutes Maß Deployment in Drupal realisieren. Bis Drupal vollständig exportierbar sein wird, werden wir uns aber auf Drupal 8 gedulden müssen. Immerhin wurde der Grundstein für Drupal 8 letzte Woche auf der DrupalCon in Chicago gelegt. Es lohnt sich, die Entwicklung im Auge zu behalten und gegebenenfalls daran mit zu arbeiten.

Veröffentlichung des Gruppenfotos mit freundlicher Genehmigung von Ingo Jürgensmann.

Was in Drupal Schmerzen bereitet

In seiner zweiten Session hat Ronald seine Top10-Themen in Drupal vorgestellt, die ihm bei der Kalkulation und Umsetzung von Drupal Projekten Schmerzen bereiten und diese zur Diskussion gestellt. An der Diskussion haben sich via Twitter noch Daniel Wehner und Karsten Frohwein aus Chicago beteiligt, die beide für i18n und Deployment votierten.

Newsletter

In der Tat! Kunden sind sich häufig nicht darüber im Klaren, dass für ein Newsletter zunächst ein Konzept erstellt werden muss, wie Inhalte erstellt, aggregiert und verschickt werden. Externe Drittanbieter-Tools bieten zudem den Vorteil, die eigenen Mailserver nicht zu gefährden. Die Versender verschicken die Mails über verteilte Server und kümmern sich darum, dass die Server nicht geblacklistet werden.

Suche

Die Standard-Drupal Suche "ist so, wie sie ist". Sie sortiert Beiträge zwar anhand von Relevanz, kann darüber hinaus aber nicht besonders viel.

Funktionen wie Wortstammsuche ("Stamming"), Berücksichtigung von Ähnlichkeiten, Distanzsuche aufgrund von Geodaten können PHP und MySQL-basierte Systeme technisch bedingt nicht besonders gut leisten. Für komplexe Suchen sind externe Tools wie z.B. Apache Solr besser geeignet. Aus unserer Erfahrung ist es gut vom Kunden ein Gefühl zu erhalten, welchen Stellenwert er der Suche innerhalb des Gesamtprojekts beimisst. Für die Einrichtung insbesondere mehrsprachiger Solr-Suchen können schnell 20 Personentage und mehr zusammen kommen.

Backend

Einige Kunden legen Wert auf ein Backend. Mit Panels lassen sich individuelle Dashboards schnell hinzaubern. Aus unserer Sicht ist nicht sehr problematisch, so lange der Kunde auf dem Umschreiben der üblichen Drupal-Eingabeformulare legt. In diesem Fall lässt sich der Mehraufwand nur Anhand konkreter Mockups und Beschreibung der gewünschten Eingabe-Workflows einschätzen.

WYSIWYG

Auch das ist häufig ein Thema. WYSIWYG Editoren sind geliebt und gehasst. Die Eingabeoberflächen kommen bei komplexen HTML-Strukturen schnell an ihre Grenzen. Aus unseren Erfahrungen stellt sich dies bei anspruchsvollen Projekten weniger als Problem dar. Kunden mit hohem redaktionellen Anspruch legen häufig Wert auf strukturierte Eingabemasken, die eine einheitliche Darstellung der Inhalte für die Besucher sicher stellen.

"Eine Plattform wie XING"

"Wir möchten eine Community haben, die die Vorteile von XING und Facebook vereint aber auch ein bißchen wie Twitter funktioniert. Was kostet das bei Ihnen?"

Solche Anforderungen nehmen wir eher dankbar zur Kenntnis. Ein Kunde, der mit solchen Tasks an uns heran tritt, zeigt uns anschaulich, dass er sich inhaltlich praktisch gar nicht nicht mit den Anforderungen solcher Plattformen auseinander gesetzt hat. Er möchte einfach nur bestehende Konzepte kopieren und für sich nutzen, ohne diese überhaupt substantiell beschreiben zu können.

In der Praxis wird der Kunde die dafür zu leistenden Arbeiten schwerlich wertschätzen können.
Wir erklären solchen Kunden, dass wir auf diese Anforderung nicht anbieten können und bitten den Kunden um die Vorlage eines umsetzbaren Anforderungsprofils.

Viel schwieriger für uns sind "wirre Konzepte", unzusammenhängende Feature-Sammlungen, die keine Vision beinhalten und nicht zu Ende gedacht sind. Hier kann es schwer sein dem Kunden zu vermitteln, dass wir ein Angebot ohne einen vorherigen gemeinsamen Workshop zur Präzisierung und Priorisierung der Anforderungen nicht stellen können.

Import / Export

Das Node-Import Modul eignet sich zum Einlesen komplexer Inhalte nur begrenzt . Besser funktioniert hier feeds.

Datenimport-Tasks bzw. die Einrichtung von Schnittstellen können sehr zeitaufwändig sein, lassen sich aus unseren Erfahrungen aber - so lange die Anforderungen spezifiziert sind - recht genau einschätzen.

Formulare

Spezialformulare für Konfiguratoren, Tarifrechner oder ähnliches.

Auch hier kommt es darauf an, dass die Spezifikationen und Workflows für die Erfassung und Prüfung der Eingaben, gut dokumentiert vorliegen. Aus unseren Erfahrungen greifen hier selten Standardmodule. Meistens führt die Entwicklung ein eigenen Custom-Moduls, dass die Anforderungen auf den Punkt genau umsetzt, am schnellsten zum Ziel.

i18n / Mehrsprachigkeit

Oh - ja! Durch die verschiedenen Konzepte von Drupal mit mehrsprachigen Inhalten verfahren zu können, geht zwar im Prinzip alles, muss bei komplexeren Inhalten in jedem Einzelfall genau beleuchtet und konzipiert werden. Hinzu kommt es, dass einige Module Mehrsprachigkeit fehlerhaft oder gar nicht umsetzen.

Zu Mehrsprachigkeit haben mir erfahrende Drupaler auf anderen Events gesagt, dass sie für jede weitere Sprache pauschal 30% Mehraufwand des Projektes veranschlagen.

Aus unseren Erfahrungen ist der Aufwand tatsächlich sehr schwer einzuschätzen, da man vor Überraschungen nirgends gefeit ist. In Kombination bestimmter Module und Konstellation kann sich die Mehrsprachigkeit als unverhältnismäßíg anstrengend erweisen, die bei Projektplanung schwer vorhersagbar ist.

Deployment

Auch dies ein schmerzbehaftetes Thema. Bei Drupal liegen Konfiguration und Content in der selben Datenbank vor. Sobald ein Projekt die Größe erreicht hat, dass ein "Gefummel" auf dem Live-System ausscheidet, stellt sich die Frage, wie Erweiterungen getestet und in das System ausgerollt werden können. Git, Drush und Features bieten hier gute Ansätze. Mit Features lassen sich Konfigurationsbestandteile in Code unterbringen, der als Modul ausgerollt werden kann. Leider lassen sich bei weitem noch nicht alle Konfigurationen und Inhalte in Drupal exportieren. Die aktuelle Diskussion um Deployment in Drupal 8 zeigen, dass dies einerseits eine große Herausforderung darstellt, Drupal andererseits aber auch in die Enterprise-Liga angekommen ist, in der eine Lösung auf diese Fragen erwartet wird.

Theming IE6/7

Tja, was soll man dazu sagen, wo selbst Microsoft sich bei den Entwicklern für den IE6 entschuldigt und dazu auffordert, diesen Browser nicht mehr zu benutzen...? IE6-Kompatibilität erhöht den Theming-Anteil eines Projekts aus unseren Erfahrungen um 30%.
Immerhin ist dies kein Drupal-Problem sondern betrifft alle Systeme gleichermaßen.

Die Session habe ich als sehr mutig empfunden, da sie die Schwächen bzw. die Hauptbaustellen beleuchtet. Wer den Twitter-Stream aus der Session mitgelesen hat, könnte den Eindruck gewinnen, dass Drupal ein ziemlich furchtbares System sein muss. Drupal besitzt eben nicht nur Licht- sondern auch Schattenseiten.

Die Fragestellungen lassen sich aber auch als Erfolg von Drupal lesen: mit der Größe und Verantwortlichkeit der Projekt verschieben sich die Anforderungen in Richtung Enterprise System.

Tracking

Kurz vor Schluss fand noch eine interessante Session von Jan-Henrik Hampel zum Tracking von Websites statt. Anhand der Google Analytics Statistik konnte ich seine Aussage, dass mittlerweile mehr Besucher über Facebook auf die Seite kommen als über die Google Suche, auch für unsere Seite bestätigen.

Mauschelei bei der Verlosung?

Das Event endete mit einer Verlosung von T-Shirts und verschiedenen Büchern. Bestimmt war es abgekartetes Spiel, dass Stephan Luckow, Präsident der Drupal Initiative,  gleich als erster ein T-Shirt gewonnen hat ;-).

Andreas Doege, einer unserer beiden Auszubildenden hatte das Pech, vorher abreisen zu müssen und seinen Lospreis nicht erhalten konnte. Immerhin hat Alexander noch ein Buch gewonnen...

Bei den XML-Büchern nehmen wir an, dass ein Fachverlag "ganz normale" Romane speziell für Nerds aufgelegt hatt, bei denen die Handlung nicht in Kapiteln und Absätzen strukturiert sondern in XML-Marken ausgezeichnet werden.

Socialising

In der Kneipe hatten wir noch viel Spaß und sind noch bis 23 Uhr dageblieben. Wir haben viele neue Leute kennen gelernt - zum Teil sogar aus Hamburg. Von Dirk haben wir noch Tipps für die Organisiation des Drupal-Campings mit auf den Weg genommen. Gegen halb kamen wir zufrieden aber erschöpft wieder in Hamburg an.

Einen herzlichen Dank an die Veranstalter des Drupal Days. Das habt Ihr toll hinbekomen und wir freuen uns auf das nächste Treffen in 2012!

Einen weiteren Bericht mit vielen Fotos findet Ihr im Blog von Ingo Jürgensmann.