Mehrere Websites

Ein Workspace kann mehrere Websites betreiben, etwa eine pro Kundin oder Kunde. Jede Website hat ihre eigenen CMS-Sammlungen. Zwei Websites können also beide eine Sammlung blog haben, ohne dass du Slugs mit dem Kundennamen versehen musst.

Websites und Sammlungen

Jede CMS-Sammlung gehört zu genau einer Website. Verschachtelte Sammlungen gehören immer zur selben Website wie ihre Elternsammlung.
Sammlungs-Slugs sind pro Website eindeutig, nicht pro Workspace. blog darf es in jeder Website einmal geben.
Eine Website kann zusätzlich eine Builder-Site, eine verbundene SDK-Site und Analytics haben. Eine Website ganz ohne diese Teile ist eine gültige reine Content-Website, die externer Code über API-Schlüssel liest.
Builder-Sites und das In-Page-Editing einer verbundenen Site sehen nur die Sammlungen ihrer eigenen Website.
Ein Relationsfeld kann auf eine Sammlung einer anderen Website zeigen. Damit deren Einträge mitgeladen werden, müssen API-Schlüssel und verbundene Sites auch diese Zielsammlung lesen dürfen.

Sammlungen einer Website finden

Websites zeigt die Websites des Workspace. Öffne eine Website und wähle den Tab Sammlungen, dann eine Sammlung, um mit ihren Einträgen zu arbeiten.
Die Brotkrumen-Navigation zeigt Websites › Website › Sammlungen › Sammlung. Mit Websites kommst du zurück zur Übersicht aller Websites.
Eine neue Sammlung entsteht in der Website, die du gerade geöffnet hast.
Hat der Workspace nur eine Website, öffnet der Eintrag in der Seitenleiste direkt diese Website.

Website-Slug

Jede Website hat einen Slug, der aus ihrem Namen erzeugt wird und innerhalb des Workspace eindeutig ist. API-v2-URLs und das SDK benennen die Website damit.
Du findest und änderst ihn unter Websites: Website auswählen, dann Einstellungen › Allgemein.
Eine Änderung des Slugs ändert jede API-v2-URL dieser Website. Verbundene Sites müssen ihren SDK-Client danach mit dem neuen Slug neu generieren und selbst gebaute URLs anpassen.

Public API v2

API v2 nennt in jeder CMS-Adresse die Website:

GET /api/v2/cms/<website-slug>/<collection>
GET /api/v2/cms/<website-slug>/<collection>/<record-slug>

/api/v2/cms/acme/blog und /api/v2/cms/mueller/blog sind zwei verschiedene Sammlungen.
Native Ressourcen wie Events oder Jobs behalten ihre Workspace-weite Adresse, zum Beispiel /api/v2/events.
/api/v2/schema liefert das OpenAPI-Dokument für den API-Schlüssel, und der Ressourcenindex unter /api/v2 führt jede CMS-Sammlung mit ihrer Website auf.

SDK 3.0

@einblick/sdk 3.0 spricht mit API v2. Ein Client ist an eine Website gebunden, deshalb bleiben die Sammlungs-Slugs in deinem Code schlicht. Den typisierten Client für eine Website erzeugst du mit einblick-sdk generate --website <slug>:

npx @einblick/sdk generate --website acme --output app/lib/einblick.generated.ts

Liest der API-Schlüssel nur Sammlungen einer Website, wählt der Generator sie selbst. Liest er mehrere, ist --website <slug> Pflicht, und die Sammlungen der anderen Websites fehlen in der generierten Datei.
Die generierte Datei exportiert EINBLICK_WEBSITE, den Slug, an den der Client gebunden ist. Übergib ihn an createEinblickCmsTags({ website: EINBLICK_WEBSITE }), wenn du gecachte Reads taggst.
Ein von Hand erstellter Client nennt die Website einmal:

import { createEinblickClient } from '@einblick/sdk'
 
const einblick = createEinblickClient({ website: 'acme' })
const posts = await einblick.request('blog', { limit: 10 })

Ein Client ohne Website kann weiterhin native Ressourcen lesen, ein CMS-Read wirft aber EinblickWebsiteRequiredError, noch bevor eine Anfrage rausgeht.
Dashboards, Aggregatoren und Sync-Jobs, die wirklich mehrere Websites umfassen, nutzen den Workspace-Client und nennen die Website pro Aufruf. Kunden-Sites bleiben beim gebundenen Client.

import { createEinblickWorkspaceClient } from '@einblick/sdk'
 
const workspace = createEinblickWorkspaceClient()
const acmePosts = await workspace.request({ website: 'acme', resource: 'blog' })
const mueller = workspace.website('mueller')

API-Schlüssel für mehrere Websites

Ein API-Schlüssel darf Sammlungen mehrerer Websites lesen. Unter Systemeinstellungen → API zeigt das Schlüssel-Sheet neben jeder Sammlung ein Website-Badge, sobald der Workspace mehrere Websites hat.
Das Sheet warnt, wenn ein Schlüssel denselben Sammlungs-Slug aus mehreren Websites liest.
API v1 adressiert Sammlungen nur über den Slug (/api/v1/cms/<slug>). Liest der Schlüssel diesen Slug aus mehreren Websites, scheitert eine v1-Anfrage mit 400 und nennt die betroffenen Websites, statt eine davon zu raten. Stelle solche Aufrufe auf API v2 oder SDK 3.0 um oder gib jeder Website einen eigenen Schlüssel.

Sammlung in eine andere Website verschieben

Mit In Website verschieben… in den Sammlungseinstellungen verschiebst du eine Sammlung in eine andere Website. Ihre verschachtelten Sammlungen ziehen mit.
In der Zielwebsite darf es noch keine Sammlung mit demselben Slug geben.
Nach dem Verschieben enthält die API-v2-URL der Sammlung den Slug der neuen Website. Generiere den SDK-Client jeder Site neu, die sie liest.
Relationen zwischen der verschobenen Sammlung und Sammlungen, die in der alten Website bleiben, werden zu Website-übergreifenden Relationen. Builder-Seiten und In-Page-Editing-Bindings der alten Website finden die Sammlung nicht mehr.