Drupal mit Composer oder mit Ludwig?

Das Major Update von Drupal 7 auf Drupal 8 (heute 9), vor mittlerweile sechs Jahren führte zu einer Segmentierung, um nicht zu sagen Spaltung der Drupal Community.

Bis zu dieser Zeit war Drupal ein sehr beliebtes Projekt bei Site-Buildern, die Drupal als No-Code Plattform nutzten und in kürzester Zeit beeindruckende und kostengünstige Websites nur durch Konfigurationen auf der Benutzeroberfläche realisieren konnten. Viele grosse Firmen wurden auf die Drupal Rockstars und die „One man armies“ im Theming-Bereich aufmerksam und stellten auch sehr grosse, mehrsprachige Websites auf Drupal um. Damals waren die Versionen Drupal 6 und 7 aktuell und die Art und Weise, wie diese Sites konfiguriert wurden, führte bei vielen Projekten durch ganz unterschiedliche Gründe längerfristig zu Performance- und Wartungsproblemen.

Drupal 8 war, verglichen mit Drupal 7, technisch besser durchdacht und bot „klassischen“ Software-Entwicklern Möglichkeiten, einen Grossteil der UI-Konfiguriererei zu vermeiden. Konfigurationsänderungen konnten als YAML-Dateien geschrieben und als Code ausserhalb der Datenbank in Versionskontrollsystemen verwaltet werden. Diese Vorgehensweise (Composer, Drush, Git) wurde in den letzten sechs Jahren verfeinert und ist auch heute die empfohlenen Vorgehensweise bei einem Drupal Projekt.

Für Drupal-Agenturen begann durch die Möglichkeiten von Drupal 8 ein wirtschaftlicher Goldrausch mit der Entwicklung und Pflege grosser Drupal-Sites, der bis heute anhält. Der Durchschnittspreis und -Aufwand für eine Drupal-Site steigt noch immer. Ich habe dafür keine empirischen Belege, aber alle Gespräche, die ich führe, weisen darauf hin.

Site-Builder zögerten bei der Umstellung von D7 auf D8, denn der Aufwand war hoch und die Wartung und Weiterentwicklung bestehender Sites wurde erheblich aufwendiger. Mit Backdrop entstand sogar ein Fork von Drupal 7 (siehe auch Backdrop, das benutzerfreundliche Open Source Web CMS vom 26.10.2020). Der offizielle Support für Drupal 7 Sicherheits-Updates wird immer wieder verlängert und reicht momentan bis November 2022. Viele Site-Builder wanderten zu WordPress und Contao ab.

Wenn du bei Google Trends nach den aktuellen Drupal Versionen suchst, erhältst du dieses Ergebnis:

Man könnte nun ein wenig zynisch behaupten: Drupal wurde ab etwa 2008 erfolgreich auf der Basis des bis dahin durch die begeisterte Community entstandenen Codes monetarisiert und konsolidiert. Der Erlös pro einzelner Drupal-Site ist heute erheblich höher und das CMS viel professioneller. Insgesamt werden aber viel weniger Sites mit Drupal erstellt.

Auf der Strecke bei dieser Monetarisierung blieb das am Anfang wohl wichtigste Alleinstellungsmerkmal (USP) von Drupal: in kürzester Zeit mit hochmotivierten Leuten logisch strukturierte Websites per Browser zu einem funktionierendem Ganzen konfigurieren zu können.

Der Markanteil von Drupal schrumpfte von 7.1% im Jahr 2010 auf zuletzt 2.2% im Jahr 2021 (Quelle W3Tech).

Nun hat sich die Welt natürlich in den letzten 10 Jahren verändert. Auch bei grossen Firmen ist der aktuelle Trend zu statischen Sites mit Microservices angekommen, Stichwort Jamstack. Die meisten Firmen tun sich aber noch schwer mit der Umstellung, denn Jamstack Sites sind zwar leicht und preisgünstig zu starten aber später, wie bei den ersten Drupal Sites, schwer zu warten. Je nach Vertrag können sie bei intensiver Nutzung auch sehr schnell sehr teuer werden. Aber, und das ist deren grosser Vorteil, sie sind statisch und dadurch prinzipbedingt sehr performant.

State of Drupal 2021

In jedem Jahr gibt Dries Buytaert, der Gründer von Drupal, eine „State of Drupal“ Presentation. In diesem Jahr gab es neben vielen anderen Themen einen deutlichen Schwenk zur Zielgruppe der Site-Builder.

When I ask people why they fell in love with Drupal, most often they talk about feeling empowered to build ambitious websites with little or no code. In fact, the journey of many Drupalists started with Drupal’s low-code approach to site building. It’s how they got involved with Drupal.

https://dri.es/state-of-drupal-presentation-april-2021

Building a Drupal site has grown increasingly complex with the need to manage external dependencies using tools like Composer or NPM. Site-builders without command line access on their hosting providers are increasingly unable to take full advantage of Drupal

https://www.drupal.org/project/ideas/issues/2940733

Um es kurz zu machen. Der „Total Adressable Market (TAM)“ für Drupal sinkt beständig. Der Einstieg für Anfänger muss vereinfacht werden um ihn zu vergrößern.

Erfahrungen mit Drupal 9

Ich bin in den letzten Monaten wieder öfter mit Drupal in Berührung gekommen und dabei sehr positiv überrascht worden. Sehr viele Anfragen kommen von Firmen, die WordPress Sites haben, die mittlerweile schwer durchschaubar, schwer wartbar und schwer erweiterbar geworden sind. Sie wünschen sich einfache und logische Strukturen, wie man sie mit Drupal sehr einfach aufbauen kann.

Zur Installation von Drupal gibt es bei Novatrend mit Softaculous einen wirklichen famosen Apps-Installer. Du kannst dir mit wenigen Klicks eine Drupal-Installation erstellen und Softaculous kümmert sich um die Updates. Ich war anfangs sehr vorsichtig mit dieser Funktion, nutze sie allerdings immer häufiger und muss sagen – es funktioniert sehr gut.

Nach dieser langen Vorgeschichte sind wir endlich bei der Bedeutung der Überschrift dieses Blog-Posts – Drupal mit Composer oder mit Ludwig?

Es gibt nämlich grundsätzlich zwei Wege mit einer Drupal-Site zu interagieren um Module zu installieren, Abhängigkeiten von externen Bibliotheken zu verwalten, die Site zu aktualisieren und vieles andere mehr. Der eine Weg führt über die Benutzeroberfläche von Drupal im Browser und der andere über eine Textkonsole im Terminalfenster. Beide Vorgehensweisen haben Vor- und Nachteile.

• Site-Builder und Anfänger arbeiten gern im Browser. Die Lernkurve ist dabei nicht so steil, der Einstieg niederschwellig und die Ergebnisse überwältigend (#teamLudwig).
• Entwickler und professionelle Agenturen arbeiten gern auf der Kommandozeile um möglichst viele wiederkehrende Prozesse automatisieren und optimieren zu können (#teamComposer).

Hier bei Novatrend sind grundsätzlich beide Varianten möglich, wir stehen der Arbeitsweise daher neutral gegenüber.

#teamLudwig

Das Modul Ludwig erhielt seinen Namen nach Ludwig van Beethoven, der bekanntlich ein tauber, aber sehr erfolgreicher Komponist war – also ein echter „Composer“ ohne Gehör. Das Modul Ludwig wird genutzt, wenn man zwar eine Dupal-Site, leider aber keinen SSH-Zugang hat.

Diese Art Humor, das Augenzwinkern und der Pragmatismus hinter diesem Modul war in der frühen Drupal Community sehr verbreitet. Nein, früher war nicht alles besser, nur anders 🙂.

Die Idee hinter Ludwig ist ganz einfach. Jedes Drupal Modul, das externe Bibliotheken benötigt, beispielsweise das Modul für die Einbindung des Newsletter-Services Mailchimp, benötigt eine Datei, in der die von diesem Modul benötigten externen Bibliotheken beschrieben werden. Vor der Aktivierung des Moduls muss Ludwig aufgerufen werden. Ludwig liest die Datei und lädt nach einem Klick die richtigen Bibliotheken in das Modulverzeichnis.

Diese Vorgehensweise hat, wie gesagt, auch architektonische Nachteile, ermöglicht es aber ohne SSH-Zugriff, nur über die Drupal-Oberfläche, ein Newsletter-Modul wie Mailchimp zu installieren. Allein die Möglichkeit, so etwas über die Browseroberfläche zu tun kann entscheidend für die User-Experience sein (Auch der Administrator ist in Drupal ein einfacher User).

#teamcomposer

Ja, Composer ist natürlich das bessere, richtigere und angemessenere Tool für eine grosse Drupal-Site. Es ist nur eines von mehreren Kommandozeilen-Tools aber es ist aufwendiger für Anfänger. Hier geht es zur Dokumentation https://www.drupal.org/docs/develop/using-composer/using-composer-with-drupal.

Fazit

Ludwig ist der inklusive, charmante Underdog und repräsentiert als Vorbote einer Vereinfachung gut den Spirit der frühen Drupal-Jahre. Drupal als agiles Produkt ist meiner Meinung nach bis heute unerreicht, wenn es um den Einsatz eines Web-CMS geht. Ich denke da nicht an einfache „Brochure“-Websites, auf denen sich wenig ändert, sondern an Sites, die viele Inhaltstypen mit vielen Feldern, vielen Relationen und viele Benutzerkonten haben. Sites, die relevant in der Welt. Trotz aller Hürden beim Drupal 7 -> 8 Update, gibt es viele, sehr gut verwaltete, grosse und kleine Drupal-Sites, die seit mehr als als 12 Jahren stabil laufen und nachhaltig weiterentwickelt werden.

Und die Antwort auf die Frage ob es Ludwig oder Composer sein soll ist doch ganz einfach – beides muss funktionieren und miteinander harmonieren. Man fängt vielleicht mit Ludwig an und wenn es kompliziert und grösser wird, steigt man um in die Composer-Welt.

Solche Ziele verfolgt auch die Dries erwähnte Site-Builder Initiative.

Gerade diese Nachhaltigkeit wird in Zukunft wichtiger werden. Ich wünsche der Initiative viel Erfolg!

---

tl;dr: Drupal wird nachhaltiger und inklusiver