Vorsicht "angestaubt"!
Dieser Artikel ist bereits etwas in die Jahre gekommen und enthält möglicherweise Informationen, die nicht mehr dem aktuellen Stand des Themas entsprechen.
Wer im Süden Deutschlands in einem Ort zugezogen ist und nicht zu den Alteingesessenen gehört, ist „neigschmeckt“. Ich bin ein „Reingeschmeckter“ in Drupaldingen. Seit 2013 realisiere ich Web-Projekte mit Drupal 6,7 und 8, allerdings ohne selbst zu coden. Vielmehr bin ich der typische Fall eines entwickelnden Anwenders, der die Konfigurationsmöglichkeiten von Drupal und passender Module ausreizt, um für Kunden in der Verlagsbranche leistungsfähige Web-Lösungen zu entwickeln.
Verlags-Datenbank- und Workflow-Management-System mit Drupal 6
Mein erster Kontakt mit dem CMS stammt aus dem Jahr 2012, als ich die Drupal 6-Distribution OpenAtrium als mögliche Lösung für ein Verlags-Intranet testete. Zwar kam das Firmen-Intranet damit nicht zustande, aber dafür hatte ich entdeckt, dass OpenAtrium mit dem CMS Drupal unter der „Haube“ einen Motor hatte, der noch viel mehr konnte.
So kam Drupal auch im folgenden Jahr als Kandidat für ein übergreifendes Verlagsprojekt ins Spiel: Eine Gruppe von Verlagen plante einen gemeinsamen, halbjährlichen Katalog von Neuerscheinungen für den Buchhandel. Dafür sollten die aufzunehmenden Titel in jedem Verlag dezentral in eine Datenbank eingepflegt und daraus in einem möglichst automatisierten Verfahren alle 6 Monate der gemeinsame gedruckte Katalog erstellt werden. Obwohl eher ein Datenbank- als ein Website-Projekt, fiel die Entscheidung für Drupal – v.a. wegen der damit verbundenen Erweiterungsoptionen.
Diese Optionen kamen auch schon bald zum Zug, als einer der Verlage als „Vorstufe“ zum inzwischen realisierten Katalog ein Workflow-Management-System für die Aufnahme von Titeln ins Verlagsprogramm inklusive entsprechendem Online-Begutachtungsprozess benötigte. Dieses System ließ sich mit Drupal problemlos vor die Datenaggregation für den Buchhandelskatalog bauen, sodass im daraus entstehenden Komplettsystem der gesamte (manchmal mehrere Jahre dauernde) Weg eines Titels von den ersten verlagsinternen Überlegungen über den Aufnahme- und Begutachtungsprozess bis hin zur seiner Ankündigung für den Buchhandel abgebildet werden konnte. Dank Drupal und ca. 50 hilfreicher Module wurde als Entwicklungszeit nur gut ein halbes Jahr benötigt, wobei keine einzige Zeile Code geschrieben werden musste.
Lexikon-Redaktionssystem mit Drupal 7
Nach den guten Erfahrungen mit Drupal kam das CMS auch in Folgeprojekten zum Zuge, dann allerdings in der neueren Version 7. So ist Drupal 7 z.B. seit 2016 als Redaktionssystem für ein Lexikonprojekt mit mehreren Tausend Artikeln und über 400 Autor/innen im Einsatz, wobei auch hier ein mehrstufiger Workflow und komplexe Berechtigungsanforderungen abzubilden waren. Nachdem die online eingestellten Beiträge der Autor/innen von der Redaktion bearbeitet und den Herausgebern freigegeben sind, werden sie für den Satz des gedruckten Lexikons aus Drupal in XML-Form bereitgestellt. Die Entwicklungszeit hierfür lag bei nur 3 Monaten, auch in diesem Fall allein durch die Nutzung von Drupal Core und passender Module.
Drupal 6 zu Drupal 8
Als Drupal 6 im Jahr 2016 an das Ende seiner Lifetime kam, war das Verlags-Workflow-Management-System weiter gewachsen und um mehrere Schnittstellen ergänzt worden. Da im November 2015 Drupal 8 erschienen war, fiel der Entschluss, Drupal 7 zu überspringen und das System gleich auf Drupal 8 upzudaten. Die Drupal 8-Version machte einen ausgereiften und stabilen Eindruck und es war klar, dass der Weg über kurz oder lang ohnehin zu Drupal 8 führen musste.
Composer, Drush und yaml
Bei diesem Umstieg gab es allerdings einige Hürden zu nehmen: Zum einen zeigte sich schnell, dass die Entwicklung nur mit Nutzung der Drupal-Oberfläche nun zu Ende war. Ohne Composer und Drush ging es nicht mehr. Außerdem waren die Inhalte der Drupal 6-Installation zu migrieren. Die mit den Drupal-Migrate-Modulen erzeugten yaml-Migrationsskripte mussten dafür noch an zahlreichen Stellen nachbearbeitet werden, auch um im Zuge der Migration einige Verbesserungen in der Datenstruktur vorzunehmen. Schließlich ging es darum, die neue Konfigurationsverwaltung von Drupal 8 zu nutzen und einen darauf abgestimmten Deployment-Workflow zu entwickeln. Bei alledem erwies sich Drupal 8 als ein ausgereiftes und sehr stabiles System, dessen Handling zwar deutlich anspruchsvoller ist als bei den Vorgängerversionen, das dies aber mit erweiterter Leistung und Funktionalität zurückzahlt.
Integration von Erweiterungsmodulen
Aufwändiger als in Drupal 6 gestaltete sich die Integration externer Module. Trotz der Aufnahme einige Drupal 6-Module in den Core von Drupal 8 blieben weiterhin fast 50, die in die neue Drupal 8-Lösung eingebunden werden mussten. Aufgrund der tiefgreifenden technischen Umstellungen in Drupal 8 gestaltete sich die Modul-Anpassung für die Entwickler oft aufwändig und damit langwierig. In einigen Fällen – wie z.B. beim intensiv genutzten Rules-Modul – standen (noch) gar keine einsatzfähigen Nachfolgelösungen für Drupal 8 zur Verfügung. Es mussten also passende Ersatzlösungen gesucht werden. Doch auch die Ersatz-Module (wie z.B. Business Rules statt Rules) waren oft noch im Entwicklungsprozess. Deshalb ging es nicht ohne umfangreiche Tests, Bug-Reporting, Fixing und Patching ab. Während die ursprüngliche Drupal 6-Installation ohne jeden Patch ausgekommen war, entwickelte sich das Patch-Management unter Drupal 8 so zu einem Aufgabenbereich mit eigenem Gewicht. In den meisten Fällen konnte man dabei auf die Unterstützung der Drupal-Community zählen, auch wenn sich die Projektentwicklung an einigen Stellen durch die Abhängigkeit von externen Modulen verzögert hat.
Ein Backup für alle Fälle
Kritisch wurde diese Abhängigkeit schließlich bei einem Modul, das für eine wichtige Funktion vorgesehen war, beim Test aber Fehler zeigte und vom Maintainer nicht weiter gepflegt wurde. Ohne eigene Coding-Kompetenz ist dies natürlich ein Ausschluss-Kriterium. Glücklicherweise stand mit arocom ein Partner bereit, der nicht nur die Korrektur und Anpassung dieses Moduls übernahm, sondern auch an vielen anderen Stellen den Umstieg auf Drupal 8 unterstützte. Die Bereitschaft zu einer solchen Zusammenarbeit mit einem ansonsten selbstständigen Entwickler ist alles andere als selbstverständlich und verdient besonderen Dank. Wer heute als Anwender-Entwickler Drupal 8 einsetzt, sollte auf jeden Fall einen solchen Partner mit Coding-Kompetenz im Hintergrund haben, um für alle Fälle gerüstet zu sein.
Dr. Bertram Salzmann arbeitet als e-Publishing Consultant für Medienunternehmen und ist Inhaber der Publishing Future GmbH.
Sie haben noch eine veraltete Drupal Version? Erfahren Sie mehr über das Drupal 9 Upgrade
