Strony składają się z bloków, a bloki potrzebują danych. Część z nich mieszka w samej instancji bloku - nagłówek, akapit, obrazek. Reszta żyje w strukturalnych kolekcjach, które definiujesz raz i używasz wszędzie: modele, rekordy, media i formularze.

Modele i rekordy

Model to schemat dla rodzaju treści: produktu, autora, ogłoszenia o pracę, case study. Rekord to jeden wpis zgodny z tym schematem. Modele żyją na poziomie workspace'u, nie strony, więc ta sama kolekcja zasila tyle stron i bloków, ile chcesz.

Modele definiujesz w workspace, nie w kodzie frontendu. To odwrotnie niż schematy bloków, które są kodem i jadą z Twoim repo - ten podział jest celowy: kształt UI w kodzie, kształt danych w cmssy.

Podpinanie rekordów do bloków

Bloki zaciągają rekordy przez pole relacyjne. Relacja przechowuje id, nie kopie - API dostawcze rozwiązuje je do pełnych rekordów w czasie renderowania, więc rekord zmieniony raz aktualizuje się wszędzie, gdzie występuje.

• picked (domyślne) - redaktor wybiera jeden rekord albo kilka przy multiple: true. Wyróżnione case study; trzy plany na stronie cennika.
• mode: "all" - pole nie przechowuje nic; blok dostaje wszystkie rekordy modelu, układane przez sort i limit. Użyj do indeksu bloga albo FAQ, które nigdy nie ma wymagać ręcznego dokładania.

Dlatego blok "najnowsze wpisy" działa dalej po dodaniu wpisu: trzyma zapytanie, nie migawkę.

Media

Obrazy i pliki żyją w bibliotece mediów workspace'u, poukładane w foldery. Bloki odwołują się do mediów przez URL, a każdy upload dostaje własny URL z hashem - więc wgranie zamiennika nie aktualizuje bloków wskazujących na stary plik. Podmiany w miejscu nie ma, więc lekarstwem jest przepięcie bloków: szukaj-i-zamień po treści bloków, czyli dokładnie to, w czym dobry jest serwer MCP. Wgrywanie, foldery i przenoszenie są dostępne przez serwer MCP, co pozwala oskryptować hurtową robotę na mediach.

Formularze

Formularze budujesz wizualnie w workspace, a renderuje je blok, do którego je podepniesz. Zgłoszenia wracają do cmssy, gdzie każde niesie status, który przeprowadzisz przez własny workflow.

Wysłanie formularza to jedyny zapis, który Twój publiczny frontend wykona bez tokenu - idzie przez mutację form.submit w API dostawczym. Wszystko inne wokół formularzy - tworzenie, odczyt zgłoszeń, zmiana statusu - wymaga autoryzowanego klienta.

Wszystko jest wielojęzyczne

Każde pole jest domyślnie wielojęzyczne. Treść jest przechowywana z kluczem języka, więc jeden rekord niesie wszystkie swoje tłumaczenia, a API dostawcze podaje frontendowi to właściwe dla aktywnego locale. Nie modelujesz tłumaczeń - po prostu je uzupełniasz.