Drupal – ein CMS Überblick

Drupal feiert 20 Jahre Entwicklung, Begeisterung und vor allem CMS Community! Warum das Drupal CMS für uns auch weiterhin neben WordPress ein wichtiges und starkes Content Management System bleibt, stellen wir in diesem Artikel vor.

Drupal – ein Überblick

Das beliebte Web Content Management System Drupal basiert auf der Programmiersprache PHP und liegt heute im Versionsstand 10 vor.

Unser Lesetipp dazu: Drupal 10 – Ausblick nach der DrupalCon Prag

Facts & Figures

Dries Buytaert, der Begründer von Drupal, erzählt die Geschichte der Open Source Software in der Keynote der DrupalCon Los Angeles 2015. Im Jahr 2000 wurde Drupal von Dries Buytaert ursprünglich als Forum für ein Studentenwohnheim entwickelt. Das Open Source CMS wurde anschließend zu einer Blog-Software und später zu einem extrem anpassungsfähigen Web Content Management Systeme erweitert.

• Drupal ist unter der GNU General Public License, Version 2 veröffentlicht und damit quellcode-offen (Open Source).
• Seit ca. 2009 trifft sich die Community auf großen Events wie der internationen DrupalCon sowie internationalen und nationalen DrupalCamps bzw. lokalen Usergroups. Die DrupalCons in den USA sind größer als die europäischen und haben rund doppelt so viele Teilnehmer.
• Aufgrund der funktionalen Differenzierung innerhalb der Entwicklung und Vermarktung Drupals gibt es inzwischen themenbezogene Camps wie die Drupal Dev Days, Frontent United, Drupal Business Days oder sogar den Decoupled Dev Days.
• Um die Organisation und Durchführung der DrupalCons, der Bereitstellung und Wartung der Plattform drupal.org sowie die allgemeine Unterstützung der Community kümmert sich die Drupal Association mit Sitz in Portland, Oregon.
• Für deutschsprachige Benutzer gibt es das „DrupalCenter“ als Community-Plattform.
• Traditionell endet jede DrupalCon mit einer „Trivia Night“: Teams von vier bis fünf Personen können mit nützlichem und sinnlosem Wissen rund um Drupal brillieren. Das Foto wurde 2016 auf der DrupalCon New Orleans aufgenommen.

Drupal CMS – alles geht: „There’s a module for that.“

Das Drupal CMS ist modular konzipiert: Mithilfe der rund 40.000 verschiedenen Modulen lassen sich durch den vergleichsweise schlanken Kern (Core) höchst flexible und unterschiedliche Anwendungen bauen. Dies können z.B. Unternehmens-Webseiten, sprich Corporate Websites, Blogs, Online-Magazine bzw. Content-Portale, E-Learning Plattformen, Onlineshops, Intranet-Applikationen sowie alle denkbaren Kombinationen daraus sein.

Diese Universalität Drupals stellt gleichzeitig Stärke und Schwäche dar: Die vielfältigen Anwendungsmöglichkeiten verwässern sein Profil. Damit wird Drupal erklärungsbedürftig für Kunden.

Drupal vs WordPress – Wann wählen wir Drupal und wann WordPress als CMS?

Screenshot CMS Usage Distribution in the Top 1 Million Sites

Die mit Drupal möglichen komplexen Anwendungen hängen mit der oben beschriebenen Modularität zusammen. Drupal ist eine Entwickler-Community: auf 100 Anwender kommen bei Drupal etwa 10 Entwickler, die der Community Module oder Verbesserungen (Patches) zurück geben (Contribution).

Content Creation & Organisation

In Drupal können Sie das Datenmodell – Inhaltstypen, Taxonomien und seit Drupal 7 Entities – komplett über Bedienoberflächen konfigurieren (Site-Building), ohne dass etwas programmiert werden muss. Die Inhalte sind somit quasi lose organisiert. Kontext organisieren Sie über Konzepte wie z.B. „Taxonomien“ und entscheiden damit, welche Inhalte Sie in welchem Zusammenhang ausspielen.

Frontend, Backend & Usability

Bei diesem Content Management System können Sie Inhalte und Konfigurationen aus dem Frontend der Website heraus bearbeiten.

Es gibt kein getrenntes Backend.

Jedoch gibt es administrative Themes, die für Verwaltungsaufgaben optimiert sind und dem Benutzer das Gefühl eines Backends verleihen. Durch die intuitiven Eingabeoberflächen ist der Schulungsaufwand für Redakteure und Site-Builder bei Drupal erheblich geringer als beispielsweise bei TYPO3.

Sicherheit und Long-Term-Support von Drupal

Bei Drupal kümmert sich ein Sicherheitsteam um den aktuellen Core sowie die auf drupal.org veröffentlichten Contrib-Module. Im Falle des Bekanntwerden von Sicherheitslücken schreibt das Security-Team die Maintainer der betreffenden Module an und gibt ihnen eine bestimmte Zeit zum Bereitstellen eines Sicherheitsupdates.

Reagieren die Entwickler nicht rechtzeitig, indem sie ein Update bereitstellen, das das Problem behebt, werden die Module bei Drupal.org depubliziert. Auf der Update-Übersicht innerhalb der betroffenen Installationen erscheint dann eine entsprechende Warnung.

Long-Term-Support (LTS): Die Entwickler-Community von Drupal hat sich darauf festgelegt, stets zwei Hauptversionen von Drupal mit Sicherheitsupdates zu versorgen.

Erst mit Erscheinen der übernächsten Hauptversion endet die Supportphase für die Vorgängerversion.

Drupal SEO: Suchmaschinen-Optimierung

Drupal 8 verwendet den modernen Web-Standard HTML5. Die Erweiterung der erlaubten Auszeichnungselemente (Tags) ermöglicht es z.B. Sektionen zu definieren, die Suchmaschinen mehr Informationen über die Bedeutung der Inhalte vermitteln können. Mit neuen Elementen wie „section“, „nav“, „article“, „header“ und „footer“ können Sie die Strukturierung Ihrer Inhalte verbessern.

Bildern, die Sie innerhalb des Quelltextes mit dem neuen Element „figure“ ausgezeichnet haben, können Sie mit weiteren Text-Informationen wie z.B. Überschrift und Bildunterschrift ausstatten, sodass Ihre Bilder auch in der Google Bildersuche optimal gefunden werden können.

Das Maskottchen Drupals heißt „Druplicon“.
Als Plüschbällchen sind die Druplicons nicht nur bei Kindern sehr beliebt.

Der Entwicklungsprozess von Drupal – die wichtigsten Versionen

Der Weg zur Version 9 verlief innerhalb der Vorgängerversionen über folgende Entwicklungsschritte:

Drupal 5 (2007)

Gegenüber den Vorgängerversionen seit 2001 ist die Installation von Drupal zum Glück 😉 erheblich vereinfacht worden. Mit Version 5 hatte Drupal eines seiner Herausstellungsmerkmale erreicht: Große Teile der Architektur einer Website lassen sich ohne Programmierkenntnisse per Site-Building konfigurieren.

Das Daten-Modell lässt sich per Eingabeoberflächen durch die Installation der drei Modul-Familien „CCK – Content Construction Kit“, „Views“ für Datenbankabfragen und „i18n“ für Mehrsprachigkeit konfigurieren.

Vorher bestanden alle Inhalte (Nodes“ nur aus einem Titel und einem Body-Feld. Mit Hilfe des „Content Construction Kits“ lassen sich alle Inhaltstypen um beliebige weitere Felder erweitern. Referenzierungs-Felder ermöglichen Relationen und Hierarchien zwischen Inhalten. Damit lassen sich auch komplexe Datenmuster im Backend konfigurieren.

Die Abfrage-Engine „Views“ ist eine Bedienoberfläche für Site-Builder, mit der sie Daten ohne Programmierkenntnisse der Datenbanksprache SQL abfragen und auf der Website ausgeben können. Das Modul „Internationalization“ ermöglicht die Übersetzung redaktioneller Inhalte sowie von Texten, die auf der Oberfläche der Website dargestellt werden.

Da sich Site-Building innerhalb eines überschaubaren Zeitaufwands erlernen lässt, ist Drupal im Versionsstand 5 für einen sehr viel größeren Nutzerkreis attraktiv geworden.

In Version 8 sind inzwischen alle drei Module Bestandteil des Core.

Drupal 6 (2008 – 2016)

Für Views wurde eine Hauptversion 2 entwickelt, die Ableitungen von Abfragen für verschiedene Anwendungsfälle ermöglicht. Vorher musste für jede Variante einer Abfrage eine eigene Abfrage erstellt werden. Eigenschaften von Abfragen lassen sich entweder für alle Varianten vererben oder je Variante einzeln übersteuern.

Außerdem ist es nun möglich geworden, Daten nicht nur abzufragen, sondern deren Ausgabe für die Website formatieren zu können.

Innerhalb des bestehenden Regionen-Modells haben Redakteure und Site-Builder im Prinzip nur Zugriff auf Inhalte, die innerhalb der Content-Region des Themes ausgespielt werden. Die Panels und ctools Modul-Familie bricht dieses Konzept auf, indem es das Regionenmodell mit Panels Everywhere transzendiert: Der Site-Builder bekommt das Regionen-Modell grafisch visualisiert dargestellt und kann flexibler entscheiden, welche Inhalte der Website in welchen Regionen ausgespielt werden sollen.

Mit Hilfe von ctool-Plugins lassen sich Sichtbarkeitskriterien definieren, die das herkömmliche Block- und Regionenmodell fundamental erweitern.

Drupal 7 (2011 – 2020)

Am 07. Januar 2011 ist die Hauptversion Drupal 7 erschienen. Das Prinzip von CCK wurde in den Core übernommen und heißt fortan Fields.

Sämtliche redaktionellen Inhalte – Nodes (Seiten), Taxonomien, Benutzer und Kommentare – stellen Ableitungen eines generischen Typs namens Entity dar. Damit lassen sich alle Eigenschaften von Entities vererben bzw. stehen sämtlichen Inhaltsarten zur Verfügung. Die wichtigste Eigenschaft besteht darin, dass sämtliche Entitäts-Typen nun fieldable sind: sie lassen sich auf einheitliche Weise um Felder erweitern. Bis dato war es z.B. für Taxonomien oder Benutzer nur mit Hilfe umständlicher Erweiterungsmodule möglich, diese Datentypen um zusätzliche Eigenschaften zu erweitern.

Die Modulversionen Views 3 und Panels 2 bohren Views um komplexere Abfragen auf und verbessern die Interaktionen zwischen Views und Panels. Kurz vor Ablauf von Drupal 6 gab es noch einen Backport von Views 3 für Drupal 6. Wegen des nahenden Endes wurden jedoch keine Update-Pfade mehr für die Umstellung von Views 2 auf Views 3 entwickelt.

Drupal 8 (2015 – 2020)

Am 19. November 2015 – dem 39. Geburtstag des Gründers Dries Buytaert – wurde Drupal 8 gelauncht. Die Veränderungen bei der Umstellung auf Drupal 8 stellten die bisher größte Zäsur in der Geschichte Drupals dar.

Objektorientierte Programmierung und Teile von Symfony im Core

Die wichtigste Neuerung stellt sicherlich die Einbindung von Teilen des PHP-Frameworks Symfony 2 – bzw. Symfony 3.2 ab Drupal 8.4 – und die damit verbundene Umstellung auf Objekt-orientierte Programmierung (OOP) dar.

Wegen dieser tiefgreifenden Änderungen hat die Entwicklung von Drupal 8 fast fünf Jahre gedauert – annähernd zwei Jahre länger als ursprünglich geplant. Ein Teil der Community hat sich währenddessen von Drupal abgespalten, indem er versucht hat, die modernen Leistungsmerkmale auf Basis prozeduraler Codes unter dem Name Backdrop CMS zu implementieren.

Die Drupal Community hat jedoch geschickt agiert, indem sie Backdrop nicht nur nicht ausgegrenzt, sondern sogar ein Forum auf der DrupalCon geboten hat. Unserer Beobachtung zufolge wechseln die Backdrop-Entwickler nach und nach wieder zu Drupal zurück.

Drupal 8 Core-Initiativen

Mit Drupal 8 hat die Community die Strategie eines (sehr) schlanken Drupal-Kerns verlassen. Die in Drupal 5 eingeführte Mehrsprachigkeit befindet sich inzwischen fest verankert im Core. Damit können Sie sämtliche Inhalte, Textbausteine und Variablen sauber übersetzen. Weitere Contrib-Module wie CCK und Views sind ebenfalls Bestandteil des Core.

Zur Implementierung der einzelnen Themen wie „Configuration Management“, „View in Core“, „Multilingual„, „Mobile“ und einigen mehr wurden separate Initiativen – sozusagen Sub-Projekte – mit eigenen Verantwortlichkeiten gegründet.

Seit Beginn Drupals ist der Kern erstmals so mächtig, dass Sie eine durchschnittlich komplexe Website fast ausschließlich mit Bordmitteln des Core umsetzen können. Bei den Vorgängerversionen war ein Umfang von 50-80 Contrib-Modulen pro Installation durchaus normal.

Teile der Konzepte von Panels haben in das verbesserte Blocksystem Einzug gefunden. Damit hat sich der Bedarf nach Zusatz-Modulen wie Panels erheblich reduziert.

Drupals technische Entwicklungen – ein Schnelldurchlauf

Configuration Management (CMI)

Eine wesentliche Verbesserung stellt der Umgang mit Konfiguration dar. Bei Drupal befinden sich Content und Konfiguration seit jeher zusammen in einer Datenbank. Dies hat zur Folge, dass sich Konfiguration nicht separat vom Content sichern lässt und umgekehrt.

Für die Zusammenarbeit zwischen Kunde und Agentur stellte dies in der Vergangenheit eine Herausforderung dar: schließlich kann man den Kunden nicht jedesmal während Konfigurations-Arbeiten bitten, für eine bestimmte Zeit lang keine Änderungen am Inhalt vorzunehmen (Content-Freeze).

In früheren Drupal-Versionen ab Drupal 6 gab es die Contrib-Modulfamilie „Features“, die die Möglichkeit bot, Konfigurations-Bestandteile in Form von Drupal Modulen zu exportieren. Diese haben sich anschließend als Quellcode versionieren lassen. Die exportierten Module lassen sich wie normale Module ausrollen und auf dem Zielsystem aktivieren.

Während der Lebensdauer von Drupal 6 und 7 wurde Features weiterentwickelt. In der Praxis hat sich dieses Konzept jedoch zu keinem Zeitpunkt als vollauf befriedigend herausgestellt.

Neben technischen Herausforderungen existieren viele Contrib-Module, die keine Features-Anbindung besaßen. Dies hatte zur Folge, dass sich die Konfiguration dieser Module nicht als Features exportieren ließ und die Konfiguration der Website somit nie vollständig exportiert und ausgerollt werden konnte.

Wie oben erwähnt wurde für den Umgang mit Konfiguration eine eigene Configuration Management Initiative (CMI) in Drupal 8 geschaffen, die von Greg Dunlap aka „heyrocker“ geleitet wurde.

Als Ergebnis können Sie sämtliche Konfiguration einheitlich in Form von YAML-Dateien exportieren und sichern. Im Live-Betrieb greift Drupal zwar weiterhin auf die in der Datenbank befindliche Konfiguration zurück. Die Konfiguration einer Website können Sie jedoch jederzeit bequem exportieren und einlesen. Indem dies Bestandteil des Drupal-Core ist, steht diese Funktionalität automatisch sämtlichen Contrib-Modulen zur Verfügung.

Derzeit unterstützt der Core jedoch nur den Im- und Export aus bzw. in einen einzigen Ordner. Multisites besitzen in aller Regel einen großen Anteil identischer Konfiguration sowie einen kleineren Teil an Site-individueller Konfiguration. Um die Funktionalität für Multisites zu erweitern, hat Bright Solutions (ehemals Comm-Press) das Modul Nimbus entwickelt. Mit Nimbus können Sie Konfiguration aus verschiedenen Verzeichnissen lesen bzw. darin schreiben.

Seit September 2015 – zwei Monate vor dem offiziellen Launch von Drupal 8 – hat Bright Solutions sämtliche neuen Projekte auf Basis von Drupal 8 aufgesetzt. Diese Aufnahme von Ralf Hendel ist während der DrupalCon Los Angeles 2015 enstanden.

REST-Services

Durch die REST-Unterstützung im Core eignet sich Drupal auch für Architekturen, bei dem Drupal als reiner Daten-Provider im Hintergrund agiert. In diesem Fall stellt Drupal die abgefragten Informationen in einem neutralen Datenformat zur Ausgabe auf verschiedensten Geräten wie Desktops, nativen Mobile-Apps bzw. sämtlichen Geräten im Internet der Dinge (IoT) bereit.

Sämtliche Backend-Eingabemasken zur Konfiguration und redaktionellen Eingabe von Inhalten sind für mobile Geräte optimiert.

Einbindung der TWIG Template-Engine
Die Einbindung der Template-Engine „Twig“ ermöglicht Frontend-Entwicklern, die keine tiefergehenden PHP-Programmierkenntnisse besitzen müssen, die Mitarbeit an der Template-Erstellung.

Drupal Performance und Caching
Performance steht und fällt bei Drupal mit ausgeklügeltem Caching. Caching bedeutet das Zwischenspeichern einzelner Elemente, deren Ausgabe vom Server bereits berechnet (gerendert) wurde und die beim Aufruf einer komplexen Seite „eingesammelt“ und ausgeliefert werden. Auf diese Weise muss der Server nicht die gesamten Inhalte eines Elements aus der Datenbank abfragen und deren Ausgabe berechnen.

Unterschiedliche und verschachtelte Caching-Mechanismen sorgen dafür, dass sich Inhalte trotz komplexer Datenbankabfragen im Backend schnell an den Benutzer ausliefern lassen. Im Unterschied zu Drupal 7 lassen sich die Caches einzelner Seiten aufgrund der Änderung von Inhalten selbstständig invalidieren. Drupal 7 kannte überwiegend nur ein zeitlich basiertes Caching. Das bedeutet, dass sämtliche Inhalte für eine feststehende Zeitdauer zwischengespeichert werden – ungeachtet dessen, ob sie sich auf der hochfrequentierten Homepage oder einer selten besuchten Seite einer abgelegenen Region der Website befinden.

Um die Drupal 8 Funktionalität auch in der Vorgängerversion nutzen zu können, musste unter Drupal 7 ein Contrib-Modul „Display Cache“ installiert werden: Display Cache ermöglicht erstmals auch unter Drupal 7, dass die Caches der beteiligten Inhalte (Seiten-Content, Teaser auf Übersichtsseiten sowie Blöcke) im Fall einer inhaltlichen Änderung unabhängig von ihrer Ablaufzeit invalidiert und vor der nächsten Auslieferung neu berechnet werden.

Migrate-Modulfamilie im Core

Wegen der umfangreichen Änderungen, wie die Daten innerhalb von Drupal 8 intern gespeichert werden, ist die „Migrate“ Modul-Familie, mit der sich Inhalte von Drupal oder auch Dritt-Systemen importieren lassen, in den Core aufgenommen worden.

Mit Migrate können Sie Inhalte aus älteren Websites oder sogar aus fremden Systemen importieren. Der Import funktioniert transaktionsbasiert, sodass Sie einzelne Schritte im Bedarfsfall zurückrollen und später erneut ausführen können. Das System merkt sich, welche Inhalte bereits importiert wurden.

Begrüßung zur europäischen Drupalcon 2017, die im September mit 1.670 Teilnehmern in Wien stattfand.

Semantische Versionierung, Composer und Deployment in Drupal 8

Mit Drupal 8 wurde die sogenannte „semantische Versionierung“ für Unterversionen (Minor-Versions) eingeführt.

Bei semantischer Versionierung gibt die Versionsnummer – z.B. „8.4.2“ – Auskunft über Major-, Minor-, und Patch-Version: Minor-Versionen enthalten Verbesserungen und. API-Änderungen sind innerhalb von Minor-Versionen nicht zulässig. Im Fall von „API-Breaks“ muss die Major-Version erhöht werden.

Das Konzept semantischer Versionierung legt nahe, den in der PHP-Welt etablierten Dependency-Manager „Composer“ zur Verwaltung der Drupal Quellcodes zu verwenden.

Bei Composer befinden sich nicht mehr sämtliche Quell-Codes eingebundener Komponenten wie z.B. Modulen, Add ons, Extensions oder Programm-Bibliotheken im Verzeichnis des Projekts. Statt dessen zieht Composer referenzierte Quellcode-Bestandteile anhand ihrer Abhängigkeiten aus verschiedenen Quellen zusammen. Durch den Einsatz von Composer wird die Code-Basis der einzelnen Projekte erheblich verschlankt, da sich der Drupal-Quellcode und die einzelnen Contrib-Module nicht mehr im Repository befinden sondern über Sub-Repositories eingebunden werden.

Jedes Composer-Projekt enthält ein Inhaltsverzeichnis der referenzierten Unterprojekte in der Datei composer.json.

Über Anbieternamen (Vendor) und Namensräume (Namespaces) werden die Pakete angesprochen. Auch innerhalb von Drupal-Projekten ist „Drupal“ lediglich ein „Vendor“ wie jeder andere auch.

Zur Identifikation ihres jeweiligen Versionsstands erhalten sämtliche Pakete ebenfalls semantische Versionsnummmern. Im oben beschriebenen Inhaltsverzeichnis, der Datei composer.json, können referenzierte Pakete zusätzlich mit Update Operatoren – sogenannten „Constraints“ –, versehen werden. Auf diese Weise lassen sich Bedingungen an Minimal- oder Maximal-Versionsstände formulieren, die Composer beim Build-Prozess berücksichtigt. Deswegen wird Composer als „Dependency Manager“ bezeichnet.

Beispiele für Constraints sind:

• „vendor/package“: „1.4.3“, (= verwende exakt die Version „1.4.3“)
• „vendor/package2“: „2.*“, (= es dürfen beliebige Minor-Versionen der Major-Version „2“ verwendet werden)
• „vendor/package3“: „^1.0.4“ (= es muss genau die Major-Version „1“ und mindestens die gepatchte Version „4“ verwendet werden)
• „vendor/package“: „dev-master“, (= verwende den aktuellsten Git-Commit im Master-Branch)

Vor dem sogenannten „Deployment“, dem Übertragen der Quellcodes auf das Produktiv-System, werden automatisierte Tests gegen die frisch gebaute Software laufen gelassen. Besteht die Software die Tests, werden Updates vom Live-System erstellt und die Software auf die Produktiv-Umgebung ausgerollt. Die Automatisation dieses Vorgangs wird als „continuous integration“ bezeichnet. Als Deployment-Server setzen wir „Jenkins“ ein.

Damit die Paketquellen nicht bei jedem Build-Prozess erneut über das Internet geladen werden, gibt es Paketverwaltungen, die die benötigten Pakete lokal spiegeln („cachen“) und Composer in Form komprimierter ZIP-Dateien zur Verfügung stellen. Die gewünschten Code-Kompomenten werden von der Paketverwaltung anhand ihres Git-Tags und Namespaces aufgelöst.

Als Paketverwaltungs-Software gibt es „Packagist“. Neben der öffentlichen Version, bei der sämtliche Projekt-Quellcodes anonym – von jeder Person – heruntergeladen werden können, gibt es eine kommerzielle Version sowie eine eine private Open Source Alternative „Satis“, die wir für unsere Projekte einsetzen. Die Quellcodes befinden sich in aller Regel auf dem öffentlichen Drupal-Verzeichnis für Packagist.

Ralf Hendel – der Autor dieses Artikels und Geschäftsführer Bright Solutions Hamburg – 2015 auf der DrupalCon Los Angeles.
Ralf beschäftigt sich seit 2007 mit dem Open Source CMS.

Drupal mit dem Terminal steuern: „Command Line Interfaces“ für Drupal

Hacker lieben die Shell: Als Entwickler oder Site-Builder möchten Sie bestimmte Aufgaben möglicherweise gezielt per Kommandozeile anstoßen können ohne viel in Benutzeroberflächen herumklicken zu müssen.

Um das CMS vom Terminal bzw. der Konsole aus steuern zu können, gibt es zwei verschiedene Command Line Interfaces (CLI) namens Drush und Drupal Console.

Das könnte Sie auch interessieren: Drupal Agentur in Darmstadt und Hamburg

Drush, das Schweizer Messer

Drush ist die Kurzform von Drupal Shell. In der ersten Version wurde Drush bereits für Drupal 4.7 entwickelt und im Mai 2007 von Franz Heinzmann für Drupal 5 redesigned. Seitdem wird es es fortlaufend weiterentwickelt. Der derzeit wichtigste Maintainer für Drush ist Moshe Weitzman.

Als Entwickler, Site-Builder und zum Deployment ist „drush“ praktisch unverzichtbar: Während Ihrer täglichen Arbeit kommt es häufig vor, dass Sie beispielsweise den Cache leeren möchten. Bis zur Version Drupal 7 lautet der entsprechende Befehl einfach „drush cc“ (die Kurzform von „drush cache-clear“) bzw. ab Drupal 8 „drush cr“ (der Kurzform von „drush cache-rebuild“). Diese Befehle haben Sie viel schneller im Terminal ausgeführt, als wenn Sie erst mit der Maus zum entsprechenden Eintrag „Konfiguration“ / „Entwicklung“ / „Leistung“ im administrativen Menü navigieren und die Schaltfläche „Clear all caches“ klicken müssen.

Indem Sie sich für Ihre unterschiedlichen Umgebungen eigene Aliase wie beispielsweise „cp-local“ oder „cp-production“ anlegen, können Sie Drush Befehle auch remote auf entfernten Servern ausführen. Dies setzt jedoch voraus, dass Drush auf den Servern installiert ist und Sie Kenntnis der Zugangsdaten besitzen.

Für die Synchronisation von Daten aus externen Quellen – z.B. von Artikeln und Bestandsdaten aus einer externen Warenwirtschaft oder den Abo-Kunden eines Online-Magazins ist es sinnvoll, eigene Drush-Plugins zu entwickeln, die Sie zeitgesteuert per Cron-Job auf dem Server starten und aus Performance-Gründen im Batchmodus ausführen lassen sollten.

Im Batchmodus wird ein Skript, das in einer Schleife nacheinander über alle Datensätze eines Inhaltstyps läuft, in mehrere Pakete aufgeteilt, die nacheinander ausgeführt werden.

Anstelle einer herkömmlichen Schleife, in der ein Skript in einem Zug über sämtliche Datensätze eines Inhaltstyps ausgeführt wird, werden die Datensätze im Batchmodus in einzelne kleinere Pakete aufgeteilt. Der Batchmodus arbeitet die einzelnen Pakete nacheinander ab und sorgt dafür, dass die Schleifen immer nur über eine kleinere Anzahl von Datensätzen ausgeführt werden.

Unser Lesetipp: Drupal vs WordPress vs TYPO3: Drupals Weg zum Enterprise Level CMS

Ohne den Batchmodus kann es unter Umständen passieren, dass die Serverlast infolge der Ausführung des Skripts dermaßen stark anwächst, dass die Seite nicht mehr für Besucher dargestellt oder die Ausführung sonstiger Funktionen auf dem Server beeinträchtigt werden.

Eine Liste der verwendbaren Drush-Befehle finden Sie unter https://drushcommands.com/. Bei Github können Sie sich Drush kostenlos herunterladen.

Drupal Console

Ab der Version Drupal 8 gibt es mit der DrupalConsole eine weitere CLI, die sich objektorientiert an modernen PHP OOP Design-Patterns orientiert und auf Symfony Console sowie weiteren Komponenten von Drittanbieter aufsetzt.

Der Befehlssatz überschneidet sich teilweise mit Drush: Einige Befehle gibt es in beiden CLI-Versionen, so lässt sich mit beiden Tools der Cache leeren oder Konfiguration importieren.

Deutlicher als Drush wendet sich die Drupal Console jedoch an Entwickler. Der Code-Generator nimmt Ihnen eine Menge Arbeit ab: Bei der Entwicklung neuer Module können Sie sich von der Drupal Console ein Code-Korsett von Klassen, Methoden und Interfaces erstellen lassen, die Sie anschließend nur noch mit der entsprechenden Funktions-Logik vervollständigen müssen.

Blick in den Sprintraum auf der DrupalCon 2015 in Los Angeles: Auf Events wie den DrupalCons kommen Entwickler aus der ganzen Welt zusammen, um sich über Drupal und Tools wie Drush auszutauschen bzw. daran weiterzuentwickeln.

Drupal Themes

Im Vergleich zu WordPress gibt es für Drupal weniger kommerzielle oder freie Themes.

Das hängt mutmaßlich mit der Komplexität Drupals zusammen: Um dem technisch weniger versierten Anwender ein Theme zugänglich zu machen, wird es häufig zusammen mit Demo-Content ausgeliefert. Dieser Content setzt ein auf willkürlich Weise vorkonfiguriertes Datenmodell – und damit eine ganz bestimmte Installation – voraus. Aus unserer Erfahrung greifen die Template-Dateien oftmals nur bei genau dieser Konfiguration. Sobald man andersartig konfigurierte Inhalte ausspielt, werden diese nicht mehr im gewünschten Layout der Website dargestellt.

Streng genommen muss man von einer Distribution sprechen, sobald Konfiguration mitgeliefert wird. Ein Theme darf nur aus Template-Dateien bestehen und sollte so generisch aufgebaut sein, dass es auch bei unbekannter Konfiguration sauber funktioniert. Wegen der Komplexität und Modul-Vielfalt des Open Source CMS ist so etwas jedoch kaum möglich.

Der Nachteil solch distributionsartiger Themes besteht darin, dass der Benutzer auf die willkürliche Vorauswahl der Module festgelegt ist. Häufig lassen sich kommerzielle Themes nicht oder nur sehr aufwändig modifizieren. Insofern empfehlen wir unseren Kunden üblicherweise die Erstellung eines individuellen Themes.

Kostenlose Drupal Themes befindet sich hier. Renommierte Anbieter kommerzieller Drupal Themes sind z.B. „themeforest“ bzw. „TemplateMonster„.

Zielgruppen für Drupal

Obwohl Sie mit Drupal auch kleinere Websites erstellen können, zeigt der Trend erkennbar in Richtung Enterprise. Nicht zuletzt wegen der individuellen Themes stellen Systeme wie WordPress für kleinere Websites in aller Regel eine günstige Alternative dar, da sich die initiale Einrichtung Drupals deutlich aufwändiger darstellt.

Seine Vorteile spielt Drupal im Bereich komplexer Applikationen aus, die entweder viel Content halten und ausspielen oder aber Daten online verarbeiten müssen.

Speziell für Verlage und Universitäten gibt es eine Drupal Distribution „Thunder“, die auf Drupal 8 aufsetzt und eine verbesserte Medienverwaltung sowie Eingabeoberflächen für Redakteure mitbringt.

Die Zukunft von Drupal

Die Zukunft Drupals besteht allem Anschein nach im Ausbau zum führenden headless bzw. decoupled Content Management System. Auf der DrupalCon Wien hat Dries in seiner Keynote erklärt, dass er Drupal in den kommenden Jahren als leading Headless-CMS sieht:

Driesnote Vienna 2017:
Die DrupalCon Wien wurde von Megan Sanicki eröffnet. Anschließend hat Dries Buytaert seine „Driesnote“ gehalten: traditionell gehört die erste Keynote auf jeder DrupalCon ihm.

Obwohl das beliebte Open Source CMS weiterhin ein klassisches Frontend mitbringt, werden im Enterprise-Segment immer mehr größere Seiten auf Basis moderner Frontend-Technologien in Verbindung mit Frameworks wie beispielsweise GraphQL und React entwickelt.

Für decoupled angelegte Anwendungen gibt es eine auf „API-First“ getrimmte Distribution namens „Contenta“.

Inzwischen gibt es sogar den Ansatz, selbst die Konfigurations- und Eingabeoberflächen headless zu bauen.

Downloads & Links

Eine Auswahl repräsentativer Arbeiten auf Basis von Drupal finden Sie in unseren Referenzen.

Drupal 9 steht hier zum Download zur Verfügung.

Eine besonders komfortable und Hosting-neutrale Testplattform stellt „simplytest.me“ dar. Hier können Sie verschiedene Module auswählen bzw. sogar Patches angeben, die Sie auf Drupal 6, 7 oder 8 testen können. Nach spätestens 24 Stunden wird die Installation wieder zurückgesetzt.

Die Distribution „Thunder CMS“ können Sie hier herunteladen und installieren. Auch für Thunder gibt es eine Online Demonstration bzw. die Möglichkeit Thunder auf simplytest.me auszuprobieren.