Seiten bestehen aus Blöcken, und Blöcke brauchen Daten. Ein Teil davon steckt in der Block-Instanz selbst - eine Überschrift, ein Absatz, ein Bild. Der Rest lebt in strukturierten Sammlungen, die du einmal definierst und überall wiederverwendest: Modelle, Records, Medien und Formulare.

Modelle und Records

Ein Modell ist ein Schema für eine Inhaltsart: ein Produkt, ein Autor, eine Stellenanzeige, eine Case Study. Ein Record ist ein Eintrag zu diesem Schema. Modelle liegen auf Workspace-Ebene, nicht auf einer Seite - dieselbe Sammlung speist also beliebig viele Seiten und Blöcke.

Modelle definierst du im Workspace, nicht im Frontend-Code. Das ist genau umgekehrt zu Block-Schemas, die Code sind und mit deinem Repo ausgeliefert werden - die Trennung ist Absicht: Form der UI im Code, Form der Daten in cmssy.

Records mit Blöcken verbinden

Blöcke ziehen Records über ein Relationsfeld heran. Eine Relation speichert IDs, keine Kopien - die Delivery-API löst sie beim Rendern zu vollständigen Records auf. Ein einmal bearbeiteter Record aktualisiert sich also überall, wo er auftaucht.

• picked (Standard) - die Redaktion wählt einen Record aus, mit multiple: true auch mehrere. Eine hervorgehobene Case Study; die drei Tarife auf einer Preisseite.
• mode: "all" - das Feld speichert gar nichts; der Block erhält alle Records des Modells, geformt von sort und limit. Ideal für einen Blog-Index oder ein FAQ, das nie nachkuratiert werden soll.

Deshalb funktioniert ein "Neueste Beiträge"-Block weiter, nachdem du einen Beitrag hinzugefügt hast: Er hält eine Abfrage, keinen Schnappschuss.

Medien

Bilder und Dateien liegen in der Medienbibliothek des Workspace, in Ordnern organisiert. Blöcke referenzieren Medien per URL, und jeder Upload bekommt seine eigene gehashte URL - ein hochgeladener Ersatz aktualisiert die Blöcke also nicht, die auf die alte Datei zeigen. Ein Ersetzen an Ort und Stelle gibt es nicht - das Mittel ist, die Blöcke neu zuzuweisen: ein Suchen-und-Ersetzen über die Blockinhalte, wofür der MCP-Server gemacht ist. Uploads, Ordner und Verschiebungen laufen auch über den MCP-Server, womit Massenarbeit an Medien skriptbar wird.

Formulare

Formulare baust du visuell im Workspace; gerendert werden sie von dem Block, an den du sie hängst. Einsendungen landen zurück in cmssy, wo jede einen Status trägt, den du durch deinen eigenen Workflow bewegst.

Das Absenden ist der einzige Schreibvorgang, den dein öffentliches Frontend ohne Token ausführen kann - über die Mutation form.submit der Delivery-API. Alles andere rund um Formulare - anlegen, Einsendungen lesen, Status ändern - erfordert einen autorisierten Client.

Alles ist mehrsprachig

Jedes Feld ist standardmäßig mehrsprachig. Inhalte werden nach Sprachcode verschlüsselt gespeichert, ein Record trägt also alle seine Übersetzungen, und die Delivery-API reicht deinem Frontend die passende für das aktive Locale. Du modellierst Übersetzungen nicht - du füllst sie aus.