Ein Rezept für Content First

Content-Management-Systeme sind im Publishing gerade hoch im Kurs und vereinfachen das Publizieren über verschiedene Kanäle. Warum es sich lohnt, seine Prozesse mit den Prinzipien von Content First neu zu denken und welche Rolle dabei Headless CMS spielen können, erfährst du in diesem Artikel.

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 formuliert, 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.» Und 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 Ausgabe­kanals übersetzen lässt. Dies ist leider meist mit Kompromissen verbunden. Mit dem Head­less-CMS-Ansatz versucht man nun, die Kompatibilitä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.

JSON einfach erklärt …
JSON (JavaScript Object Notation) ist ein textbasiertes ­Datenaustauschformat. JSON besteht aus selbstdefinierbaren Namen-Werte-Paaren und kann von Menschen wie auch Maschinen leicht gelesen bzw. interpretiert werden. Im Vergleich mit XML ist JSON leichtgewichtig und sorgt für einen schnellen Datenaustausch. Im Publishing kann JSON genutzt werden, um Schnittstellen von Dritt­systemen – zum Beispiel Weban­wendungen – anzubinden, Daten zu erhalten und ­weiterzuverarbeiten.

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 Ausgabe­kanäle gelangen. Dies wird durch eine Schnittstelle (API) ermöglicht. Im Web und vor allem bei Headless CMS kommen dabei oft sogenannte REST-APIs 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 Bi­bliothek 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-APIs funktionieren im Grundsatz nach diesem Prinzip, mit dem Unterschied, dass sich die Daten natürlich über das Web abrufen lassen. Als Austauschformate kommen meist JSON, HTML oder XML zum Einsatz. REST-APIs 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.

Was ist Strapi?
Das Headless CMS Strapi wird vom gleichnamigen Unternehmen als Open-Source-Lösung weiter­entwickelt und von einer breiten Community unterstützt. Neben der kostenlosen Version bietet das Unternehmen seinen Kunden ­verschiedene bezahlte Pläne, die mehr Funktionen sowie ­verschiedene Supportleistungen enthalten. Auch die Community bietet mittlerweile eine Vielzahl an Plug-ins, die den Funktionsumfang erweitern. strapi.io

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 Einzel­einträ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. 

Was ist eine REST-API?
Die Abkürzung API steht für Application Programming Interface – in der deutschen Sprache sind damit Programmierschnittstellen gemeint. Einfach erklärt dienen diese Schnittstellen dazu, die Kommunikation zwischen verschiedenen Anwendungen zu ermöglichen. So lassen sich beispielsweise Daten oder Dienste anderer Systeme nutzen. REST steht für Representational State Transfer und beschreibt ein spezifisches Programmierparadigma, welches unter anderem bei verteilten Systemen seine Anwendung findet. Dieser Architekturstil baut auf sogenannten Ressourcen auf und wird häufig mit HTTP umgesetzt – in diesem Fall spricht man von RESTful HTTP. Eine Ressource kann zum Beispiel ein User in einem System sein. Diese Ressourcen lassen sich über eine URI identifizieren. Mit den HTTP-Anfragemethoden ­lassen sich Ressourcen abfragen (GET), erstellen (POST), aktualisieren (POST) oder löschen (DELETE).

Im Grunde genommen können also Systeme über diese Schnittstelle miteinander kommunizieren. Es stellt sich nun aber die Frage, in welcher Form Daten bzw. Ressourcen ausgetauscht werden. Im Fachjargon spricht man diesbezüglich von Repräsentationen oder Darstellungsformen. Im Zusammenhang mit REST-APIs werden häufig Formate wie JSON, HTML oder XML verwendet.

Wenn wir von Kommunikation und Datenaustausch schreiben, kommen wir natürlich auch zum Punkt der Sicherheit bzw. des Datenschutzes. Wenn die Möglichkeit bestehen soll, Ressourcen über das Internet abrufen und verändern zu können, müssen diese ­öffentlich verfügbar sein. Es ist jedoch nicht so, dass einfach jeder beliebige Anfrager auch die gewünschten Informationen erhält. ­Schnittstellen lassen sich über verschiedene Authentifizierungs- sowie Autorisierungsverfahren schützen – so kann nur auf eine bestimmte Ressource zugegriffen werden, wenn man im Besitz eines gültigen Schlüssels (Token) ist.