Content First mit dem Headless CMS Strapi

Microsoft-Word, InDesign, die Datenbank der Webseite – das sind nur einige mögliche Orte, an denen Inhalte in einem «klassischen» Publishing-Workflow abgelegt werden können. Doch in welcher Version pflegt man nun die Inhalte? In welcher Datei oder in welchem Tool werden Korrekturen ausgeführt? Diesen Fragen wird man sich unweigerlich stellen müssen, wenn ein klassischer Print-Workflow plötzlich mit weiteren Ausgabekanälen ergänzt werden soll. Bei meiner Leibspeise – den Bündner Capuns – sagt man liebevoll: «Es gibt so viele Rezepte wie Grossmütter.» So ähnlich verhält es sich mit Antworten auf die soeben gestellten Fragen, nur sind es dann meist keine Rezepte, sondern Ansätze und Tools. Mit meinem Rezept oder anders ausgedrückt, mit meiner Publishing-Empfehlung möchte ich neben einem konkreten Ansatz auch das Open-Source-Tool Strapi vorstellen und in einer Artikelreihe die verschiedenen Möglichkeiten im Publishing aufzeigen.

Content First mit Finesse

Content First bedeutet, dass der Inhalt und somit auch die Person, die diesen Inhalt konsumiert, an erster Stelle stehen. Inhalte sollten also immer über dem Layout oder dem Ausgabemedium stehen und so aufgebaut sein, dass sie für den Leser relevant sind. Ansätze wie Print-First oder auch Web-First bergen das Risiko, dass die Inhalte nicht medienneutral aufbereitet werden, sondern bereits durch den jeweiligen Ausgabekanal beeinflusst werden. Ein Klassiker bilden dabei zum Beispiel Verweise auf bestimmte Seiten im Printmedium, die den Weg irgendwie in den Web-Artikel gefunden haben. Oder umgekehrt – überfüllte Bildergalerien, bei denen sich der Leser im Netz selbst einen Reim darauf machen muss, zu welchem Kontext das jeweilige Bild passt. Diese Bilder landen dann oft im Print-Artikel in einem liebevoll gestalteten Bildraster, leider ohne Bezug zum Inhalt. Du denkst dir nun vielleicht: «Das muss doch auch besser gehen.» undUnd damit hast du natürlich auch vollkommen recht.

Abstraktion mit Headless CMS

Um eine medienneutrale Datenhaltung zu gewährleisten, die sich für alle möglichen Ausgabekanäle eignet, hat eine Entwicklung in die Richtung von Headless CMS stattgefunden. Wie der Name bereits vermuten lässt, sind Headless CMS im wahrsten Sinne des Wortes kopflos. Mit Kopf ist in diesem Fall das Frontend gemeint – also die Präsentationsschicht, die Inhalte in einem bestimmten Layout darstellt. Man kann sich natürlich darüber streiten, ob Systeme besser werden, wenn man einfach gewisse Teile oder Funktionen weglässt. In diesem Fall löst diese Abstraktion aber die bereits beschriebenen Probleme, dass Inhalte beispielsweise mit der Print- oder Web-Brille erstellt werden. In klassischen CMS wie Wordpress, Typo3 oder Drupal werden Inhalte in der Regel im Backend – also der eigentlichen Schaltzentrale – verwaltet und im Frontend ausgegeben. Um den Benutzern das Erfassen und Editieren von Content zu erleichtern, werden meist sogenannte WYSIWYG-Editoren zur Verfügung gestellt. Dieses Prinzip funktioniert wunderbar, solange der Content in der Form dargestellt wird, auf welcher die Vorschau basiert. Möchte man die Daten nun in einen anderen Ausgabekanal einspeisen, ist man darauf angewiesen, dass sich die gegebene Struktur in die Form des neuen Ausgabekanals übersetzen lässt. Dies ist leider meist mit Kompromissen verbunden. Mit dem Headless-CMS-Ansatz versucht man nun, die Kompatibiltät für ­verschiedene Ausgabekanäle zu erhöhen, ­indem man die Präsentationsschicht ganz einfach weglässt.

Inhalte mit Struktur

Wer sich mit dem Thema Headless CMS befasst, kommt unweigerlich zum Punkt, an dem er sich mit der Modellierung der Inhalte befassen muss – und das ist auch gut so. Bevor man Inhalte ausgeben kann, müssen diese erstellt werden. Doch, welche Inhalte sollen überhaupt erstellt werden und wie müssen diese aufgebaut sein? Welche Zusatzinformationen (Metadaten) werden benötigt? Wärmen wir nun also unsere Analogie in Bezug auf Publishing-Ansätze und Capuns-Rezepte nochmals auf und überlegen uns, wie ein grundsätzliches Rezept aufgebaut ist. Ein Rezept verfügt zum Beispiel über einen Titel, eine Kurzbeschreibung und ein Tellerbild. Auch die Zutaten, die Mengenangaben sowie die einzelnen Zubereitungsschritte dürfen in einem guten Rezept natürlich nicht fehlen. Mit diesen Überlegungen haben wir nun bereits unser erstes Inhaltsmodell für den Inhaltstyp «Rezept» definiert. Überlegungen zur Content-Strategie und zur Datenmodellierung bilden also den Ausgangspunkt eines Content-First-Prozesses.

Beziehungen und Module

Was ist, wenn wir das soeben definierte Inhaltsmodell genauer anschauen? Wir stellen fest, dass die Zutaten im Rezept selbst wiederum über eine Bezeichnung und allenfalls über ein Produktbild sowie eine kurze Beschreibung verfügen können. Es ist also nichts anderes, als ein weiterer Inhaltstyp, der in einer Beziehung zum Inhaltstyp «Rezept» steht. Der Vorteil solcher Relationen ist, dass eine Zutat nicht in jedem Rezept neu erfasst werden muss, sondern einfach aus einer Sammlung an Zutaten verknüpft werden kann – wir minimieren also Redundanzen in unseren Daten.

Mit dem Prinzip der Modularisierung betrachten wir unsere Inhalte nicht mehr als Ganzes, sondern zerlegen die verschiedenen Bereiche in Module. Diese Module können dann beliebig oft sowie in unterschiedlichen Kontexten verwendet werden.

Inhalte ausspielen, aber wie?

Ich habe bereits erwähnt, dass mit einem Headless CMS das Frontend weggelassen wird. Dies ist nur die halbe Wahrheit. Auch ohne Frontend müssen die Inhalte über einen Weg in die verschiedenen Kanäle gelangen. Dies wird durch eine Schnittstelle (API) ermöglicht. Im Web und vor allem bei Headless CMS kommen dabei oft sogenannte REST-API’s zum Einsatz. Hierbei wird in der Regel eine Anfrage über HTTP an den Server gestellt. So können Ressourcen über eine URL/URI mithilfe bestimmter Methoden abgerufen, verändert oder gelöscht werden. Das Prinzip lässt sich einfach mit dem Beispiel einer Bibliothek erklären. Ein Kunde (Anfrager) betritt die Bibliothek und möchte ein bestimmtes Buch (Ressource) ausleihen. Der Bibliothekar – in diesem Falle die Logik der Schnittstelle –prüft, ob das Buch bzw. die Ressource zur Verfügung steht und ob der Kunde berechtigt ist, das Buch auszuleihen. Ist alles korrekt, kann das Buch ausgeliehen werden. REST-API’s funktionieren im Grundsatz nach diesem Prinzip, mit dem Unterschied, dass sich die Daten natürlich über das Web abrufen lassen. Als Austauschformate kommen in der Regel JSON, HTML oder XML zum Einsatz. REST-API’s zeichnen sich durch eine hohe Flexibilität, Skalierbarkeit sowie Sicherheit aus.

Klassisch, Headless oder beides?

Die typischen Vertreter von klassischen CMS geniessen grosse Bekanntheit. Doch wie sieht es im Bereich der Headless CMS aus? Alle WordPress-Fans kann ich an dieser Stelle beruhigen. Auch dieses CMS kann durch die implementierte REST-API und zusätzlichen Erweiterungen einfach zu einem Headless CMS «umgebaut» werden, genauer gesagt spricht man dann in diesem Fall von einer progressiven Entkopplung (Progressive Decoupling). Auch andere Systeme bieten hybride Möglichkeiten. Georg Obermayr erklärt zum Beispiel in einem seiner Blogbeiträge, wie man mit dem CMS Kirby die Vorteile des Headless-CMS-Ansatzes nutzen kann.

Strapi – Content-Lieferant für alle Kanäle

Mittlerweile gibt es auch eine stattliche Zahl an Vertretern aus den Reihen der Headless CMS, die sich voll und ganz der Abstraktion des Frontends verschrieben haben und als reine Content-Plattform fungieren. Das Tool Strapi ist einer dieser Vertreter, dessen Vorzüge nun etwas genauer beleuchtet werden. Fünf Jahre nach der ersten Veröffentlichung des Projekts auf Github hat das Open-Source-Headless-CMS im letzten Jahr den sogenannten Stable Release herausgegeben und sich dadurch zu einem vielversprechenden Kandidaten gemausert. Strapi besticht durch eine einfache Benutzeroberfläche, um Inhalte zu erfassen sowie durch eine automatische Bereitstellung von API-Endpoints, um die erstellten Inhalte über das Web abzurufen. Die Installation von Strapi ist aktuell nicht ganz so einfach, wie dies zum Beispiel bei den bekanntesten CMS der Fall ist. Mit Hilfe der detaillierten Dokumentation des Herstellers ist das System jedoch schnell aufgesetzt und konfiguriert. Zudem soll nächstens eine Cloud-Version veröffentlicht werden, mit welcher das Selfhosting entfällt.

Content Management im Eigenbau

Ist Strapi erst einmal installiert, ermöglicht es durch die flexible Datenstruktur das Erstellen von individuellen Inhaltsstrukturen. Dies geschieht mit dem sogenannten Content Type Builder. Strapi unterscheidet hier zwischen verschiedenen Content-Typen wie Sammlungen, einzelnen Einträgen und Komponenten. Wie der Name bereits sagt, können Sammlungen im Gegensatz zu Einzeleinträgen mehrere Einträge mit der gleichen Struktur enthalten. Dies kann zum Beispiel eine Sammlung verschiedener Blogbeiträge sein. Komponenten können in ­verschiedenen Sammlungen sowie Einzeleinträgen verwendet werden. Sie erhöhen also die Wiederverwendbarkeit von Datenstrukturen. Ein Content-Typ kann mittels verschiedener Feld-Typen strukturiert werden. So können unter anderem Felder für gewöhnliche und formatierte Texte, Listen ­sowie Bilder hinzugefügt werden. Relationen können ebenfalls ganz einfach mit einem dafür vorgesehen Feld-Typ definiert werden.

Strapi durch Inhalte mit Leben füllen

Die mit dem Content Type Builder definierten Inhaltsmodelle bilden im Grunde das Grundgerüst für unser Headless CMS. In dieses Grundgerüst fliesst dann der eigentliche Content, der in Strapi mit dem Content Manager erfasst und editiert werden kann. Dafür steht ein übersichtlicher Editor zur Verfügung, mit welchem Texte erfasst und mittels Markdown formatiert werden können. Neu lassen sich auch Inhaltsvarianten in verschiedenen Sprachen bzw. für verschiedene Regionen verwalten. Für die Verwaltung von Medien wie Bilder, Videos und Audio-Inhalte stellt Strapi eine einfache Media Library in Form eines Plug-ins zur Verfügung.

Benutzer, Rollen und Rechte

Mit der implementierten REST-API spielt Strapi die eigentliche Stärke eines Headless CMS gekonnt aus. Die mit dem Content Manager erstellten Inhalte können nach deren Veröffentlichung sofort über die jeweiligen API-Endpoints abgerufen werden (z. B. https://strapi-example.ch/articles). Die Daten werden im JSON-Format ausgeliefert und können so einfach im Frontend verarbeitet werden. Mittels Benutzern und Rollen kann der Zugriff auf die verschiedenen Inhalte detailliert gesteuert werden.

Volle Roadmap

Strapi bietet schon jetzt eine einfache Benutzeroberfläche und eine Vielzahl an Funktionen. Die Zahl der Features ist seit dem Stable Release im letzten Jahr stetig gestiegen, weitere sollen mit den nächsten Releases folgen. Ein Blick in die Roadmap zeigt, dass man in Zukunft einige spannende Entwicklungen erwarten darf. Auch die Community liefert stetig neue interessante Plug-ins.

Im nächsten Artikel erfährst du, wie man mit Strapi einen einfachen Content-First-Workflow mit Ausgabekanälen für Web und Print definieren kann.