Inhaltstypen & Einträge

Ein Inhaltstyp ist die Form, die Inhalte annehmen: welche Felder es gibt, wie sie heißen und was hineindarf. Ein Eintrag ist ein Datensatz genau eines Inhaltstyps — ein Blogbeitrag, ein Produkt, eine Person. Inhaltstypen entstehen im Klick-Baukasten unter Inhaltstypen, ohne YAML, ohne TypoScript, ohne Migration.

Inhaltstyp anlegen

Ein Inhaltstyp hat einen Namen, einen Slug und Felder. Der Slug ist der API-Name: er taucht in den URLs der Delivery API auf (/delivery/content/{slug}). Er lässt sich später ändern, dann müssen aber alle Abfragen im Frontend nachgezogen werden.

Empfehlung: lieber wenige, klare Typen. Zwei Typen mit je acht Feldern sind leichter zu pflegen als einer mit zwanzig optionalen Feldern.

Feldtypen

Jedes Feld hat einen Schlüssel (key), unter dem der Wert in data erscheint, sowie Pflicht, Hilfetext und Vorgabewert.

Unter Rich-Text-Feldern zeigt der Editor beim Schreiben Hinweise zur Barrierefreiheit: übersprungene Überschriftenebenen (H2 → H4), eine H1 im Text (die liefert meist schon der Titel), nichtssagende Linktexte wie „hier“, „mehr“ oder eine nackte URL. Die Hinweise sind Empfehlungen und blockieren das Speichern nicht.

Gruppen

Felder lassen sich in Gruppen ordnen — „Stammdaten", „Beschreibung", „Details". Im Editor erscheint jede Gruppe als Abschnitt mit Sprungnavigation; ab drei Gruppen werden daraus Reiter. SEO ist immer ein eigener Abschnitt. In der API bleiben alle Felder flach unter data. Für wiederholbare Strukturen gibt es den Feldtyp Blöcke; für Daten, die in vielen Einträgen gleich sind, einen eigenen Inhaltstyp mit Relation.

Blöcke (Repeater)

Ein Feld vom Typ Blöcke nimmt beliebig viele Inhaltsblöcke in freier Reihenfolge auf — das, was Strapi „Dynamic Zone“ und Payload „Blocks“ nennt. Im Inhaltstyp legst du die Blocktypen fest, jeder mit eigenen Feldern (alle Feldtypen außer Blöcke selbst — eine Ebene reicht). Ein Blog-Artikel bekommt so ein Feld content mit den Blocktypen:

Optional begrenzt Mindestens/Höchstens die Zahl der Blöcke je Eintrag. Im Editor erscheinen die Blöcke als zusammenklappbare Karten mit Icon, Typ und einer Vorschauzeile aus dem ersten Textfeld; sie lassen sich per Griff oder Pfeiltasten sortieren, duplizieren und mit Rückgängig löschen. Fehlende Pflichtfelder stehen am Block, Grenzen unter der Liste — gespeichert wird trotzdem.

In der API ist der Wert eine Liste aus { type, id, data }. Mit expand=media und expand=relations werden Medien und Relationen auch in den Blöcken aufgelöst:

{
  "data": {
    "title": "Relaunch 2026",
    "content": [
      { "type": "text", "id": "5a1c…", "data": { "body": "<p>Warum wir neu gebaut haben …</p>" } },
      { "type": "quote", "id": "8f02…", "data": { "text": "Weniger, aber besser.", "source": "Dieter Rams" } },
      { "type": "image", "id": "c7d9…", "data": {
        "image": { "id": "…", "url": "https://…/buero.webp", "alt": "Büro", "width": 1600, "height": 900 },
        "caption": "Das neue Büro"
      } },
      { "type": "gallery", "id": "e310…", "data": { "images": [ { "id": "…", "url": "…" }, { "id": "…", "url": "…" } ] } }
    ]
  }
}

Im Frontend rendert ein switch über block.type die passende Komponente. Die id ist je Block stabil und eignet sich als Key beim Rendern. Texte in Blöcken landen auch in der Volltextsuche der Delivery API.

Relationen

Eine Relation verweist auf einen oder mehrere Einträge eines anderen Typs: ein Beitrag hat einen Autor (Person), ein Produkt gehört zu einer Kategorie. In der API steht standardmäßig nur die ID; mit expand=relations wird der verknüpfte Eintrag mitgeliefert:

curl "https://entrydeck.app/api/v1/delivery/content/beitrag/relaunch-2026?locale=de&expand=relations,media" \
  -H "x-api-key: $ENTRYDECK_API_KEY"

{
  "id": "…",
  "slug": "relaunch-2026",
  "locale": "de",
  "data": {
    "title": "Relaunch 2026",
    "author": { "id": "…", "slug": "manuel-grasse", "data": { "name": "Manuel Grasse" } },
    "hero": { "id": "…", "url": "https://…/hero-large.webp", "alt": "…", "width": 1600, "height": 900 }
  },
  "seo": { "title": "…", "canonical": "https://muster.de/blog/relaunch-2026", "jsonLd": [ … ] }
}

Relationen werden beim Import über den Content-Mapper ebenfalls aufgelöst — anhand des Schlüssels in der Quelle.

Sprachen

Als übersetzbar markierte Felder existieren je Sprache; alles andere gilt für alle Sprachen gemeinsam. Gespeichert wird je Sprache: Das Sprachsegment im Kopf des Editors wechselt die Übersetzung, fehlende Fassungen sind ausgegraut und werden per Klick angelegt; ungespeicherte Änderungen bleiben beim Wechsel erhalten. Fehlt eine Übersetzung, liefert die API die Standardsprache der Website.

Slug und SEO je Eintrag

Der Slug wird aus dem Titel vorgeschlagen und danach nicht mehr automatisch geändert — sonst brächen veröffentlichte Links. Der Abschnitt SEO im Editor enthält Titel, Beschreibung, Bild, Canonical, noindex, Keywords und Open Graph; die Ampel in der Seitenleiste zeigt je Sprache, ob Titel und Beschreibung gesetzt sind. Die Delivery API baut daraus ein fertiges SEO-Objekt mit JSON-LD.

Status und Workflow

Wer welchen Übergang gehen darf, steuern Rollen und Rechte je Inhaltstyp (etwa content.publish). Jede Änderung landet im Änderungsprotokoll unter Audit-Log, mit Vorher/Nachher der geänderten Felder.

Versionen und Vergleich

Jedes Speichern legt eine Version der Übersetzung an (bis zu 50 je Sprache). Die Seitenleiste zeigt die letzten drei, Alle Versionen öffnet die ganze Liste. Dort lässt sich jede Version vergleichen — mit dem aktuellen Stand oder mit der vorigen Version. Der Vergleich zeigt Feld für Feld, was sich geändert hat: Texte und Rich-Text als Inline-Diff (grün mit + eingefügt, rot mit − gelöscht), Blöcke je Position (Inhalt › Zitat #2 · Text), andere Werte vorher/nachher nebeneinander. „Nur Änderungen“ ist voreingestellt. Vor dem Zurückholen erscheint derselbe Vergleich als Vorschau; der bisherige Stand bleibt als Version erhalten.

API: GET /admin/content-entries/{id}/revisions/{revId}/diff?against=current|{revId} liefert { fields: [{ path, label, kind, before, after, textDiff }], unchanged }.

Kommentare und Erwähnungen

Über Kommentare in der Seitenleiste besprecht ihr Fragen, Hinweise und Freigaben direkt am Eintrag — als Thread mit Antworten, optional an ein Feld geheftet. Mit @Name erwähnt man jemanden aus dem Team; die Person bekommt eine E-Mail mit Link. „Erledigt“ räumt einen Thread aus den offenen Kommentaren, der Zähler am Reiter zeigt, wie viele noch offen sind. ⌘ Enter sendet.

Rechte: comments.read und comments.write (Redakteur, Freigeber, Tenant-Admin). Bearbeiten darf nur der Autor; fremde Kommentare löschen dürfen Autor oder Tenant-Admins (users.read).

Gleichzeitiges Bearbeiten

Öffnet jemand einen Eintrag, hält das Admin eine weiche Bearbeitungssperre: Wer denselben Eintrag danach öffnet, sieht oben „Anna bearbeitet seit 3 Min.“, die Felder sind schreibgeschützt und Speichern wird vom Server mit 423 Locked abgelehnt. Die Sperre endet beim Schließen des Editors oder nach 90 Sekunden ohne Lebenszeichen. Übernehmen darf, wer content.publish besitzt oder wenn die andere Seite seit über zwei Minuten still ist. Das Übernehmen steht im Audit-Log.

Zuweisung an Websites

Ein Eintrag wird einer oder mehreren Websites zugewiesen. Nur zugewiesene und veröffentlichte Einträge erscheinen in der API der jeweiligen Website. So bleibt ein Standort auf der Hauptseite und der Karriereseite identisch, ohne kopiert zu werden. Statt jeden Eintrag einzeln zuzuweisen, kann eine Website auch per Ausspielregel alle passenden Einträge übernehmen — siehe Inhalte auf Websites ausspielen.

Listen und Filter

Die Liste unter Inhalte wählt über Chips Gruppe oder Inhaltstyp (mit Eintragszahl) und filtert darunter nach Status, Sprache und Sortierung; Suche, Filter und Sortierung stehen in der Adresszeile und lassen sich als Link weitergeben, Ansichten sichern eine Kombination unter eigenem Namen. Kästchen links wählen mehrere Einträge für Statuswechsel auf einmal. ⌘ K öffnet die Befehlspalette mit Volltextsuche über alle Einträge.