Das beliebte Web Content Management System "Drupal" basiert auf der Programmiersprache PHP und liegt heute im Versionsstand 8 vor. Drupal ist unter der GNU General Public License, Version 2 veröffentlicht und damit quellcode-offen ("Open Source").

Im Jahr 2000 wurde Drupal von Dries Buytaert ursprünglich als Forum für ein Studentenwohnheim entwickelt. Das System wurde anschließend zu einer Blog-Software und später zu einem der führenden Web Content Management Systeme erweitert.

Seit ca. 2009 trifft sich die Community auf großen Events wie der internationen DrupalCon sowie internationalen und nationalen DrupalCamps bzw. lokalen Usergroups. 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.

Drupal – alles geht: "There’s a module for that."

Drupal ist modular konzipiert: mit Hilfe der rund 40.000 verschiedener Module lassen sich mit dem vergleichsweise schlanken Kern ("Core") höchst unterschiedliche Anwendungen bauen. Dies können z.B. Unternehmens-Webseiten ("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.

Vergleich mit anderen Systemen: Wordpress und TYPO3

Im deutschsprachigen Raum (Deutschland, Österreich und Schweiz) stellen Wordpress und TYPO3 die bekanntesten alternativen Systeme auf Basis von PHP dar.

TYPO3 war das erste quellcode-offene System, mit dem sich anspruchsvolle Projekte haben realisieren lassen. Wordpress ist einigermaßen zeitgleich mit Drupal bekannt geworden. Aufgrund seiner Bedienerfreundlichkeit hat sich Wordpress rasant entwickelt. Rund 20% aller Websites weltweit laufen auf Basis von Wordpress. Bei Drupal beträgt dieser Anteil ca. 2%. Betrachtet man die Teilmenge der weltweit stärksten 10.000 Websites, die auf Basis eines Content Management Systems betriebenen werden, liegt der Anteil von Wordpress bei 37% und der von Drupal bei 8%. Je größer man diese Menge fasst, desto mehr verschiebt sich der Anteil zu Wordpress: Der Anteil von Wordpress aller CM-betriebenen Websites beträgt dann 53 und der von Drupal 2%. Dies zeigt, dass Drupal seine Bedeutung vor allem bei sehr großen – das heißt entweder bei komplexen oder bei sehr trafficstarken – Websites hat. TYPO3 ist weder bei den stärksten 10.000 noch bei Berücksichtigung sämtlichenr Websites innerhalb der Top 20 CM-Systeme vertreten.

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"). Bei Wordpress kommt auf 100 Anwender nur etwa ein Contributor.

TYPO3 ist hierarchisch organisiert: der gesamte Content und alle Menüfunktionen organisieren sich in einer baumartigen Struktur. TYPO3-Websites werden über Typoscript konfiguriert.

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

Das Eingabe-Backend ist bei TYPO3 klassischerweise von der für Besucher sichtbaren Website ("Frontend") getrennt. Bei Drupal 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 bei TYPO3.

Hinsichtlich der Benutzerfreundlichkeit für Redakteure ist Wordpress das benutzerfreundlichste und TYPO3 das am wenigsten benutzerfreundliche CMS im Vergleich der drei Systeme.

Bei der möglichen Komplexität von Webanwendungen liegen Drupal und TYPO3 etwa gleichauf. Aufgrund seiner verschachtelten Quellcode-Architektur kann Wordpress eher Performance-Probleme bei umfangreichen Anwendungen bekommen.

Im deutschsprachigen Bereich erfreut sich TYPO3 einer höheren Nachfrage als Drupal. Außerhalb dieses Bereichs spielt TYPO3 jedoch kaum eine Rolle.

Anhand der Daten lässt sich ablesen, dass die Nachfrage nach allen drei CM-Systemen rückläufig ist. Das hängt sicherlich damit zusammen, dass inzwischen immer mehr Funktionen, die früher klassischerweise Teil eines Content Management Systems waren, durch eigene Komponenten abgelöst werden. Besonders im Bereich Frontend-Entwicklung haben große Player wie Facebook und Google neue Systeme wie z.B. GraphQL, React und AngularJS entwickelt, die die Architektur von Websites revolutionieren.

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. Bei Entdeckung neuer Sicherheitslücken werden aktuell für Drupal 7 und Drupal 8 Sicherheitsupdates angeboten.

Entwicklungsprozess von Drupal

Der Weg zum heutigen Enterprise Content Management System in Version 8 verlief innerhalb der Vorgängerversionen über folgende Entwicklungsschritte:

Drupal 5

Gegenüber den Vorgängerversionen ist die Installation von Drupal erheblich vereinfacht worden.

Mit Version 5 hat 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

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

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

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.

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 comm-press das Modul "Nimbus" entwickelt. Mit Nimbus können Sie Konfiguration aus verschiedenen Verzeichnissen lesen bzw. darin schreiben.

SEO: Suchmaschinen-Optimierung und semantisches Markup

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.

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, das comm-press entwickelt hat: 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 Drupal-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.

Semantische Versionierung, Composer und Deployment bei 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. Unseren eigenen Modulen haben wir "comm-press" als Vendor-Namen gegeben.

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 bei comm-press für unsere Projekte einsetzen. Die Drupal-Quellcodes befinden sich in aller Regel auf dem öffentlichen Drupal-Verzeichnis für Packagist.

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 Drupals 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.

Eine repräsentative Auswahl deutschsprachiger Drupal-Referenzen findet sich hier.

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:

Obwohl Drupal 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.

Referenzen und Download

Eine Auswahl repräsentativer Arbeiten auf Basis von Drupal finden Sie hier.

Drupal 8 steht entweder hier zum Download zur Verfügung oder kann bei Hostern Pantheon bzw. Acquia online getestet werden.

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.

Die ältere Version 7 von Drupal können Sie hier herunterladen und installieren. Bei neuen Projekten sollten Sie auf jeden Fall Drupal 8 verwenden.

Wir sind für Sie da!

Sprechen Sie uns gern an, wenn Sie weitere Fragen rund um Drupal haben oder Unterstützung bei einem Projekt benötigen:

Unsere Drupal Experten in Hamburg beraten und unterstützen Sie bei Ihren Projekten, bieten Workshops und schulen Ihre Mitarbeiter in PHP, Drupal oder agilem Projekt-Management.

Telefonisch, im Chat oder vor Ort: ganz wie Sie es wünschen!