Kategorien
Automatisierung Content Management Systeme Site Builder

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:

Google Trends – https://trends.google.com/trends/explore…

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

Ludwig im Backend: /admin/reports/packages

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.

The Site-Builder Tool/Project Browser initiative. The goal is to implement a site builder tool, including a project browser, which abstracts away the manual process of installation, updates, and dependency resolution – handling those items behind the scenes for the site builder. The end product might be a code-base installed-in-place on the server, or it might be a consolidated tar.gz/zip with the complete codebase to be uploaded to a host. This initiative also has the potential to support the sustainability of the Drupal Association and our community programs, perhaps through the promotion of featured projects (modules, distros, themes) or even hosting providers that the output of the tool could be deployed to. These changes can help Drupal retain its lower to mid-market users, lower the barrier to entry, and lower the cost of ownership for a Drupal site.

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

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


tl;dr: Drupal wird nachhaltiger und inklusiver

Von hagengraf

Ich erstelle bequeme und benutzerfreundliche Orte in virtuellen und physischen Umgebungen.

2 Antworten auf „Drupal mit Composer oder mit Ludwig?“

Danke für den Beitrag:-) Bin selber für klassische Website-Projekte auf Backdrop CMS (also den „Fork“ von Drupal 7) umgestiegen, u.a. wegen der besseren Wiederverwendbarkeit von einmal erstellten Konfigurationen. Allerdings hatte ich ebenfalls kürzlich nach längerer Zeit wieder mit Drupal zu tun (ein kleines Projekt mit Drupal Commerce). Kann ebenfalls bestätigen, dass Drupal jetzt endlich wieder richtig flott läuft. Nutze selber die Kommandozeile, komme als Nichtprogrammierer aber sehr gut zurcht damit. Probierte vor zwei Jahren mal Ludwig aus, damals mussten die zu installierenden Module Ludwig ausdrücklich unterstützen, was natürlich nur wenige Module taten. Ist diese Beschränkung denn jetzt weg?

Die Beschränkung ist immer noch da, es sind aber überraschend viele Module, die von Ludwig unterstützt werden. Ich sehe Ludwig auch eher als Weckruf für Drupal

Kommentar verfassen