Drupal: Modular Power

Was Plugins für WordPress sind, sind für Drupal Module: funktionale Erweiterungen des Basis-Systems, die Betreibern mitunter viel teure Eigenentwicklung einsparen können. Im vorliegenden Artikel gehen wir auf das Modulkonzept Drupals im Detail ein. Wir beleuchten, welche unterschiedlichen Sorten von Drupal-Modulen es gibt, betrachten die Vor- und manche Nachteile des Modulkonzepts und schauen uns an, wie das Community-Contribution Prinzip Drupals funktioniert.

"There is a module for that"

So ziemlich jedem, der mit Drupal schon zu tun gehabt hat, dürfte dieser Satz bereits über den Weg gelaufen sein. Er ist die Chiffre für eine der besonderen Stärken, die Drupal auszeichnen. Denn nicht nur steht der Satz stellvertretend dafür, wie vielseitig Drupal in unterschiedlichsten Business Use Cases einsetzbar ist.

Er zeigt auch, dass bereits für eine Vielzahl von Problemstellungen oder nachgefragten Funktionen, die ein potenzieller Betreiber Drupals lösen bzw. umsetzen lassen möchte, Lösungen existieren. Mit anderen Worten: das fragliche Problem hat schon vorher jemand gehabt, über ein generisches Modul gelöst und dieses wiederum der Drupal-Community zur Nutzung und weiteren Entwicklung zur Verfügung gestellt.

Was ist ein Drupal-Modul und wie funktioniert es?

Ein Drupal-Modul ist ein nach einem festgelegten Standard entwickeltes Datei-Set. Es besteht meist aus einer unterschiedlichen Zahl von PHP-, JavaScript-, CSS- und weiteren Plaintext-Konfigurations-Dateien. In seiner Gesamtheit ergänzt oder erweitert dieses Datei-Set den Kern-Drupals um neue Funktionen. Dabei sind der Fantasie, um welche Funktionen es sich dabei handeln kann, keine Grenzen gesetzt – diese liegen allenfalls in den Bereichen "time and budget".

Diese große Vielseitigkeit, die das Modulkonzept Drupals bietet, ist mit ein Grund, wieso das System oft als "Web-Application-Framework" bezeichnet wird, und nicht "nur" als "Content-Management-System". Content-Management ist somit nur *ein* Aspekt, der sich über Drupal darstellen lässt. Aber auch das ganze funktionslogische "Drumherum" ist mit Drupal abbildbar: seien es komplexe Freigabeprozesse, Unternehmens-Workflows, Produkt-Taxonomien, Berechtigungsschemata, Nutzer- und Rollenmanagement, die Steuerung von oder die Ansteuerung durch beliebige Drittsysteme - die Liste ließe sich beliebig lange fortsetzen.

Module werden in Drupal installiert, indem ihre Dateien im Ordner "modules" im Drupal-Verzeichnisbaum hinterlegt werden. Dies kann theoretisch auch händisch passieren, wird bei versionierten Projekten aber in der Regel mittels "Composer" erledigt.

Die interne Modul-Verwaltung liest dann aus der standardisierten Info-Datei eines Moduls dessen Basis-Informationen wie Name, Beschreibung und Versionsnummer aus und zeigt es der Modul-Liste an. Ebenso ist in dieser Liste dann ersichtlich, ob das Modul gerade aktiviert oder deaktiviert ist. Aktivieren lässt es sich auf mehrere Arten: entweder automatisiert bei der Installation über ein Script, oder auch manuell in der Modul-Liste über eine Checkbox. Analog lässt sich ein Modul auch wieder deaktivieren und deinstallieren, sofern auf dieses Modul gerade keine Abhängigkeiten bestehen.

Was sind Modul-Abhängigkeiten?

Module können in Drupal so entwickelt werden, dass sie den Funktionsumfang anderer Module voraussetzen, um selbst funktionieren zu können. Auch hier gilt wieder der Effizienzgedanke: Was da ist und funktioniert, sollte nach Möglichkeit wiederverwendet oder darauf aufgebaut werden, sodass das Rad nicht immer wieder neu erfunden werden muss.

Das bedeutet aber auch: ist ein Modul A in einem Drupal-Setup vorhanden und aktiviert, von dessen Funktionsumfang ein weiteres installiertes und aktives Modul B abhängt, kann Modul A nicht ohne Weiteres deaktiviert werden. Zuerst müsste dies beim abhängigen Modul B geschehen.

Ein weiterer Aspekt, der bei Modul-Abhängigkeiten ("Dependencies") mitunter zu Problemen führen kann, sind Inkompatibilitäten nach Funktionsänderungen. Gibt es bei Modul A beispielsweise in einer neuen Version eine Änderung in den bereitgestellten Funktionen, die von Modul B so nicht erwartet wird, kann dies zu einem Kompatibilitätsproblem und somit zu Fehlern im Projekt führen. Sofern das Problem nicht durch eine neue Version oder einen Patch für Modul B behoben wird.

Dies ist im Übrigen eines der häufigsten Szenarien im Lebenszyklus eines Drupal-Projekts, bei denen im Rahmen der reinen Wartung und Instandhaltung Probleme auftreten können. Dies tritt insbesondere dann auf, wenn Module zum Einsatz kommen, die nicht so häufig verbreitet sind oder selten neue Versionen bekommen.

Modul-Abhängigkeiten bringen somit auch Nachteile mit sich. Im Großen und Ganzen wiegen hier jedoch die Vorteile - nämlich die Wiederverwendungsmöglichkeit bereits vorhandener Lösungen - erheblich schwerer.

Welche Arten von Modulen gibt es?

Core-Module

Auch der Drupal-Kern selbst ist bereits modular aufgebaut. Das heißt, auch das Funktions-Set, welches Drupal nach einer Standard-Installation bietet, wird über Module bereitgestellt. Diese Module nennt man "Core"-Module. Sie werden auf drupal.org zentral verwaltet, betreut und weiterentwickelt. Jedoch ist ihre Zahl nicht unveränderlich.

Seit der neuen, mit Drupal 8 eingeführten evolutionären Entwicklungsstrategie, werden immer wieder neue Module in den Drupal-Kern aufgenommen, um den Funktionsumfang von Drupal Core zu optimieren. Veraltete, kaum oder nicht mehr genutzte Module wiederum können aus dem Core im Rahmen eines Minor- oder Major-Release auch wieder herausgenommen werden.

Veränderungen an Core-Modulen durch den Seitenbetreiber sind technisch zwar möglich, aber unbedingt zu vermeiden - es sei denn, dies geschieht durch einen gemäß der Drupal-Entwicklungsrichtlinien geschriebenen Patch, der ggf. auch an die Community zurückgegeben wird. Denn nur wenn die Core-Module unangetastet bleiben, bleibt eine Drupal-Installation update-fähig und wartbar.

Eine Übersicht der aktuell in Core befindlichen Module befindet sich hier.

Contrib-Module

Ein Contrib(ution)-Modul ist, wie der verkürzte englische Name schon sagt, ein Modul, welches ein Beitrag (contribution) aus der Community zum Funktionsumfang von Drupal ist. In vielen Fällen entstehen solche Module initial im Rahmen von Drupal-Projekten, bei denen sich

• ein einzelner Drupal-Entwickelnder
• der umsetzende Dienstleister
• oder der Betreiber des Drupal-Projekts

entscheidet, aus einer bestimmten Problemstellung heraus den Lösungsansatz als generisches Modul zu abstrahieren, dieses der Community bereitzustellen und entweder dessen Betreuung und Weiterentwicklung als sogenannter "Maintainer" selbst übernimmt oder nach Gleichgesinnten sucht, die sich an der Betreuung beteiligen ("Co-Maintainer").

Löst das Modul ein häufig vorkommendes Problem, ist es wahrscheinlich,

• dass sich weitere Mitglieder aus der Drupal-Community an dessen Weiterentwicklung beteiligen
• Dritte dessen Weiterentwicklung finanziell unterstützen (z.B. durch Sponsoring)
• oder die Bereitstellung von eigenen Entwickler-Kapazitäten für Verbesserungen und Bugfixing anbieten.

Der Contribution-Ansatz, eigene Arbeitsergebnisse der Allgemeinheit zur Verfügung zu stellen, kann sich also in vielerlei Hinsicht auszahlen - und steht ganz im Zeichen des Open-Source-Gedanken:

• Modul-Maintainer können Co-Maintainer finden, die ihnen helfen und Entwicklungsarbeit abnehmen
• Betreiber von Drupal-Projekten, für deren Projekte das Modul ein Problem löst, müssen nicht von null beginnen, sondern profitieren von der bereits geleisteten Entwicklungsarbeit, was sowohl eine Zeit- als auch Geldersparnis bedeuten kann
• entscheiden sich diese anderen Betreiber, in Abstimmung mit dem Maintainer, das fragliche Modul funktional aufzurüsten, zu verbessern oder sicherheitstechnisch weiter zu härten, gewinnt auch die ursprüngliche veröffentlichende Person des Moduls, da sie nun ihrerseits von der investierten Arbeit anderer Community-Teilnehmer profitieren kann
• entscheiden sich andere Betreiber, für das Modul Plugins zu schreiben oder zusätzliche abhängige Module zu entwickeln, die in Kombination mit diesem funktionieren, steht allen Beteiligten ebenfalls ein potenziell viel größerer Nutzwert zu Verfügung, als wenn jede Partei isoliert ihre eigene Lösung verfolgt hätte

Aufgrund dieser vielen Vorteile ist das Contrib-Modul erwartungsgemäß ein sehr häufiger Modul-Typ. Die Suchmaske für Contrib-Module auf drupal.org nennt hier inzwischen über 50.000 verfügbare Module.

Besonders beliebte und mitunter seit Jahren verfügbare Module sind beispielsweise:

• Token
• cTools
• Pathauto
• Webform
• Paragraphs
• Backup and Migrate
• Group
• Rules bzw. als spannender "Newcomer" ECA

Schon immer war es außerdem so, dass besonders populäre und weitverbreitete Contrib-Module irgendwann auch zu einem Core-Modul werden konnten. Bekannte Beispiele sind etwa Views, welches ab Drupal 8.0 in den Core aufgenommen wurde oder Media, welches ab Drupal 8.4 in Core wanderte.

Setzt ein Bestandsprojekt ein Contrib-Modul ein, welches zu dessen Betriebszeit in Core wandert, kann mitunter eine kleinere Migration im Rahmen der Wartung und Weiterentwicklung notwendig werden. Hierbei muss die Funktionslogik in diesem Fall vom "alten" Contrib-Modul auf das "neue" Core-Modul umgestellt werden muss. Insbesondere bei komplexen und funktionsmächtigten Modulen, wie es bei Media der Fall war, kann eine solche "interne" Migration durchaus aufwändiger werden.

Custom Module

Unter einem "Custom Modul" versteht man ein nach den allgemeinen Entwicklungsrichtlinien geschriebenes Drupal-Modul, welches aber in der Regel nur in einem konkreten Kundenprojekt zum Einsatz kommt und somit nicht veröffentlicht wird.

Mit Custom-Modulen lassen sich insbesondere Business-Logiken und Geschäftsprozesse gekapselt in einem Drupal-Projekt abbilden, die sehr kundenspezifisch sind und deren Abstraktion in ein generisches Modul entweder nicht sinnvoll oder nicht wirtschaftlich ist.

Im konkreten Kundenprojekt fungieren diese Module aber genauso wie "veröffentlichte" Module: sie lassen sich installieren, aktivieren, ggf. konfigurieren und können durch den Seitenbetreiber oder seine/n Dienstleister weiterentwickelt werden.

Nicht selten beginnt ein neues Contrib-Modul sein Leben auch als ein solches Custom-Modul: wenn also etwa die Entscheidung getroffen wird, den kundenspezifischen Use Case zu generalisieren und daraus eine abstrakte Problemstellung mit einem generischen Lösungsansatz zu definieren bzw. implementieren. In diesem Fall - und entsprechend vorhandenes Budget vorausgesetzt - kann ein Custom-Modul ein Rewrite erfahren und daraus ein neues Contrib-Modul entstehen, was auf drupal.org veröffentlicht wird und das Funktionsangebot für Drupal wieder um ein kleines Stück erweitert.

Themes

Ähnlich wie Module sind Themes ebenfalls ein Bundle aus verschiedenen Dateien: Konfigurationsangaben in Plaintext, PHP, HTML, CSS, JavaScript und ggf. Grafiken. Während Module jedoch in der Regel Funktionalität bereitstellen, kümmern sich Themes um Darstellung.

Vereinfacht gesagt sind sie die Oberfläche dafür, was Drupal an funktionalen und inhaltlichen Elementen bereitstellt und legen fest, wie diese in einem Webbrowser letztlich angezeigt werden. Erst über diese von den Themes bereitgestellte ("gerenderte") Oberfläche wird es also möglich, Daten aus Drupal zu konsumieren, dorthin zu übergeben oder anderweitig mit dem System zu interagieren.

Im Gegensatz zu manch anderen Systemen, wie beispielsweise Typo3, erzwingt Drupal keine harte Trennung zwischen einer bestimmten administrativen Oberfläche ("Backend"), über die das Projekt verwaltet wird, und der eigentlichen Endbenutzer-Oberfläche ("Frontend").

Es ist also ohne Weiteres möglich, Frontend und Backend über dieselbe Benutzeroberfläche zu verwalten. Aufgrund des Umstandes, dass jedoch viele Bedienelemente, die für die Administration einer webbasierten Software erforderlich sind, selten oder nie in Frontend-Kontexten gebraucht werden, existieren für Drupal aber auch spezielle "Backend", oder auch "Administration"-Themes". Diese sind für die bequeme und übersichtliche Website-Administration optimiert - etwa das neu für Drupal 10 mit aufgenommene Standard-Administrations-Theme Claro.

Das Drupal-Contribution-System

Im Verlauf des Artikels wurde bereits mehrfach angerissen, dass im Drupal-Ecosystem die "Contribution" - also der Beitrag bzw. die Beiträge Einzelner, einer Gruppe, eines Unternehmens oder einer Institution - die entscheidende Triebfeder ist, die das Drupal-Projekt in seiner Gesamtheit voranbringt.

Ohne dieses kontinuierliche Commitment zahlloser Unterstützer könnte Drupal nicht das sein, was es ist:

• ein ausgesprochen vielseitiges und funktionsmächtiges Content-Management-System und Web-Applikation-Framework
• mit hohen Qualitätsstandards, einer geregelten Update- und Upgrade-Policy
• technisch kontinuierlich erneuert und somit stets auf der Höhe der Zeit
• und das alles für jeden frei verfügbar, nutzbar, erweiterbar, da es quelloffene Open-Source-Software ist

Wer kann contributen?

Jeder. Man muss dazu kein Entwickler sein, denn es gibt auch genug nicht-entwicklerspezifische Themen, zu denen man beitragen kann. Folgende sogenannte "contribution areas" werden hierbei von der Drupal-Community genannt:

• Accessibility
• Community building
• Contributed modules, themes, and distributions
• Contributor guide
• Documentation
• Drupal core
• Drupal.org websites
• Event planning
• Knowledge sharing
• Marketing
• Mentoring
• Support
• Translation
• Usability
   

Quelle: drupal.org

Man muss auch keine natürliche Person sein, denn auch Unternehmen und Institutionen können Contributions beitragen: etwa, indem

• sie ihren Mitarbeitenden gestatten, Drupal-Contributions aus den oben genannten Bereichen während der Arbeitszeit vorzunehmen
• sie Contributions durch Dritte, für die genannten Bereiche finanziell unterstützen oder dafür als Sponsor fungieren
• die Betreuung und Weiterentwicklung z.B. eines Contrib-Moduls übernehmen und finanzieren

Contribution Credits

Für Contributions gibt es seit 2015 Credits. Sie fungieren gewissermaßen als "Belohnung" bzw. als Indikator dafür, dass eine Person oder ein Unternehmen eine Contribution für Drupal vorgenommen hat (hier als Beispiel unsere eigene Credit-Page).

Dieses System kann somit als ein Gradmesser für das Engagement in der Community dienen. Für besonders stark engagierte Unternehmen kann es zudem einen Werbeeffekt darstellen, wenn beispielsweise

• Kunden darauf Wert legen, dass ein Dienstleister bei Einsatz einer Open-Source-Software "nicht nur nimmt, sondern auch (zurück-)gibt" oder
• potenzielle neue Mitarbeitende darauf achten, dass der mögliche künftige Arbeitgeber auch Zeit und gestalterischen Raum anbietet, etwas in der Open-Source-Community beitragen zu können

Aber auch Kunden als Drupal-Betreiber selbst können Credits einsammeln. Hierzu benötigen sie ebenfalls einen Account auf drupal.org. Im Rahmen ihres eigenen Projekts können sie Aufwände ihres Dienstleisters finanzieren, aus denen Contributions wie z. B. Bugfixes, Lokalisierung, Dokumentation u. v. m. entstehen. Denn dann kann der Dienstleister diese Contribution auch seinem Kunden gutschreiben lassen, wodurch der Kunde wiederum öffentlich zeigen kann, dass er ebenfalls einen Beitrag zur Verbesserung und Weiterentwicklung Drupals leistet. Wir freuen uns beispielsweise, dass unser Kunde Wertgarantie seit Kurzem ebenfalls Präsenz auf drupal.org zeigt und schon ein paar Credits für die im Rahmen seines Projekts erfolgten Contributions erhalten hat.

Fazit

Module sind ein besonders wichtiger und mächtiger Baustein in der Entwicklungs-Philosophie Drupals, um funktionale Erweiterungen nach einem definierten Prinzip bereitstellen zu können. Sie tragen damit wesentlich zur großen Flexibilität bei, die Drupal sowohl als Content-Management-Plattform, aber auch als Web-Applikation-Framework bietet.

Die Bereitstellung und der Unterhalt ("Maintenance") von Contrib-Modulen ist ein wichtiger Beitrag zur Stärkung von Drupal als Gesamtprodukt und eine tragende Säule für seinen anhaltenden Erfolg. Jedoch bedeutet diese Maintenance Arbeit und erzeugt auch Kosten, die gedeckt sein wollen.

Deswegen ist es so wichtig, dass Betreiber von Drupal-Projekten auch die Bereitschaft zeigen, etwas an die Drupal-Community zurückzugeben. Das hierfür geschaffene Contribution-Modell bietet vielfältige Möglichkeiten, sich für Drupal oder seine Community zu engagieren.

"Come for the software. Stay for the community".
So lautet ein weiterer viel zitierter Satz, wenn es um Drupal geht. Nur wenn möglichst viele Betreiber dieses Motto beherzigen und auch aktiv leben, haben Open-Source-Projekte wie Drupal eine sichere Zukunft.

Daher ist es an uns allen, dafür zu sorgen, dass dies so bleibt.

Bildnachweis

Zahnräder auf Titelbild von Vecteezy