Frust oder Vorfreude?

Diskussionen um Drupal 8

“Wandlung ist notwendig wie die Erneuerung der Blätter im Frühling”.
Vincent van Gogh, Briefe

In seinem Artikel im Web Magazin stellte Eric Herrmann im August wachsenden Unmut gegenüber Drupal 8 fest – Tendenzen innerhalb der Drupal Community, die mir so gar nicht bewusst waren. Er stützt sich dabei auf Postings der Drupal Core-Entwickler quicksketch (AKA Nathan Haug) und Dave Reid in der Drupal 8 Issue Queue, in denen die beiden mit deutlich frustrierten Worten ankündigen, sich als Drupal Core-Entwickler zurückzuziehen. Nun sind die beiden nicht irgendwer, sondern als Mitarbeiter bei zwei der wohl bedeutendsten US-Firmen in Sachen Drupal – Lullabot und Palantir – und als langjährige Contributer bzw. Lead Maintainer verschiedenster Projekte durchaus gewichtige Personen innerhalb der Drupal Community.

Nathan Haug hat im Zuge dieser Entwicklung das Projekt "Backdrop" als einen Fork (eine Abspaltung) von Drupal 7 zur Weiterentwicklung dieser Version eröffnet.

Doch was sind nun die gravierenden Änderungen, die altgediente Mitglieder der Community dazu bringen, von der aktuellen Entwicklung abzuspringen und Parallelprojekte zu starten? Als Entwickler springen einem zuerst drei Dinge ins Auge:

• Die neue Template-Engine: Twig
• Symfony 2, das objektorientierte PHP-Framework.
• Objektorientierte Programmierung nun obligatorisch bei der Modulentwicklung

Das Symfony 2 Framework

Die Entscheidung für Symfony fiel, weil Drupal einerseits einen “inselhaften Status” in der PHP-Landschaft einnimmt und durch die Kollaboration mit anderen (Open Source) PHP-Projekten nur profitieren kann, andererseits, weil es ganz klar ineffizient ist, an allen möglichen Stellen eigene Lösungen zu entwickeln, wenn es ohnehin schon verlässliche, offene Frameworks wie eben Symfony gibt, die das Erarbeiten einer Vielzahl von Funktionalitäten überflüssig macht.

Die Integration von Symfony in Drupal 8 ist aber nicht nur durch den Wunsch motiviert, mit anderen PHP-Frameworks und -Standards zusammenzuwachsen und dadurch Synergieeffekte zu nutzen. Symfony soll in Drupal 8 hauptsächlich einen ganz konkreten Zweck erfüllen: Drupal “out of the box” für Web Services bereit machen. Dries Buytaert hat die Überlegungen dazu und die Entscheidung für Symfony 2 in seinem Artikel The future is a RESTful Drupal erläutert. Die Bedeutung dieses Schrittes ist weitreichend: als Framework betrachtet ist Drupal 8 noch mehr als seine Vorgängerversionen nicht “nur ein CMS” – es ist ein Framework, ein Application Server, den man unter anderem auch als leistungsfähiges CMS benutzen kann.

Wir bei Tojio finden diese Entwicklung sehr spannend. Denn bereits vor einigen Jahren waren genau diese Möglichkeiten (u.a.) maßgeblich für unsere Entscheidung für Drupal. Wir haben an etlichen Web-Applikationen mit Server/Client-Architekturen gearbeitet. Immer gab es dabei die Anforderung, dass Inhalte und Daten der Applikationen a) von Redakteuren ohne technischen Hintergrund bearbeitet werden mussten und b) diese Daten nahtlos auch in die restliche Website integriert sind - Drupal war schon damals ein guter Kandidat für so etwas und wird es immer mehr.

Objektorientierte Programmierung in PHP

Objektorientierte Programmierung (OOP) in PHP ist schon seit längerem möglich und viele Module nutzen sie längst. Mit Drupal 8 wird sie nun allerdings zwingend erforderlich. Es gibt nicht wenige Leute, die davor warnen, dass damit etliche Drupal-Entwickler verprellt werden, die sich mit OOP nicht auskennen. Dieser Punkt ist nicht leicht zu entkräften, denn das objektorientierte Denken zu erlernen und konsequent im Code umzusetzen, ist keine leichte Aufgabe – vor allem, wenn man zuvor jahrelang prozedural in PHP programmiert hat.

Ich selbst habe während meiner Zeit an der Uni OOP von der Pike auf mit Java gelernt. Mein erster Kontakt mit PHP(4) außerhalb des Elfenbeinturms war... gruselig. Die Sprache mutete vollkommen steinzeitlich an, war voller Inkonsistenzen und die mühsam erworbenen OOP-Fertigkeiten konnte ich wieder über Bord werfen, weil sie dort nichts taugten. Insofern ist mir klar, wie hart der Übergang zu einem völlig anderen Programmier-Paradigma ist.

In der Zwischenzeit (seit PHP5) ist es nun möglich, auch in dieser Sprache objektorientiert zu programmieren (oder wenigstens Objekte zu nutzen). Das ist ein sehr großes Plus hinsichtlich der Wiederwendbarkeit und Wartbarkeit von Code und durch die Kapselung in Objekte werden auch etliche Fehlerquellen eingegrenzt. OOP-Techniken zu erlernen und einzusetzen lohnt sich, auch wenn es Mühe und Zeit kostet!

Twig - die neue Template Engine

Twig ist die neue Template Engine in Drupal 8. Der Umbruch von PHPTemplate hin zu Twig enstand im Hinblick auf Webdesigner und Themer, um das Arbeiten mit Templates sicherer und einfacher zu machen:

We hand themers a loaded gun and tell them to hammer in a nail with it. Oh and be careful!
John Albin, auf der DrupalCon Denver

Das Problem mit PHPTemplate als Template Engine ist, dass in Templates beliebiger PHP-Code ausgeführt werden kann. Nun ist es zwar allgemeine Best Practice, in Template-Dateien eben keinen Code auszuführen, alle Verarbeitungslogik in entsprechende Präprozessor-Funktionen zu verlagern und an dieser Stelle nur Variablen im Template auszugeben. Doch allein die Möglichkeit, dort beliebigen Code auszuführen birgt ein ernstes Sicherheitsrisko. Darüber hinaus stellt es auch unnötige, potenzielle Fehlerquellen dar. So soll Twig neben höherer Geschwindigkeit und Sicherheit auch Webdesignern und Themern das Leben leichter machen.

Wozu also nun die Aufregung?

Drupal 8 hat viele Diskussionen entfacht, Gemüter erhitzt und Befürchtungen geschürt – hauptsächlich wegen der einschneidenden Änderungen wie der Integration von Symfony und OOP. Aber ich denke, jeder Entwickler oder auch Designer kennt das Phänomen: ein Projekt wächst über die Jahre, die Anforderungen ändern sich. Irgendwann kommt der Moment, in dem man den aktuellen Status evaluiert, die Lehren der Vergangenheit betrachtet und mit Sicherheit auch neue Ideen hat, wie das Projekt besser gemacht werden könnte. Dann ist es unter Umständen eine zukunftsträchtige Investition, das Projekt von Grund auf neu zu implementieren.

It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.
Dries Buytaert, buytaert.net

Und Recht hat er. Durch das Mitschleppen von Altlasten enststehen keine Innovationen.

Vorschau auf Drupal 8

Letzten Mittwoch hat Dries Buytaert auf der DrupalCon Prague in einer Keynote den aktuellen Stand von Drupal 8 vorgestellt: