Ich bin am Freitag Abend gemeinsam mit Micha in Essen angekommen und unser erster Programmpunkt (nach Bezug des Zimmers im “Gasthaus Nordstern“) war der “soziale Vorabend” am Veranstaltungsort. Die Zeit habe ich gut genutzt, “alte” Bekannte wieder zu treffen und mit ihnen zu klönen. Von Vorteil war, dass das Unperfekthaus (worüber noch zu schwärmen sein wird) um 23 Uhr schließt und ich so rechtzeitig mein Hotelbett erreichen konnte.

Tag 1

Mein erste Camp-Tag begann mit de Session “Module mit Hilfe von cTools Plugins erweitern” von Ricardo Kelling. Interessante Anregung, für Erweiterungen nicht nur den Hook-Mechanismus zu nutzen, sondern die mit dem cTools-Modul bereitgestellten Plugin-Mechanismus einzusetzen. Das werde ich sicher in Kürze im eigenen Projekt testen.

Dann ging es zur Session “Entities and fields – New core concepts of Drupal 7“ mit Karsten Frohwein. Ein 40-minütiges Plädoyer für den Einsatz von Entities bei der  Drupal-Programmierung: “Es muss nicht immer ein Node sein”. Wer nicht dabei sein konnte und einen Eindruck gewinnen will, wie viel Dynamik in Kars-Ts Session steckt, dem sein ein etwas älterer Drupalcenter Podcast mit ihm zum Nachhören empfohlen ;).

Weiter ging es mit Karstens zweiter Session “Profiling Drupal with devel and xhprof“. Ich benutzte bisher xdebug, um Resourcenfresser in einer Webanwendung zu finden und war entzückt, mit xhprof einen wohl einfacheren/schnelleren Weg zum Profilieren einer Webanwendung gezeigt zu bekommen. Schneller, weil mit xdebug Profilerd-Dateien erzeugt werden, die vom Webserver auf den Desktop und mit einem Programm visualisiert werden. Mit xhprof erledige ich das direkt im Browser, der Profiler liefert seine eigene Website zur Auswertung der Testläufe mit.

Von der Session “Smooth collaboration and deployment using features and git“ von  S. Groetschel hätte ich mir mehr erhofft, als geboten wurde, der Vortrag ging nicht über die Grundlagen der Arbeit mit git und Drupal-Features hinaus. Leider habe ich damit die Session “Schau, Mutti, keine Programmierzeile“ verpasst.

Die Session “Drupal Deployment 2.0“ von Christian Schramm war dagegen ein Gewinn, gerade wegen der Ausblicke auf die Einrichtung eines Continuous Integration Servers und der quasi ständige Test der Webanwendung, was gerade in verteilten Teams  von großem Wert ist.

Dann noch ein letzter Raumwechsel an diesem Tag und die Session “tmgmt Translation Management Tool” von Pascal Crott und Daniel Wehner. Da meine nächsten beiden Projekte die Erstellung einer zweisprachigen Website und Webanwendung sein werden, war diese Session ein Muss. Die Beiden stellten das beim kürzlichen Codesprint entstandene Modul “Translation Management Tool“, welches die Übersetzung von Inhalten einer mehrsprachigen Website revolutionieren soll — durch einen besseren Workflow innerhalb der Anwendung und die Einbindung externer Übersetzungsdienste.

Zum “dienstlichen” Abschluss des ersten Tages gab es für mich noch die Session “Frontend-Entwicklung mit SASS & Compass” von Andreas Dantz. Für mich als Sitebuilder und Backend-lastigem Entwickler war es eher eine Informationsveranstalung, aber die Vorstellung der Präprozessoren für die CSS-Generierung war schon erleuchtend und der Vortrag sehr kurzweilig.

Zum Abtrainieren nach all den Sessions und Drupal-Neuigkeiten gab es ein Drupal Jeopardy, bestens organisiert und moderiert von Mark Engelhardt und  Ronald Krentz. Hochachtung auch für alle Kandidaten, die alles gegeben haben, aber nicht immer mit ihren Antworten richtig lagen. Ich wusste es fast immer besser, aber ich saß ja auch nicht im Rampenlicht und konnte die Fragen mitlesen…

Anschließend noch noch gemeinsames Biertrinken und allgemeines “Sozialisieren”. Schöner Ausklang eines schönen Tages. Um 23 Uhr ging es wieder zurück ins Gasthaus.

Tag 2

Der zweite Tag begann mit der Session “Drupal wird langsam, einige Möglichkeiten zur Verbesserung“ von Benjamin Wenderoth. Man merkte Benjamin gut an, dass er täglich mit dem Thema beschäftigt ist und er bei jeder Frage aus dem Publikum an nur das letzte Projekt denken brauchte. Und mit BOA stellte er einen schwergewichtigen Kandiataen für ein High-Performance-Drupal-Setup (uff!) vor. Wenn ich auch nicht den gesamten Ansatz an den Start bringe, so werde ich ihn mal in einer VirtualBox oder jiffyBox testen und aus dem Setup sicher viel lernen.

Als Vorbereitung auf mein nächsten Projekt gab es als nächste Session “Entity Translation” von Florian Loretan. Florian stellte einen neuen Ansatz zur Übersetzung von Inhalten einer Website vor. Im Gegensatz zur “klassischen” Node-Transalation (zwei Nodes in je einer Sprachversion, die auf einander verweisen) stellte er das mit D7 eingeführte System der Sprachversionen von Feldern innerhalb eines Nodes (besser: eines Entities) vor. Man kann bei jedem Feld definieren, ob es übersetzbar sein soll. Ich arbeite mittlerweile schon damit.

Meine letzte Session war Fredrik Lassens Beitrag “Drupal & node.js: erste Schritte“. Sehr beeindruckend, was mit serverseitigem Javascript so machbar ist, und wie leicht der Einstieg ist, wenn man sich etwas Zeit dafür nimmt. ich suche noch schnell einen schönen Anwendungsfall.

Leider mussten wir pünktlich zur Mittagspause das Camp verlassen und zum Zug. Schnell noch ein Gruppenfoto und ein Brötchen auf den Weg.

Das Camp war für mich ein tolles Erlebnis und ich werde noch einige Zeit brauchen, all das neue Wissen einzusortieren und in die nächsten Projekte einzubauen; Entities und Mehrsprachigkeit 2.0 habe ich schon mal angepackt.

Herzlichen Danke an das Orgateam um Nikolai Schwarz, die sicher hart gearbeitet haben, um das Event so auf die Beine zu stellen. Ihr ward wirklich hervorragende Gastgeber! Und danke an all die Sponsoren, die ein solches Community-Event mit Rundumversorgung erst möglich machen. Und Danke an die tolle Drupal-Community, die eine solche Lehrveranstaltung auch zum Familientreffen macht!

PS: Und ich hatte noch eine kleine Schwärmerei über das Unperfekthaus in Essen angekündigt, die Location für das DrupalCamp. Es ist ein tolles Haus und ein entspannter Veranstaltungsort — habe ich die Rundum-Versorgung erwähnt? Ich hätte gern mehr parallele Tracks gehabt, nur um noch mehr Räume zu sehen ;)

Da ich nicht weiß, wie lange die ursprünglichen Websites noch “am Netz” sind, möchte ich auf dieser Seite alle Ressourcen zusammentragen.

Drush-Session v1.0 in Deutsch

Beim Drupal Day MV im März 2011 hielt ich den Drush-Vortrag zum ersten Mal und in Deutsch.

• Vorstellung der Session auf der DrupalDay-Website
• Drush – Website-Administration leicht gemacht als PDF
• Drush-Website-administrationLeichtGemacht, der Video-Mitschnitt auf archive.org

Drush-Session v2.0 in Englisch

Ich hatte die Session vom Drupal Day MV noch mal für das DrupalCamp in Berlin eingereicht, diesmal in Englisch. Die Gelegenheit habe genutzt, die “Folien” nicht nur ins Englische zu übersetzen, sondern auch inhaltlich zu überarbeiten und mit meinem Wissensstand abzugleichen. Dem Englisch-Kundingen empfehle ich also dieses PDF (aber nicht das Video ;)

• Vorstellung der Session auf der DrupalCamp-Website
• Drush – managing drupal – the easy approach als PDF,
• Drush – managing drupal – the easy approach, der Video-Mitschnitt auf Vimeo.

Damit haben ich (nahezu) alles zu Drush gesagt, für meine nächste Session werde ich mir ein neues Thema suchen. Wenngleich die site aliases mit ihrer Mächtigkeit noch ein paar Blogposts verdient hätten. :)

“Multisite” ist eine raffinierte Funktion, um mehrere Drupal-Websites aus einer Codebasis zu betreiben: Im Webserver werden mehrere Domainnamen auf das selbe Drupal-Installationsvverzeichnis konfiguriert. Beim Seitenaufruf ermittelt Drupal den Domainnamen zum Request, sucht im Ordner sites/ den passenden Ordner mit den Konfigurationsdaten. Wenn es für die gesuchte Domain keinen Ordner gibt, dann wird im Ordner sites/default/ nachgesehen. Die im Konfigurationsordner vorhandene Datei settings.php enthält unter anderem die nötigen Datenbank-Informationen und Drupal liefert mit den in der Datenbank abgelegten Daten schließlich die Webseite aus. Eine detaillierte Beschreibung zu Multisites liefert das Handbuch auf drupal.org sowie die Linkliste am Podcastbeitrag.

Diese Funktion war ein unverzichtbares Hilfsmittel, als Festplattenkapazität auf dem Server kostbar war und FTP die einzige administrative Zugriffsmöglichkeit auf den Server war: Bei der Installation einer neuen Website braucht man nur einen neuen Konfigurationsordner anlegen, die settings.phpdorthin kopieren und anpassen und eine neue Datenbank befüllen. Beim Update eines Moduls kopiert man die von drupal.org heruntergeladene Modulversion per FTP auf den Server und ruft für jede Website die Updatefunktion im Browser auf. Und genau diese Arbeitserleichterng ist das Problem mit Multisites: Nach dem Austauschen der Moduldateien muss man sofort die Datenbank-Updates auf allen Websites durchführen. Das kann natürlich einige Zeit dauern, und so lange sind unter Umständen (bis zu n-1) Websites dieser Multisite-Installation zerbrochen. Und man muss darauf vertrauen, dass das Modul-Update keine der Websites “zerbricht” — also gleich noch testen, was wiederum wieder viel Zeit beansprucht. Und wie geht man vor, wenn nun Eine der Multisites nach dem Update nicht mehr funktioniert? Viel Handbareit und eine erstmal zerbrochene Website bleiben zurück.

Seit rund 3 Jahren betreibe ich (fast) alle meine Drupal-Sites auf Webhostings, bei denen ich mich per ssh auf dem Server einloggen und die Websites administrieren kann. Bei den großen Anbietern bekommt man solch ein Hosting ab ~10 Euro je Monat. Alternativ dazu kann man sich für den Preis auch einen vServer klicken. Ich bin großer uberspace-Fanboy, dort bekommt man ein Webhosting mit ssh-Zugang (und sehr vielem mehr) für den Preis, den mit das Angebot wert ist. Ich folge mittlerweile der Empfehlung der Betreiber und habe für jede Website einen eigenen Uberspace (also ein eigenes Benutzerkonto auf einem der Uberspace-Server), weil auch die E-Mail-Konfiguration per Uberspace erfolgt und ich so jedem Kunden problemlos Ssh-Zugang zu “seinem” Uberspace geben kann.

Nun fragt Ihr vielleicht, wie viel mehr Zeit ich für ein so verteiltes Hosting investieren muss? Deshalb hier noch ein paar Ausführungen dazu. Ich bin bekanntermaßen begeistert von drush, dem Kommandozeilenwerkzeug für Drupal. Natürlich ist drushauf allen Uberspaces installiert. Ich pflege eine Vorlage für ~/.drush auf meinem lokalen Rechner und die wird — zusammen mit weiteren Konfigurationsdateien — in jeden neuen Uberspace kopiert. Aktualisierung des Setups ist auch schnell getan:

cd ~/uberspace_template   
for i in $(uberspaces)   
do
  echo "*** $i ***"
  rsync -var . $i:
done

Das $(uberspaces) habe ich kürzlich beschrieben.

Auf dem Uberspace kann ich nun mit drush schnell ein Backup der Website machen, Module aktualisieren und ein fälliges Update in Sekundenschnelle auf einer Kopie der produktiven Website testen.

drush rsync @live @test   
drush sql-sync @live @test
drush @test up views
# und nun Testen
drush @live bam-backup
drush @live up views

Details dazu und den obligatorischen Hinweis auf environment_indicator.module findet Ihr in dem frühren Blogbeitrag.

Um herauszufinden, welche meiner Drupal-Installationen von einem nötgen Update betroffen sind, läuft dieses Sktipt von meinem lokalen Rechner aus:

for i in $(uberspaces)
do
  echo "*** $i ***"
  ssh $i "find /var/www/virtual/$i -type f -name modulname.module"
done

Um es noch einfacher zu haben, habe ich alle Dateien aliases.drushrc.php vom Server auf meinen lokalen Rechner kopiert und den Namen des Uberspaces als Prefix vorangestellt

for i in $(uberspaces)
do
  echo "*** $i ***"
  scp $i:.drush/aliases.drushrc.php ~/.drush/$i.aliases.drushrc.php 
done

Dann noch die Paramater remote-hostund remote-user in den Aliases ergänzen und ich kann vom lokalen Rechner aus Drush-Kommandos auf dem Uberspace ausführen, ohne mich vorher dort anmelden zu müssen:

drush @uberspacename.live st

Das vergangene halbe Jahr seit meinem Umzug zu uberspace.de mit strengen Separation aller Websites auf eigene Benutzerkonten (Accounts) hat gezeigt, dass dieser Workflow robust ist und mit drush, git, komfortablem Backup auf Systemebene und all den anderen Helferlein keinen Mehraufwand gegenüber einem eigenen Server mit allen Websites unter /var/www bringt. Dafür aber Zuverlässigkeit der Plattform, schnell durchgeführte Drupal-Updates und einen freigestellten Linux-Admin.

Nun bin ich auf Deine Meinung gespannt. Wie administrierst Du Deine Drupal-Sites? Was für Hosting-Pakete favorisierst Du wie passt Dein Provider zu Dir? Und: Nutzt Du noch Multisites und ich habe irgend ein cooles Feature aus den Augen verloren?

Beim Wahl der Hosting-Plattform war mir wichtig, dass die Teilnehmer nach dem Kurs wählen können, ob sie

• die Website weiter kostenlos betreiben ohne sich um Updates kümmern zu müssen,
• einen gewissen Jahresbeitrag bezahlen und dafür einen eigenen Domainnamen bekommen,
• die Website selbst hosten, um mehr Performance und Flexibilität bei der Modul- und Themeauswahl haben (und sich dafür mit der Drupal-Administration beschäftigen müssen).

Mittlerweile bin ich jedoch an dem Punkt angekommen, dass ich diese Kurse nicht weiterführen will. Ich hatte in den Kursen und mit den Menschen immer viel Spaß. Aber zu wenige von ihnen sind letztlich dabei geblieben – zu viele haben sich durch den Kurs gequält, viel Geld und Zeit investiert und trotzdem keine eigene Website. Ich erreiche also permanent mein persönliches Kurzziel nicht.

Ich bin mir dank des positiven Teilnehmerfeedbacks sicher, dass es (nach den vier Jahren) nicht primär an mir als Trainer liegt, den Stoff zu vermitteln. Den Teilnehmern fehlt jedoch neben dem Feierabend-Engagement (30 Abendstunden in ~2 Wochen) die Zeit, sich nochmal ~50 Stunden am heimischen PC an das Website-projekt zu setzen. Und ich habe festgestellt, dass Drupal 7 auch mit all den #d7ux-Erfolgen und Verbesserungen an der Bedienoberfläche zu kompliziert für Neueinsteiger ist.

Als Konsequenz könnte ich im Kurs auf WordPress wechseln, die ja auch ein kostenlose Hosting-Plattform anbieten, welches obigen Auswahlkriterien entspricht. Oder mit Jimdo eine kommerzielle Plattform mit Freemium-Preismodell nutzen. In beiden Fällen wäre es aber nicht mehr mein Kurs, ich will eben mit Drupal arbeiten. Die Option “Website-Baukasten-Software auf dem PC installieren und dann ins Intrnet speichern” kommt für mich gar nicht in Frage.

Im Moment denke ich also darüber nach, den Kurs nicht weiterzuführen. Ich habe noch ein paar Wochen Zeit mich zu entscheiden, aber habe (noch) keine gute Idee, wie ich meine persönlichen Erwartungen, die Leistungsfähigkeit der Teilnehmer und die verfügbaren Software-Alternativen zusammenbringen kann.

Ich habe mir ein kleines Script uberspaces geschrieben, welches mir aus meiner Ssh-Konfigurationsdatei ~/.ssh/config die Liste der Ssh-Host-IDs alle Uberspaces liefert, die ich dann in Shellkommandos nutzen kann. Die Ssh-Host-IDs sind dabei mit Leerzeichen voneinander getrennt.

Beispiel: Gib die Crontabs aller Uberspaces aus

for i in $(uberspaces)
do
  echo "*** $i ***"
  ssh $i "crontab -l"
done

Und noch ein Beispiel: Finde alle Drupal-Installationen in allen Uberspaces, in denen ein bestimmtes Drupal-Modul installiert ist. In diesem Fall — aus aktuellem Anlass — das date.module

for i in $(uberspaces)
do
  echo "*** $i ***"
  ssh $i "find /var/www/virtual/$i -type f -name date.module"
done

Einzige Voraussetzung ist, dass in der Datei ~/.ssh/config für jeden Uberspace ein solcher Eintrag vorhanden ist:

Host myuberspace
  Hostname servername.uberspace.de
  User myuberspace

Der UserName und der Host-Id müssen nicht übereinstimmen, ich habe diese Konvention gewählt. Weitere Konfigurationswerte zu einem Eintrag sollten nicht stören, sie werden einfach ignoriert.

Auf diese Weise kann man leicht der Empfehlung der Ubernauten folgen, und für jede Website einen eigenen Uberspace einrichten, ohne bei der Administration zusätzlich Zeit investieren zu müssen.

Am nächsten Dienstag (17.01.) findet der erste Schweriner Web-Dienstag am 20 Uhr im “Ruderhaus” statt. Beim ersten Treffen steht nach Aussage der Veranstalter das Kennenlernen im Vordergrund, was ja schon mal ein gutes Motiv ist. Ihr könnt Euch im Doodle für das Treffen registrieren.

Zwei Tage später lädt der eBusiness Club in Rostock zur Site-Klinik. Bestimmt auch eine gute Gelegenheit, mit Gleichgesinnten ins Gespräch zu kommen. Beginn ist am 19.01.2012 um 19 Uhr im CoWorking Space Rostock. Ihr könnt Euch bei Xing für das Treffen anmelden.

Ich plane bei beiden Treffen dabei zu sein und freue mich auf zwei spannende Web-Abende. Sehen wir uns?

Das Treffen war mit 10 Teilnehmern (einer davon via Skype) gut besucht. Die Aussicht auf konkretes Drupal-Hacken lockte wohl sehr. Passend zum Jahresauftakt gab es neben den “typischen” Stammtisch-Beköstigungen auch Glühwein und (alkoholfreien) Sekt.

Das erste Thema war gleich ein Gewichtiges: Panels, Views mit Contextual Filters und Node references. Danach ging es dann eher gemütlich mit Smalltalk über passende Module, den besten Weg zum Einbinden von Videos in eine Website, die Hürden beim D7-Upgrade weiter.

Das Format — individuelles Basteln und “nebenbei” Gespräche uber die Hürden beim eigenen Projekt — ist uns alle neu. Und braucht so noch ein paar Male, um sich so zu etablieren, im Wechsel mit unserern klassischen Stammtischen im “Plan B.”. Vielleicht sollten wir solch eine Zusammenkunft aber auch in Ergänzung zum Stammtisch einrichten, als Tagesveranstaltung (wie vor einem Jahr auf Comm-Press-Initiative in Hamburg). Ich würde mich über eine Fortsetzung freuen und bin mal gespannt, wie sich dieses Format weiterentwickelt.

Wir wollen in Anlehnung an die Münchener Drupal-LAN-Parties einen Workshop-Abend im PartMaster-Büro durchführen. So bringt Euer Notebook und Euer Projekte mit. Wir arbeiten und wer eine Frage hat, stellt die in die Runde.

Ich bin mal gespannt, wie groß die Runde wird und wie viele meiner Fragen beantwortet werden. Und gewiss werde ich an dem Abend auf meine Wortzahl der ganzen Restwoche kommen ;)

Nun naht Weihnachten, die Zeit Wünsche zu erfüllen und ich habe mich des Versprechens erinnert. Hier ist der Film! ;)

Deutsche Sprachanpassung in einer DrupalGardens-Website installieren from Dirk Ruediger on Vimeo.

Hier die Kurzzusammenfassung:

• Unter “Modules” das Modul “Locale” aktivieren,
• Unter “Configuration > Region and Languages > Languages” mit dem Knopf “Add Language” die Sprache “German (Deutsch)” hinzufügen und in der Spalte “Default” den Haken bei “Deutsch” setzen,
• Die deutsche Sprachanpassung (Zip-Archiv) von http://niebegeg.net/vhs/ herunterladen und entpacken,
• Unter “Configuration > Region and Languages > Translate interface” im Tab “Import” die gerade entpackte Datei “de.po” hochaden.

Die Organisatoren haben mit “Drupal City Berlin” ein sehr gut organisiertes Event abgeliefert, bei dem alles stimmte: die Räume inkl Drupal-Themings, der Sessions-Mix, die Beköstigung und natürlich die “Betreuung” vor Ort.

Ralf Hendel von Comm-Press hat auch eine sehr gute und ausführliche Einschätzung in seinem Blog geschrieben, auf die ich gern verweisen möchte.

Als persönliches Resümee habe ich all die selbstgesetzten Aufgaben gut “abgearbeitet” und hatte an dem Wochenende viel Spaß, auch mit meiner Session. Die wurde übrigens aufgezeichnet. Sobald das Video veröffentlicht ist, werde ich hier darauf verweisen.

Und schließlich hatte ich mich als “Track Chair” für ein einen kleinen Teil des Vortragsprogramms gemeldet um die Sprecher bei der Durchführung ihrer Sessions zu unterstützen.