Das Wetter am zweiten Tag der Drupalcon war mehr als unfreundlich. Das machte es aber zumindest leicht sich im Convention Center zu verstecken und einer Menge spannender Sessions zu lauschen. Hier der Bericht, was ich daraus mitgenommen habe.

Thriving in a world of change: future-friendly content with Drupal

Ich traue mich fast zu behaupten, dass Karen McGrane’s Keynote mein absoluter Höhepunkt der Drupalcon ist. Zwar liegen noch knapp 2/3 vor mir, die geballte Wahrheit dieser Session wird aber schwer zu toppen sein.

Um es kurz zu machen: Karen erklärte das, was wir bei Zensations seit Jahren vertreten. Das Internet besteht nicht aus Seiten sondern aus Inhalten und diese müssen transportierbar sein. Inhalt muss strikt von der Darstellung getrennt werden und WYSIWYG-Editoren sind eine Metapher aus einer Zeit die längst vergangen ist. Ja, an dieser Stelle bekommt auch Drupal 8 seine (meiner Meinung nach berechtigte) Kritik.

Mehr möchte ich an dieser Stelle auch nicht dazu sagen, da ich mir nicht anmaßen will Karens Worte vollständig wiederzugeben. Seht euch einfach dringend die Aufzeichnung an.

zur Aufzeichnung

What’s new in Drush 6

Nach dem sehr konzeptionellen Tageseinstieg musste ein technisch, praktischer Gegenpol her und „What’s new in Drush 6“ kam da gerade recht. Die Session rund um Drupal’s Kommandozeileninterface bestand letztendlich nicht nur aus den Neuigkeiten von Version 6, sondern auch aus einem kleinen Best-of-overlooked von Version 5. Laut den Entwicklern ist Drush 6 mit gutem Gewissen einsetzbar. Eine kleine Liste der Dinge die man vielleicht einfach mal ausprobieren sollte:

  • shell aliases: Drush bietet die Möglichkeit Kommandokürzel für häufige benutzte Befehle zu definieren.
  • quick-drupal: Das Kommando zur schnellen Installation einer Website kann jetzt mit Makefiles umgehen. Das bedeutet, man kann mit einem einzigen Befehl eine ganze Distribution laden und testen.
  • site-set: Ermöglicht ein Site-Alias für eine Terminal Session fix zu setzen. Nähere Instruktionen dazu in der Videoaufzeichnung.
  • config-edit: Für jene die schon mit Drupal 8 herumspielen: Drush 6 bietet ein Kommando eine Konfigurationsdatei im Editor zu laden und beim Speichern direkt ins laufende System einzuspeisen. Könnte mir vorstellen, dass man das auch mit einem File-Watcher kombinieren könnte. Klingt sehr praktisch.
  • Roles & Permissions lassen sich in der aktuellsten Version komplett von der Kommandozeile steuern.
  • Drush Make wurde um ein paar kleine Features erweitert. So ist es zum Beispiel möglich, anstatt eines Drupal-Cores direkt eine Distribution zu laden und um eigene Module zu erweitern. Und es ist nun möglich lokal gespeicherte Patches anzuwenden.
  • Ausgabeformate: Drush 6 kann den Output jedes Kommandos in diverse Formate wie JSON, XML oder CSV umwandeln, womit es sich besser in komplexeren Skripten integrieren lässt.

Das war nur ein Auszug der Features, die mir am wichtigsten erschienen. Wenn man mit Drush arbeitet zahlt es sich aus die ganze Aufzeichnung der Session anzusehen.

zur Aufzeichnung

Planänderungen

Laut Plan wollte ich den Sessions „Mistakes agencies make“ und „SASS – OO’S’CSS with extends and eilend placeholders“ beiwohnen, das habe ich jedoch kurzerhand verworfen, als sich zwei BoF’s (Birds of a Feather – informelle Diskussionen in Kleingruppen) formierten denen ich mich nicht entziehen konnte.

WYSIWYM – What you see is what you mean

Angestachelt durch die Keynote des Tages wurde darüber gesprochen, wie man die Content Editing Experience verbessern könnte. Meiner Meinung nach ging die Diskussion leider ein wenig in die falsche Richtung. Es wurde lang und breit überlegt wie es möglich wäre den visuellen Ansatz eines WYSIWYG-Editors beizubehalten und über komplexe Algorithmen zu erraten, welche semantische Bedeutung die Formatierung haben könnte. Anstatt eine Lösung zu suchen, wie man ein semantisches Eingabesystem erschaffen kann, dass nicht über die fehler- und verlustbehaftete Abstraktion der visuellen Markierung funktioniert. Man ging – auf gut österreichisch – mit der Kirche ums Kreuz.

Omega – Where are we heading

Die Diskussion war dazu gedacht herauszufinden, wie die Leute mit der neuen Version des beliebten Base Themes Omega zurechtkommen, mutierte an irgendeinem Punkt aber zu einer Aufklärungsstunde was es mit SASS eigentlich auf sich hat. Etwas das viele scheinbar noch nicht wissen, und was eventuell eine eigene Session auf der Drupalcon verdient hätte.

Using Twig: The new template engine in Drupal 8

Eine der großen und ungeduldigst erwarteten neuen Features von Drupal 8 ist die Integration der Template Engine Twig. Ein paar Gründe warum das so wichtig ist:

  • Konsistenz: (Fast) das komplette Markup von Drupal wird über ein einheitliches System generiert, statt von einem undurchsichtigen Haufen von theme-Funktionen und Templatedateien.
  • Einfachheit: Man muss kein Programmierer sein, um mit Twig Templates umgehen zu können. Und sie verhalten sich ähnlich wie andere populäre Templatesysteme wie Smarty oder Handlebars was einen Einstieg in Drupal Theming empfindlich erleichtern sollte.
  • Sicherheit: Mit Twig wird es fast unmöglich unabsichtlich Sicherheitslücken im Theme zu produzieren. Sämtliche Ausgabe wird von Haus aus sanitized, also auf potentiell gefährlichen Code überprüft.
  • Partial Overrides: Innerhalb eines Templates ist es möglich Sub-Blöcke zu definieren die dann separat überladen werden können, ohne wie bisher die komplette Templatedatei duplizieren zu müssen. Meiner Meinung nach DAS Killer-Feature von Twig.

Das klingt alles zu schön um wahr zu sein und die Medaille hat auch eine Kehrseite: Es ist sehr, sehr, sehr viel Arbeit. Um Twig sicher im Drupal 8 Core behalten zu können musste das Ziel ein wenig angepasst werden. Anstatt den gesamten Core-Output auf Twig umzustellen, werden nur vorhandene *.tpl.php Dateien umgewandelt, theme-Funktionen jedoch bleiben wie sie sind. Man hat jedoch die Möglichkeit sie im eigenen Theme mit Twig zu überladen. Eine sinnvolle Notlösung, die den Vorteil der Konsistenz jedoch schmälert. Ein Problem, das wir in Form eines Base Themes (ja Omega, ich sehe in deine Richtung) auch ausserhalb von Core in Angriff nehmen könnten.

zur Aufzeichnung

The Zen of HTML prototyping & designing in the browser

Der Vortrag von Josh Riggs vom Lullabot Team hat mich sehr positiv überrascht. Hauptsächlich weil der Titel etwas irreführend war. Oder ich ihn falsch verstanden habe … wie auch immer. Bei Designing in the Browser dachte ich an den Ansatz eine Website ohne Zuhilfenahme von statischen Photoshop-Grafiken zu layouten und designen. Was ich zu gleichen Teilen für erstrebenswert, theoretisch und unrealistisch halte.

Stattdessen wurde aber nähergebracht warum statische Mockups nicht sinnvoll sind und welche Möglichkeiten es gibt schnell und einfach und „lebendige“ HTML-Dummies zu erstellen, die Umstände wie Klickpfade und Darstellung auf verschiedenen Screens besser illustrieren. Was letztendlich zu einfacherer und effizienterer Kommunikation während der Prototyping Phase führt. Ich werde den Ansatz auf jeden Fall testen.

zur Aufzeichung

Work hard, party hard!

Nach Ende der Sessions überfielen wir kurz den Stand von Jetbrains, den Entwicklern der allseits beliebten IDE PHPStorm, um unserem Wunsch nach bestimmten Features oder Bugfixes ein wenig Nachdruck zu verleihen. Statt Antworten gab man uns T-Shirts und JoJo’s – brillianter Schachzug.

Abgeschlossen wurde der Abend wie üblich bei einer Party der vielen ortsansässigen Drupal-Companies. Diesmal auf Kosten von Pantheon – wir danken für Wein, Weib und Gesang!