Marktübersicht Hybrid CMS

Kaum ein Trend hat den Markt der Content Management Systeme in den letzten Jahren so stark beeinflusst wie die Headless Architektur. Die darstellungsneutrale Verwaltung von Content und dessen Ausspielung über ein Application Programming Interface (API) ist bei Entwicklern ausgesprochen beliebt und kann einige praktisches Problem lösen. So ist es nicht verwunderlich, dass inzwischen sehr viele traditionelle Content Management Systeme auf den Zug aufgesprungen sind und eine Headless-Nutzung entweder als Feature, oder gleich als Produkt-Variante anbieten. Jenseits der Entwickler-Szene kommen Anwender bei den vielen Begriffen jedoch schnell durcheinander. Wo liegen also die Unterschiede und worauf sollte man achten?

#Decoupled CMS und Hybrid CMS

Die Idee hinter der Headless-Architektur ist nicht neu. Sie folgt Konzepten wie dem "Separation of Concerns" und dem generellen Trend hin zum Microservice. Dieser Trend hat andere Software-Bereiche bereits vor Jahren erreicht.

Da diese Konzepte weit verbreitet sind, war der Sprung auf den Headless-Zug für einige traditionelle Content Management Systeme auch nicht so groß wie man denken könnte. Denn einige Enterprise-CMS wie CoreMedia oder auch FirstSpirit haben die Systeme intern schon immer streng voneinander getrennt und über eine API-Architektur miteinander verbunden. Solche Content Management Systeme werden hin und wieder auch als decoupled CMS bezeichnet.

Die Anbieter solcher decoupled CMS konnten ihre APIs vergleichsweise schnell ausbauen oder gleich eine Headless-Lösung als Produkt-Variante anbieten. Für solche Produkte hat sich auch der Begriff des "Hybrid CMS" eingebürgert. Im Klartext: Mit einem Hybrid-CMS kann man sowohl ein fertiges Endprodukt wie eine Webseite erstellen. Man kann das System aber auch Headless nutzen und die Inhalte darstellungsneutral über eine API ausspielen.

#Verwirrende Vielfalt

Inzwischen haben viele weitere traditionellen Content Management Systeme nachgezogen und bieten mehr oder weniger ausgereifte APIs für die Headless-Nutzung an. All diese "traditionellen" Content Management Systeme könnte man als "Hybrid CMS" bezeichnen. Aufgrund der großen Konjunktur des Headless-Trends reklamieren jedoch viele dieser eher traditionellen Systeme den Begriff "Headless CMS" auch für sich. Umgekehrt stehen manche neue Anbieter wie beispielsweise Contentful dem Begriff "Headless CMS" eher kritisch gegenüber und bezeichnen ihr Angebot lieber als Content Infrastructure oder als Content Platform. Auch der Begriff des Content Service fällt in diesem Zusammenhang sehr oft.

Dieser "Kampf um Begrifflichkeiten" hat leider dazu geführt, dass Außenstehende die Angebote für sich kaum noch sinnvoll sondieren können. Darin kann jedoch auch eine Chance liegen, denn ob "Headless", "Hybrid", "Content Service" oder "Infrastructure" sollte bei der Auswahl eines CMS ohnehin keine zentrale Rolle spielen. Stattdessen sollte man die eigenen Anforderungen an das "Web Content Management" möglichst klar definieren und dann schauen, welche Architektur am besten passt.

#Problemfelder traditioneller CMS

Viele traditionelle Web Content Management Systeme sind immer noch sehr stark auf die Verwaltung von Webseiten ausgerichtet. Dabei haben zahlreiche CMS in den letzten Jahren Autoren-Features entwickelt, die eine visuelle Bearbeitung der Webseite ohne starke Abstraktionen ermöglichen. Ein gutes Beispiel ist WordPress. Mit dem Gutenberg-Editor und den Plänen für ein Full-Site-Editing (FSE) schlägt das beliebte CMS einen Weg ein, den Enterprise-Systeme wie der Adobe Experience Manager (AEM) schon vor Jahren abgeschlossen haben. Mit solchen Systemen lassen sich Webseiten relativ intuitiv und frei gestalten, ohne dass ein Entwickler eingeschaltet werden muss.

Wenn solche Systeme nun auch Headless-Features anbieten, dann liegt das Problem oft weniger in der Technik, sondern vielmehr im Mindset der Anwender. Denn wer es gewohnt ist, visuell zu arbeiten und Webseiten weitesgehend selbst zu gestalten, der wird sich schwer damit tun, diese visuelle Repräsentation aufzugeben und stattdessen die Inhalte strukturiert und darstellungsneutral über Formulare zu erfassen. Doch genau darum geht es bei dem Headless-Ansatz: Man erstellt die inhalte nicht für eine bestimmte Webseite, sondern neutral für die Verwendung in den unterschiedlichsten Szenarien.

Abgesehen von möglichen technischen und konzeptionellen Unzulänglichkeiten mancher nachträglich integrierter "Headless"-APIs kann man das Problem traditioneller CMS mit Headless-Architektur auf folgende Regel herunterbrechen können: Je stärker sich Redakteure an ein visuelles Arbeiten gewöhnt haben und je stärker ihre Spielräume in Bezug auf die Gestaltung eines Endprodukts sind, desto größer ist der Bruch beim Umstieg auf eine Headless-Architektur.

#Problemfelder von Headless Systemen

Bei den reinen Headless-Systemen sieht es genau umgekehrt aus. Mit ihnen lassen sich die Inhalte nahezu beliebig strukturieren und organisieren. Und aufgrund des jüngeren Alters sind die Systeme in der regel leichtgewichtig, ohne historischen Ballast und technisch sauber aufgestellt. Per Definition fehlt jedoch bei den meisten Headless-CMS die visuelle Präsentation der Inhalte. Zwar lässt sich in der Regel eine Seitenvorschau konfigurieren. Ein Block-Editing, andere Formen des visuellen Arbeitens oder auch die eigenständige Erstellung von Microsites sind jedoch nur bei den wenigsten Headless Systemen möglich.

Hinzu kommen weitere bekannte Einschränkungen. Beispielsweise sind Headless-CMS auf die reine Content-Verwaltung spezialisiert. Für alle anderen Funktionen wie zum Beispiel für die Realsierung von Shops müssen Dritt-Systeme genutzt werden. Das ist im Sinne der Headless-Architektur natürlich kein Nachteil. Die Konsequenz einer stärkeren Abhängigkeit von Entwicklern und IT-Abteilungen muss bei der Auswahl jedoch bewusst sein.

#Headless-Angebote traditioneller CMS

Die traditionellen Content Management Systeme haben sehr unterschiedlich auf den Headless-Trend reagiert. Drupal ist das Headless-Thema beispielsweise sehr offensiv angegangen und bietet verschiedene Headless-Distributionen an. Dagegen hat Joomla! erst mit Version 4 im August 2021 eine umfangreiche REST-API vorgestellt. Der Umfang und die Art der APIs ist ebenfalls sehr variabel: Manche Systeme bieten neben der REST-Api auch eine ausgereifte GraphQL-API an. Andere beschränken sich auf einfache Read-Only-APIs. Die gleiche Vielfalt herrscht bei den angebotenen Authentifizierungsmethoden, die von klassichen API-Keys über modernere Web-Tokens bis hin zu einer einfachen Basic-Authentication reichen. Die folgende Liste soll einen ersten Überblick bieten. Im Anschluss werden ausgewählte Angebote noch einmal mit weiterführenden Links kurz charakterisiert.

#Adobe Experience Manager (AEM)

Ähnlich wie andere Enterprise CMS unterstützt auch AEM einen Betrieb als Headless CMS. Dabei wird zwischen den Content-Services und einer GraphQL-API unterschieden. Das Prinzip der Content Services wurde mit den Sling Model Exporters in AEM 6.3 eingeführt. Es handelt sich um eine REST-API, die die Inhalte traditioneller AEM-Seiten ausgibt. Zusätzlich gibt es eine CRUD-API für Assets. Die GraphQL-API ermöglicht dagegen einen Zugriff auf Content-Fragmente und ähnelt dadurch stärker einem reinen Headless-Ansatz. Auf diesen APIs baut auch der SPA Editor auf, mit dem sich moderne Single Page Applications mit Frontend-Frameworks wie Angular oder React erstellen lassen. Die Authentifizierung erfolgt bei AEM über Web Tokens (JWT). Adobe selbst stellt umfangreiche Tutorials zum Headless-Einsatz von AEM zur Verfügung.

#CoreMedia

CoreMedia ist ein etabliertes Enterprise Content Management System von der CoreMedia AG aus Hamburg. Auf CMSStash gibt es eine Review zu CoreMedia. Das System ist unter anderem durch seine gute Integration mit Shop-Systemen wie Hypris und WebSphere bekannt. CoreMedia arbeitet mit einem eigenen Content-Server, sodass die Verwaltung der Inhalte und die Darstellung als Webseite schon in der Grund-Architektur getrennt sind. Entsprechend bietet CoreMedia seit einiger Zeit eine Headless-Installation des Systems an. Interessant dürfte für viele sein, dass CoreMedia bei der API auch die neue GraphQL-Syntax unterstützt.

#CraftCMS

CraftCMS gehört zu den Newcomern im PHP-Bereich und eignet sich vor allem für den Mittelstand und für Commerce-Seiten. CraftCMS bietet zwar keine fertige Headless-Distribution an, es gibt jedoch mehrere Erweiterungsmöglichkeiten für einen Headless-Einsatz. Dazu zählt die Element-API, die sich recht einfach zu einer Read-Only JSON-API ausbauen lässt. Außerdem kann eine vollständige REST-API entwickelt werden. Eine GraphQL-API lässt sich sogar ohne Konfiguration und Eigen-Entwicklung mit dem CraftQL-Plugin erstellen. Es existiert ein ausführlicher Video-Kurs zum Einsatz von Craft als Headless CMS. Einführung von GraphQL-Mutations: https://craftcms.com/blog/2020

#Drupal

Für Drupal gibt es ein JSON-API-Modul, das inzwischen Bestandteil des Drupal Core ist. Daneben gibt es ein RESTful Webservice Modul, ein GraphQL-Modul und ein OpenAPI-Modul (Swagger). integriert, das einen Headless-Ansatz mit Drupal vereinfacht. Inzwischen gibt es mehrere Headless-Distributionen wie zum Beispiel Narwhal von Codelab42, das Community-Projekt contentacms oder die beiden Distributionen Reservoir und Headless Lightning von Acquia. Der Drupal Gründer Dries Buytaert hat außerdem einen langen Artikel verfasst, wie man Drupal entkoppeln kann. https://thebrainfiles.wearebrain.com/how-to-quickly-configure-drupal-as-a-decoupled-api-first-system-8730a3623388 Dries: https://dri.es/drupal-is-api-first-not-api-only and https://www.mediacurrent.com/blog/decoupling-drupal-easier-you-think/

#Evoq9

Das Enterprise Content Management System Evoq 9 folgt einer Headless und Decoupled Architektur mit einer API für den Zugriff auf Inhalte, die von der so genannten Liquid-Content-Cloud geliefert werden, ein auf Microsoft Azure basierender Dienst. Die Liquid Content Cloud ist der kopflose (headless) Teil und Evoq9 ist der Kopf des CMS. Damit ist Evoq9 ein vollständiges, aber entkoppeltes Enterprise CMS. Im Unterschied zu ähnlichen Systemen wie eZ oder FirstSpirit nutzt Evoq jedoch einen externen Cloud-Service für die Content-Speicherung, was auf dem CMS-Markt eher selten ist.

Evoq9 ist ein kommerzielles Produkt des Unternehmens DNN Evoq. Vor 2013 hieß das Unternehmen DotNetNuke, was gleichzeitig der Name eines bekannten Open-Frameworks auf Basis von ASP.NET ist.

#eZ

eZ ist ein traditionelles Enterprise Content Management System mit einer recht langen Geschichte. eZ Platform, das Herzstück von eZ Enterprise, besteht hauptsächlich aus einem Repository und aus einer Benutzeroberfläche für die Verwaltung der Inhalte. Laut dem Anbieter kann eZ out of the box als Headless CMS genutzt werden, da die Plattform entkoppelt ist, aber immer noch alle notwendigen Komponenten für ein CMS beinhaltet. eZ ist ein selbst gehostetes Open-Source System für große Unternehmen und komplexe IT-Landschaften.

#FirstSpirit

FirstSpirit ist ebenfalls ein traditionelles Enterprise Content Management System mit einer recht langen Geschichte. Auf CMSstash gibt es eine kurze Review zu FirstSpirit. Das Unternehmen hinter FirstSpirit ist die e-Spirit AG, die im Jahr 1999 gegründet wurde. Seit 2004 verfolgt FirstSpirit das Konzept einer Content-Integrations-Plattform, die es Nutzern erlaubt, Inhalte aus verschiedenen Quellen in eine Art digitalen Content Hub zu integrieren. Das Unternehmen bewirbt die Plattform als decoupled CMS und hat im Jahr 2016 eine CaaS-Erweiterung publiziert, die den kompletten Inhalte und einzelne Inhalts-Schnipsel über eine API im JSON-Format ausliefert.

#Ghost CMS

Beim Thema API und Headless fällt einem sofort das auf Node.js basierende Ghost-CMS ein (zur Review zu Ghost CMS). Tatsächlich war die Node-API bislang jedoch mit dem Admin-Bereich (Ember.js) und dem Template-System (Handlebars) verheiratet und nicht separat nutzbar. Im Januar 2019 hat Ghost die Entkopplung der Systeme verkündet, sodass das CMS mit seiner REST-API nun auch für Headless-Architekturen und JAMstack-Webseiten genutzt werden kann.

#Joomla!

Joomla! hat mit Version 4 eine REST-API für Web-Services eingeführt. Die Endpunkte decken alle wichtigen Kern-Funktionen von Joomla! ab. Zusätzlich kann die API auch über einen neuen Plugin-Typ von Entwicklern genutzt werden.

Sofern es sich nicht um öffentlichen Seiten oder Ressourcen handelt, erfordert die Nutzung der API eine Authentifizierung über klassische API-Keys. Dafür können im Admin-Bereich sogenannte Super Admin API Token generiert werden.

Für den schnellen Einstieg eignet siche der Überblick im Joomla! Magazin sowie ein Tutorial mit GitHub-Repository von Astrid Günther.

Angesichts des jungen Erscheinungsdatums der Web-Services (August 2021) muss man wohl noch einige Zeit warten, bis sich der Service etabliert hat und weitere Informationsangebote hinzugekommen sind. Da fast alle anderen Content Management Systeme beim Thema API und Webservices schon deutlich weiter sind, macht eine Wahl von Joomla! für Headless-Szenarien derzeit noch keinen Sinn.

#Kentico Cloud

Kentico ist ein etablierter CMS provider. In 2016 hat das Unternehmen die Kentico Cloud veröffentlicht. Kentico Cloud bietet "Kentico Draft" für die Content-Produktion, "Kentico Deliver" für die Auslieferung des Contents über eine API und "Kentico Engage" für Analytics und Personalisierungen. Kentico ist im Jahr 2004 als traditioneller CMS Anbieter auf Basis der ASP.NET Technologie an den Start gegangen.

#Kirby

Das kleine Flat File CMS Kirby hat mit Version 3 eine vollständige REST-API eingeführt und das Dashboard mit Vue.js vom System entkoppelt. Als Datenbasis können sowohl Files, als auch traditionelle Datenbanken oder jede andere Form des Repositories genutzt werden. Gleichzeitig können über eine Basic-HTTP-Authentication auch externe Webseite auf die Inhalte von Kirby zugreifen. Eine Generierung von API-Keys ist allerdings nicht (out of the box) vorgesehen, damit fehlt ein Kern-Element vollständiger Headless-Architekturen. Auf CMSstash gibt es eine Review zu Kirby.

#Plone

Plone ist ein etabliertes Python CMS für den Enterprise-Bereich. Neben der intern plone.api gibt es seit einiger Zeit auch eine Erweiterung für eine REST-API, mit der sich Headless-Konzepte realisieren lassen. Die REST-API soll laut der Plone-Roadmap für 2019 in Version 5.2 in den Core übernommen werden. Derzeit ist die Version 5.2 als Release Candidate verfügbar.

#TYPO3

Bei TYPO3 wird der Headless-Ansatz im Rahmen der PWA-Initiative verfolgt. Aus dieser Initiative ist unter anderem eine Headless-Extension hervorgegangen, die eine JSON-Content-API bereitstellt (read only). Ergänzend dazu gibt es API-Erweiterungen für die Extensions news, solr, powermail und gridelements. Aufbauend auf der Headless-Extension gibt es ein Modul, bei dem die Headless-API im Frontend mit Nuxt.js kombiniert wird. Nuxt ist ein beliebtes Frontend-Framework für die Server-seitige Generierung von Webseiten basierend auf Vue.js und Node.js. Zu dem Modul existiert eine eigene ausführliche Dokumentation. Zumindest auf dem Papier gibt es außerdem Pläne für eine GraphQL-API in Zusammenarbeit mit der Persistance Initiative. Aus der Initiative scheinen bislang jedoch noch keine konkreten Projekte hervorgegangen zu sein.

#WordPress

WordPress bietet seit Version 4.7 eine relativ vollständige REST-API an, die auch Headless-Ansätze ermöglicht. Es gibt vereinzelte Headless-Projekte für WordPress auf GitHub wie das WordPress React Starter-Kit sowie diverse Tutorials, zum Beispiel die Anleitung auf dev.to zur Entwicklung eines Headless WordPress mit React. Auf CMSstash gibt es eine Review zu WordPress.

WordPress Headless Form Submission: https://css-tricks.com/headless-form-submission-with-the-wordpress-rest-api/

• https://css-tricks.com/just-how-niche-is-headless-wordpress/

#Wagtail

Auch der Python-Newcomer Wagtail bewirbt auf seiner Webseite einen Headless-Einsatz, allerdings ist die Dokumentation zur Wagtail-API derzeit nicht aufrufbar. Dafür gibt es einen Blog-Beitrag zur Nutzung der GraphQL von Wagtail und diverse Blog-Posts darüber, wie man das Wagtail-eigene StreamField auch per API nutzen kann.

• https://www.fabian-keller.de/blog/how-to-choose-headless-cms-developers-perspective/
• https://engineering.3ap.ch/post/headless-cms-journey/
• Blog about headless implementations: https://deliverystack.net/2020/07/20/introducing-deliverystack-net/