Das Headless CMS Cockpit

Die Open Source Software Cockpit ist ein selbst gehostetes schlankes Headless CMS. Mit einer intuitiven und reduzierten Verwaltungsoberfläche, einer NoSQL-Datenbank und einer simplen Installations-Routine eignet sich Cockpit ideal für schnelle und einfache Headless-Konzepte.

Dashboard des Headless CMS Cockpit

Cockpit wird von dem Hamburger Dienstleister Agentejo bzw. dessen Inhaber Artur Heinze seit 2013 entwickelt, hat also bereits eine längere Geschichte und ist dementsprechend stabil. Das Projekt steht auf GitHub mit MIT-Lizenz zur Verfügung und wird kontinuierlich aktualisiert.

#Cockpit für Autoren

Die Verwaltungs-Oberfläche von Cockpit ist aufgeräumt und bietet Administratoren und Autoren ein Dashboard, Settings, Accounts und eine Asset-Verwaltung an. Für Inhalte sind drei unterschiedliche Kategorien vorgesehen:

  • Collections: Für Gruppen von Einträgen wie Blogs oder News.
  • Singletons: Für alleinstehende (statische) Seiten.
  • Forms: Für beliebige Daten, die über öffentliche Formulare gesendet werden.

Bevor Autoren Inhalte erstellen können, muss der Administrator die Inhaltstypen in Form von Collections, Singletons oder Forms anlegen und die zugehörigen Eingabefelder definieren. Für die Definition der Inhalte steht ein intuitiver Formular-Manager bereit, der knapp 30 vordefinierte und konfigurierbare Feld-Typen anbietet. Die Auswahl reicht von einfachen Text-Feldern über Markdown- und WYSIWYG-Eingabefelder bis hin zu wiederholbaren Einträgen (Repeater) oder Grid-Fields.

Field-Manager von Cockpit

Die Aufgabe des Administrators (bzw. Entwicklers) besteht vor allem darin, sich mit den Feld-Typen vertraut zu machen und den Content sinnvoll zu modellieren. Die meisten Felder können dabei mit Hilfe von JSON konfiguriert werden. Die einzelnen JSON-Optionen für die Felder findet man in der Dokumentation zu den Field-Typen. Bei einem Select-Field werden beispielsweise die einzelnen Auswahl-Werte (Options) wie in diesem Beispiel über JSON konfiguriert:

{
    "cls": "",
    "options": "Option 1, Option 2, Option 3",
    "default": "Option 2"
}

Da die Dokumentation vergleichsweise sparsam ausfällt und einige Hinweise nur im Forum zu finden sind (Beispiel Image- und Asset-Fields), kann die Konfiguration der Felder bei Cockpit im Detail allerdings etwas mühsam werden.

Für Singletons und Collections wird derselbe Formular-Manager verwendet. Etwas Verwirrung könnte am Anfang bei den Forms entstehen, denn für öffentliche Formulare werden keine Formular-Felder definiert, sondern lediglich ein Formular-Name vergeben. Das Formular dient anschließend als API-Endpunkt, über den beliebige Daten als Wertepaare abgespeichert und abgerufen werden können. Über die Oberfläche von Cockpit können die Daten nicht bearbeitet oder modelliert werden. Stattdessen liegt es allein in der Verantwortung des Entwicklers, öffentliche Formulare zu erstellen und die Daten im entsprechenden Format an Cockpit zu senden. Sinnvoll ist die Verwendung beispielsweise für Kontaktformulare. Wenn es dagegen um klassische Content-Verwaltung geht, greift man auf Singletons oder Collections zurück.

Nachdem die Eingabefelder einmal konfiguriert sind, kann der Autor seine Inhalte direkt in Cockpit über standardisierte Formulare erstellen. Die Oberfläche von Cockpit ist dabei recht reduziert, klar strukturiert und einfach in der Handhabung. Eine große Einarbeitung der Autoren ist nicht nötig. Alternativ kann auch eine externe Autorenoberfläche angeschlossen werden, die die Inhalte dann per API an Cockpit sendet.

Bei Cockpit lässt sich auch eine Seitenvorschau einrichten. Dazu muss der Entwickler allerdings erst einmal ein Frontend erstellen und die URL zum Frontend in den Eigenschaften einer Collection oder eines Singletons eintragen. Wie bei Headless-Systemen üblich hat der Autor insgesamt nur recht eingeschränkte Möglichkeiten, die Darstellung der Inhalte oder den Seitenaufbau zu beeinflussen. Bei Headless-Architekturen gilt immer zu beachten, dass die Gestaltungshoheit tendenziell vom Content-Manager auf die Entwicklung übertragen wird.

#Cockpit für Entwickler

Cockpit ist eine PHP-Anwendung und setzt auf dem von Agentejo entwickelten Micro-Framework Lime auf. Per Default nutzt Cockpit eine SQLite-Datenbank, alternativ kann auch MongoDB genutzt werden. Das Dashboard basiert noch überwiegend auf JQuery, externe PHP-Bibliotheken werden zugunsten einer schlanken Applikation nur sehr sparsam eingesetzt. Die Dokumentation von Cockpit fällt etwas dünn aus, daher wird man als Entwickler recht viel im Forum von Cockpit recherchieren und den Code des schlanken Systems studieren.

Durch die Verwendung einer SQLite-Datenbank benötigt Cockpit keine besondere Installation. Die Software wird einfach auf den Server geschoben, anschließend wird unter your-cockpit-domain.com/install ein Installations-Script aufgerufen. Sofern die Schreibrechte korrekt gesetzt und die Requirements erfüllt sind, kann man sich danach unmittelbar als Admin-User anmelden.

Cockpit läuft grundsätzlich ohne weitere Konfiguration. Bei Bedarf kann das System jedoch über eine YAML-Konfiguration angepasst werden. Damit können beispielsweise neue Nutzergruppen erstellt, CORS konfiguriert oder SMTP-Mails eingerichtet werden. Die YAML-Konfiguration erreicht man im Dashboard über den Menüpunkt Settings und Custom Settings. In der Dokumentation findet man noch ein älteres PHP-Beispiel, das als Vorlage für die YAML-Konfiguration dienen kann. Ein YAML-Beispiel sieht dann etwa so aus:

# Cockpit settings
languages:
    en: English
site: "https://cms.domain"
groups:
    editor:
        $admin: false
        $vars:
            finder.path: /storage/upload/
        cockpit:
            backend: true
            finder: true

Kern von Cockpit ist wie bei allen Headless CMS die API. Der Zugriff auf die API wird über eine Token-Verwaltung geregelt, die in den Settings unter API Access erreichbar ist. Neben dem Master-Key können dort auch einzelne Custom-Keys generiert werden, bei denen wiederum die Zugriffsrechte über Rules auf einzelne API-Endpunkte eingeschränkt werden können:

Cockpit API Token generieren

Zusätzlich zur Verwaltung der API-Keys können für jede Collection und für jedes Singleton die einzelnen Aktionen (view, edit, create, delete) festgelegt werden, für die eine Authentifizierung über den API-Token notwendig ist. Per Default sind die öffentlichen Rechte (also API-Zugriffe ohne Authentifizierung durch einen Token) natürlich unterbunden. Durch die Kombination der Token-Verwaltung und der Permissions ist eine feingranulare Zugriffskontrolle möglich.

Permissions für Inhalte bei Cockpit setzen

Für die eigentlichen API-Calls liefert die Dokumentation diverse JavaScript-Beispiele. Es gibt einen allgemeinen Cockpit-Endpunkt mit Zugriff auf die User-Verwaltung, auf die Nutzer-Authentifizierung oder auf die Asset-Verwaltung. Daneben gibt es Endpunkte für die Collections, Singletons und Forms. Allgemeine Informationen zu einer Collection können mit folgendem Beispiel abgerufen werden:

var token = 'your-token-here';
fetch('http://localhost/cms/cockpit/api/collections/collection/yourcollectionname?token=' + token)
.then(function(response) {
   return response.json();
})
.then(function(myJson) {
   console.log(JSON.stringify(myJson));
});

Die Inhalte einer Collection können bei dem API-Call beliebig gefiltert werden:

var token = 'your-token-here';
fetch('http://localhost/cms/cockpit/api/collections/get/yourcollectionname?token=' + token, {
    method: 'post',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
        filter: {published:true},
        fields: {fieldA: 1, fieldB: 1},
        limit: 10,
        skip: 5,
        sort: {_created:-1},
        populate: 1, // resolve linked collection items
        lang: 'de' // return normalized language fields (fieldA_de => fieldA)
    })
})
.then(res=>res.json())
.then(res => console.log(res));  

Beispiele für API-Calls findet man in der Dokumentation sowohl in der API-Beschreibung (Beispiel Collections-API), als auch in der Dokumentation der Module jeweils am Ende der Beschreibung (Beispiel Collections-Modul).

Sofern man nicht täglich mit APIs und Headless-Konzepten arbeitet, wird man sich als Entwickler erst einmal in die Details von Cockpit einarbeiten müssen. Viele Informationen und Hilfestellungen findet man dabei im Forum, beispielsweise eine Liste mit offiziellen und inoffiziellen Addons für Cockpit. Durch die schlanke Code-Struktur und die reduzierte und intuitive Oberfläche dürfte der Einstieg in die Headless-Welt mit Cockpit jedoch immer noch vergleichsweise einfach sein.

#Cockpit für Nicht-Entwickler

Wie alle Headless-Systeme arbeitet Cockpit im Kern mit einer API und richtet sich damit ausschließlich an Entwickler. Eine Erstellung von Webseiten in Eigen-Regie wie bei WordPress ist mit Headless-Systemen generell nicht möglich. Auch für Code-Einsteiger dürften Headless-Systeme vergleichsweise herausfordernd sein. Die Arbeit mit APIs ist vor allem bei Frontend-Entwicklern beliebt, die sich auf neue Frameworks wie React oder Vue spezialisiert haben.

#Preise

Cockpit ist kostenlos und wird unter der MIT-Lizenz angeboten. Wer professionelle Hilfe sucht, stellt am besten eine Anfrage an den Cockpit-Entwickler Artur Heinze bzw. dessen Agentur Agentejo.

#Wann eignet sich Cockpit?

Cockpit gehört neben Directus (PHP), Strapi (Node), Squidex (ASP) und Gentics Mesh (Java) zu den wenigen selbstgehosteten Headless CMS und zeichnet sich durch eine besonders schlanke Architektur aus. Vor allem die Verwendung einer SQLite-Datenbank machen den Start mit Cockpit zu einem Kinderspiel. Wer in die Welt der Headless-CMS einsteigen möchte, auf PHP und JavaScript setzt oder schnell mal einen eigenen Content-Service aufbauen will, der dürfte mit Cockpit genau richtig liegen.

Ob Cockpit das richtige Content Management System ist, kann nur eine individuelle Analyse zeigen. Wer dabei auf eine externe Unterstützung zurückgreifen will, der kann sich an unseren Kooperationspartner SUTSCHE wenden. SUTSCHE gehört zu den wenigen Dienstleistern, die nicht implementieren und so die CMS-Auswahl unabhängig im Interesse des Kunden begleiten können.

© by Sebastian Schürmanns, 2017 - 2024. All Rights Reserved. Built with Typemill.