Drupal als Content-Hub: einmal pflegen, überall ausgeben

Der Bedarf zeigt sich selten als Wunsch nach einem Content-Hub. Er zeigt sich als Ärger. Ein Produkt ändert sich, und die Änderung muss an vier Stellen nachgezogen werden. Eine davon wird vergessen. Ein Kunde findet im Händlerportal eine andere Angabe als auf der Website und fragt nach, welche gilt.

Dahinter steht eine gewachsene Ordnung. Jeder Kanal wurde für sich gebaut und bekam eine eigene Pflege. Solange es ein Kanal war, fiel das nicht auf. Mit jedem weiteren wächst der Aufwand, und mit ihm die Zahl der Abweichungen.

Der Kern eines Content-Hubs ist ein Wechsel der Sicht. Ein Inhalt ist keine Seite, sondern ein Datensatz. Eine Produktbeschreibung besteht aus Bezeichnung, Kurztext, Langtext, Anwendungsgebiet, Bildern und Dokumenten. Jedes dieser Felder hat eine Bedeutung, die unabhängig davon gilt, wo es erscheint.

Die Website setzt aus den Feldern eine Seite zusammen. Die App zeigt Bezeichnung, Kurztext und ein Bild. Das Händlerportal ergänzt Dokumente, die nur angemeldete Händler sehen. Der Inhalt ist derselbe, die Darstellung gehört dem Kanal.

Für die Redaktion ist das eine Umstellung. Sie gestaltet nicht mehr eine Seite, sondern füllt Felder. Was sie dabei gewinnt, ist Verlässlichkeit: Eine Änderung gilt überall.

Drupal ist um strukturierte Inhalte herum gebaut. Inhaltstypen und Felder werden in der Oberfläche angelegt, Beziehungen zwischen Inhalten ebenso. Ein Produkt verweist auf seine Produktfamilie, auf Anwendungsbeispiele und auf Ansprechpartner. Schlagworte und Auswahllisten werden zentral geführt.

Alles, was so angelegt ist, steht über die Schnittstelle JSON:API bereit, die seit Version 8.7 zum Kern gehört¹. Sie beachtet die Berechtigungen: Ein Inhalt, den ein Nutzer in der Oberfläche nicht sehen darf, wird ihm auch über die Schnittstelle nicht geliefert.

Drupal ist bisher das System, mit dem wir am häufigsten gearbeitet haben. Aus dieser Erfahrung wissen wir, dass die Eignung des Systems die kleinere Frage ist. Die größere ist das Inhaltsmodell.

Ein Inhaltsmodell beschreibt, welche Arten von Inhalten es gibt, aus welchen Feldern sie bestehen und wie sie zusammenhängen. Es entsteht nicht am Bildschirm, sondern im Gespräch mit den Menschen, die die Inhalte pflegen und brauchen.

Ein gutes Modell ist kanalneutral. Ein Feld heißt Kurztext und nicht Text für die Startseite. Es ist so fein wie nötig: Eine technische Angabe, nach der gefiltert werden soll, braucht ein eigenes Feld. Eine Angabe, die nur gelesen wird, kann im Fließtext stehen.

• Welche Arten von Inhalten gibt es, und wer pflegt sie?
• Welche Angaben werden gefiltert, sortiert oder verglichen?
• Welche Inhalte hängen zusammen?
• Was wird übersetzt, was gilt für alle Sprachen?
• Wer darf welche Inhalte sehen?

Ein Content-Hub führt nicht alle Angaben selbst. Preise und Bestände entstehen in der Warenwirtschaft, technische Produktdaten im PIM-System, Kontakte im CRM. Der Content-Hub bezieht diese Angaben und ergänzt, was kein anderes System führt: Beschreibungen, Anwendungsbeispiele, Ratgeber, Bilder.

Für jede Angabe wird festgelegt, welches System sie pflegt. Alle anderen zeigen sie an und ändern sie nicht. Diese Regel verhindert, dass der Content-Hub selbst zur fünften Fassung wird.

Jeder Kanal bezieht die Inhalte über die Schnittstelle und entscheidet selbst über die Darstellung. Die Website kann dabei von Drupal selbst dargestellt werden. Das ist kein Widerspruch zum Content-Hub. Das System, das die Inhalte führt, darf auch ein Kanal sein.

Für jede Anbindung ist zu klären, wie aktuell die Inhalte sein müssen. Eine Website darf eine Änderung nach einigen Minuten zeigen. Ein Preis im Shop muss sofort stimmen. Danach richtet sich, ob Inhalte zwischengespeichert, bei Änderung gemeldet oder bei jedem Aufruf abgefragt werden.

Mit mehreren Ländern kommt die Frage hinzu, was übersetzt wird und was für alle gilt. Je Feld wird das festgelegt. Die Bezeichnung eines Produkts wird übersetzt, das Bild gilt überall, die Zulassung gilt nur in bestimmten Ländern. Ein Inhalt muss nicht in jeder Sprache vorliegen.

Rechte regeln, wer was ändern darf. Die zentrale Redaktion pflegt die Inhalte, die für alle gelten. Die Redaktion eines Landes übersetzt und ergänzt eigene Inhalte. Ein Händler sieht im Portal die Dokumente, die für ihn freigegeben sind. Diese Regeln gelten für jeden Kanal, weil sie an der Quelle liegen und nicht in der Darstellung.

Der häufigste Grund ist die doppelte Pflege, die nicht endet. Der neue Hub ist da, aber der Shop wird weiter von Hand gepflegt, weil die Anbindung verschoben wurde. Nach einem Jahr gibt es eine Fassung mehr als vorher.

Der zweite Grund ist ein Modell, das die Website abbildet. Felder heißen nach Stellen auf der Seite, Texte enthalten Gestaltung. Für den zweiten Kanal sind solche Inhalte unbrauchbar. Der dritte Grund ist eine Redaktion, die nicht eingebunden war. Sie erhält ein System mit vielen Feldern und versteht nicht, wofür. Dann füllt sie das Nötigste aus, und die Inhalte bleiben dünn.

Ein Unternehmen mit einer Website und einem Newsletter braucht keinen Content-Hub. Der Aufwand für Inhaltsmodell und Schnittstellen zahlt sich erst aus, wenn mehrere Kanäle dieselben Inhalte zeigen. Auch dort, wo die Kanäle verschiedene Inhalte brauchen, etwa eine Karriereseite und ein Shop, bringt eine gemeinsame Quelle wenig.

In diesen Fällen genügt es, das CMS so anzulegen, dass der Weg offen bleibt: Inhalte in Feldern, klare Inhaltstypen, ein System mit Schnittstelle. Kommt später ein Kanal hinzu, ist die Grundlage vorhanden.

Strukturierte Inhalte sind die Grundlage für den Einsatz von Sprachmodellen. Ein Assistent, der Kunden Auskunft gibt, braucht geprüfte Inhalte mit klarer Bedeutung, Sprache und Stand. Er braucht die Fundstelle, um seine Antwort zu belegen, und die Berechtigung, um nur zu zeigen, was der Fragende sehen darf.

Ein Content-Hub liefert das. Wer heute seine Inhalte ordnet, schafft damit die Voraussetzung für Anwendungen, die morgen darauf aufbauen. Die Reihenfolge lässt sich nicht umkehren: Ein Sprachmodell ordnet keine Inhalte, die niemand gepflegt hat.