Drupal auf der Suche nach dem besten redaktionellen Erlebnis

Die redaktionelle Erfahrung wird für jedes CMS immer wichtiger. Benutzer möchten mehr Kontrolle, aber einfachere Schnittstellen. In Drupal, einem der größten und beliebtesten OpenSource-CMS auf dem Markt, geht die Suche nach der besten Erfahrung bis heute weiter. Verschiedene Ansätze werden von der Community getestet und mit jeder Ausgabe werden einige neue Ansätze untersucht und einige verworfen. Aus der Perspektive einer Drupal-Agentur ist es ziemlich interessant, diesen Prozess zu beobachten.

Lassen Sie uns erkunden, wie sich die redaktionelle Erfahrung in Drupal bis heute entwickelt hat und in welche Richtung sie sich bewegt.

Die Anfänge von Drupal

Anfangs wurden Drupal-Seiten auf Knoten aufgebaut. Stellen Sie sich einen Knoten wie einen Artikel oder eine Seite in einem typischen CMS vor. Ein Knoten hatte einen Titel und einen Hauptteil. Man gab dem Knoten einen Titel und fügte den gesamten Inhalt in ein großes Textfeld ein. Typischerweise schrieben die Leute den Inhalt der Seite in das Haupttextfeld – dies war meist Text, aber man konnte dort alles Mögliche einfügen (HTML, Bilder etc.). Sehr schnell integrierten die Leute WYSIWYG-Editoren in den Hauptteil (CKEditor, TinyMCE und andere wurden als von der Community beigesteuerte Module integriert). Man konnte nun eine ziemlich komplexe Seite ohne HTML-Kenntnisse erstellen.

Die WYSIWYG-Editoren waren so beliebt, dass in Drupal 7 CKEditor in den Kern von Drupal aufgenommen wurde.

Auf der Datenbankseite war alles  immer noch recht einfach. Eine Knotentabelle mit Titel und eine zusätzliche Tabelle für den Hauptteil. So blieb Wordpress pretty much bis heute. In Drupal jedoch ging die Evolution weiter. 

Drupal 6 - Die Dominanz von CCK & Templating

Zur Zeit von Drupal 5 wurde ein zunächst kleines Modul erstellt, das in Drupal 6 die Spielregeln vollständig änderte (das Content Construction Kit, auch bekannt als CCK).

CCK war ein beigesteuertes Modul, das es ermöglichte, zusätzliche Felder zu Knoten hinzuzufügen. Das klingt nicht sehr aufregend, war es aber. Das absolut brillante CCK-Modul ermöglichte es den Benutzern, verschiedene Felder (Zahl, Text, Boolean, Auswahl, etc.) hinzuzufügen und es erstellte eine separate Datenbanktabelle für jedes Feld. Die Tabellenspalten entsprachen dem, was man darin speichern wollte (Eine Dezimalzahl, ein Float, ein Varchar, ein Text, etc.). Darüber hinaus wurde das Feld zum Standardinhaltsformular hinzugefügt. 

Das war großartig, weil man ein Formular mit mehreren Feldern erstellen und dann die Daten in einer vom Entwickler vorgefertigten Vorlage anzeigen konnte (ein Bild rechts, Statistiken links, lange Texte unten – sowas in der Art). So baute man Seiten in Drupal. Der Redakteur musste das Layout nicht mehr im WYSIWYG entwerfen. Man konnte einfach ein Formular mit Feldern ausfüllen und die Vorlage erledigte den Rest. 

Darüber hinaus konnte man nun in SQL nach bestimmten Knoteninhalt suchen. Zum Beispiel, wenn man einen Knoten des Typs Stadt erstellte und ihm ein Dezimalfeld für die Bevölkerung hinzufügte, konnte man alle Städte mit einer Bevölkerungszahl größer oder kleiner als ein festgelegter Wert suchen. 

Sehr schnell nach CCK wurde ein weiteres Modul erstellt - das Views-Modul. Views erlaubte es den Benutzern, Abfragen in der Admin-Oberfläche zu erstellen. Man konnte nun eine Liste von Städten nach Bevölkerungszahl geordnet mit Titel und Teaser sowie anderen Daten erstellen, ohne eine Zeile Code zu schreiben. Dies war ein massiver Durchbruch, der es Entwicklern ermöglichte, sehr überzeugende Websites zu erstellen, ohne eine Zeile Code zu schreiben. 

CCK war so populär, dass es in Version 7 in Drupal integriert wurde, und Views folgte in Drupal 8.

So wurden Drupal-Websites eine Weile lang erstellt. Viele werden immer noch so gebaut.

Drupal 7 - Erste Versuche mit Seitenlayouts 

Ab Drupal 7 galten Felder als Standard. Templating war jedoch für die Community und Kunden nicht ausreichend. Drupal-Entwickler begannen nach Lösungen zu suchen, um mehr Kontrolle über die Inhaltsanzeige nur mit der Benutzeroberfläche zu ermöglichen.

Der Hauptgrund für die Suchbemühungen liegt in der Art und Weise, wie Websites gebaut werden. Die Kenntnis darüber, dass ein weiterer Klick die Wahrscheinlichkeit verringert, dass der Kunde zum Inhalt gelangt, verbreitete sich. Der Ansatz, eine Seitenleiste zu haben und Informationen auf Seiten zu verteilen, war nicht mehr interessant. Lange scrollbare Seiten entstanden.

Der Aufstieg von langen Landingpages mit Inhalt in Abschnitten begann irgendwo um 2010. Es war jedoch das Mobiltelefon, das die Seitenleiste effektiv tötete. Man konnte einfach kein Untermenü in eine Seitenleiste auf dem Mobilgerät einfügen. Man musste nun alles auf einer langen scrollbaren Seite mit mehreren Abschnitten unterbringen (das Scrollen auf Mobilgeräten ist viel einfacher als das Klicken auf Links). Und jeder Abschnitt musste interessant, fesselnd und anders sein.

Drupal-Entwickler begannen nach Lösungen zu suchen, wie man es den Editoren einfacher machen könnte, Abschnitte auf Seiten zu erstellen.

Die anfänglichen Lösungen waren:

• Panelizer - ein Modul, das auf einem anderen (Panels) basiert, das die Knotenanzeige effektiv übernahm. Anstatt nur Felder einzufügen, konnten Sie nun Ihre Seite entwerfen, um Blöcke, Felder, statische Bilder, Ansichten und verschiedene andere Elemente, die Drupal rendert, zu enthalten. Editoren konnten das „Standard“ vorgegebene Layout Knoten für Knoten überschreiben. Die Lösung war großartig und erhielt viel Aufmerksamkeit in der Drupal-Welt.
• Paragraphs - etwas spät zur Party bei Drupal 7, aber Paragraphs schlug dennoch ein. Es begann sehr schnell an Popularität zu gewinnen. Der Hauptgrund dafür war, dass es die beiden Welten verband: die Drupal Formularerstellungserfahrung und die Freiheit, Blöcke hinzuzufügen, wobei die Benutzerfreundlichkeit für die Editoren beibehalten wurde, die die obigen Lösungen nicht hatten. 
• Context - Context, ein allgemeineres Modul, das Benutzern einen Mechanismus zum Handeln von Kontexten (z.B. auf welcher Seite man sich befindet, welcher Benutzer oder welche Rolle man hat, etc.) bot. Mit diesen Bedingungen konnte man Reaktionen hinzufügen (z.B. diesen Block anzeigen, diese Einstellung festlegen). Context wurde eine Zeit lang sehr weit verbreitet, um Blöcke auf Seiten anzuordnen. Wenn ich auf dieser Seite bin, möchte ich diese Blöcke sehen. Der Nachteil war, dass man die Layouts von einem zentralen Ort aus verwaltete, Administratorrechte zur Verwaltung der Layouts benötigte und die Benutzeroberfläche nicht einfach war. Nicht geeignet für große Websites.
• Blockreference - ein einfaches, aber leistungsstarkes Modul, das es ermöglicht, Blöcke von einem Knoten zu referenzieren und sie effektiv übereinander zu stapeln. Diese Lösung erhielt nicht viel Aufmerksamkeit.

Aktueller Stand in Drupal 8 und darüber hinaus

Drupal 8, als sehr großes Neuschreiben von Drupal, hat das Spielfeld ein wenig eingeebnet und der Community die Möglichkeit gegeben, erneut darüber abzustimmen, wie Seiten erstellt werden sollten. 

Blockreference erhielt keine Version für D8, hauptsächlich weil das Entityreference-Modul nun im Kern von Drupal 8 war und Blöcke zu Referenzen wurden. Man könnte theoretisch Seiten so erstellen, indem man das verwendet, was Drupal von Haus aus bietet, aber das hat sich nicht durchgesetzt.

Context konnte in D8 nicht viel Verwendung finden und hat bis heute keine stabile Version.

Paragraphs - anfänglicher Gewinner

Das Paragraphs-Modul ging als klarer Gewinner hervor. Es war sehr schnell stabil und wurde über ein Jahr lang zum De-facto-Standard in Drupal 8. Mit über 140k Installationen läuft es mittlerweile auf einem Drittel aller Drupal-Websites. Es ist auch erwähnenswert, dass beliebte auf Drupal 8 erstellte Drupal-Distributionen Paragraphs als Grundlage ihrer Inhaltserstellungserfahrung wählten. Diese wären insbesondere Thunder - eine Distribution für Verlagshäuser und Droopler - für den Aufbau von Unternehmenswebsites. 

Hier ist ein Überblick darüber, wie Paragraphs in Drupal 8 funktioniert. Es wird auch viel Arbeit geleistet, um die redaktionelle Erfahrung im Experimentellen Widget weiter zu verbessern.

Panelizer wurde in den Kern verschoben (wurde zu Layout Builder)

Panelizer nahm einen anderen Weg. Es hinkte hinter Paragraphs in Bezug auf die Installationsnummern hinterher, aber aufgrund seiner Beliebtheit in D7 wurden Arbeiten unternommen, um es in den Kern von Drupal zu migrieren (genau wie CCK in D7). Es war jedoch erst in Drupal 8.5, dass Layout Builder verfügbar wurde (als experimentelles Modul). In Drupal 7.8 wurde es stabil. 

Layout Builder bietet große Flexibilität und ein großes Versprechen, aber die Benutzeroberfläche ist auch zum Zeitpunkt des Schreibens noch weit davon entfernt, selbsterklärend zu sein (man benötigt ein wenig Schulung, da viele Dinge nicht offensichtlich sind). Es gibt auch keine klare „beste Praxis“, wie man jetzt Inhalte verwalten und was die Seiten bilden sollte. Integrationen hinken hinterher, vor allem mit Suchmodulen. 

Derzeit gibt es keinen klaren Gewinner und eine beste Praxis ist noch nicht etabliert. Es gibt das Paragraphs-Modul mit 100k Installationen, mehreren Integrationen und einer klaren Benutzeroberfläche. Andererseits gibt es Layout Builder, das im Kern von Drupal ist, was eine unglaubliche Stärke darstellt. 

Dennoch gibt es viele Module, die die Zeit nicht überstanden haben und aus dem Kern entfernt wurden.

Gutenberg (ein WordPress-Editor)

Zuletzt, aber nicht weniger wichtig, ist das Gutenberg-Projekt. Es ist der neueste der interessanten Editoren in Drupal. Es wurde aus WordPress portiert, wo es der Haupteditor ist.

Gutenberg ist ein auf React basierender Editor, der das gesamte Bearbeitungserlebnis übernimmt und dem Benutzer ein WYSIWYG-ähnliches Erlebnis bietet. Es unterscheidet sich im Ansatz zu Paragraphs und Layout Builder darin, dass es das Layout oder die Entitäten nicht in der Datenbank speichert, sondern das generierte HTML speichert. Sie erstellen den Inhalt mit einem WYSIWYG-Editor und das resultierende HTML wird gespeichert. Dies macht es zu einem echten lesbaren WYSIWYG für Maschinen (automatische Updates oder Migrationen solcher Inhalte könnten problematisch sein). Dennoch wird es immer besser in Drupal integriert. Mit etwa 900 Installationen ist es keineswegs mit den beiden oben genannten vergleichbar, aber die Geschwindigkeit der Einführung ist beeindruckend. Sehen Sie sich einen kurzen Überblick über Gutenberg in Drupal an.

Wie Sie sehen können, gibt es keinen eindeutigen Gewinner. Die Drupal-Community testet noch verschiedene Ansätze zum Aufbau von Websites und zur Stärkung der Redakteure. Einerseits ist das fantastisch, weil der Wettbewerb dazu beiträgt, dass die beste Lösung gewinnt. Andererseits sind die Bemühungen der Entwickler über mehrere verschiedene Ansätze verteilt, was den Fortschritt verlangsamt. Was ist das Beste? Ich weiß es nicht.