Schema einer bereitgestellten Website weiterentwickeln

EmDash speichert Sammlungen, Felder und Taxonomien in der Datenbank neben den Inhalten. Verwenden Sie diese Anleitung, um das live Inhaltsmodell zu ändern, ohne es mit einem Code-Deploy, einem erstmaligen Seeding oder einer EmDash-Core-Migration zu verwechseln. Die Beispiele verwenden Cloudflare D1; die gleiche Trennung gilt für jeden Datenbankadapter.

Was ändert was

Eine Website durchläuft vier verschiedene Workflows. Jeder berührt eine andere Ebene:

Die Seed-Datei nimmt nur an der dritten Zeile teil. Sie wird einmal angewendet, wenn die Datenbank leer ist und der Setup-Assistent nicht abgeschlossen wurde. Das Bereitstellen einer geänderten Seed-Datei gegen eine bestehende Datenbank bewirkt nichts — die Weiterentwicklung des Schemas einer live Website geschieht immer über das Admin-Panel oder die API.

Schema im Admin-Panel ändern

Das Admin-Panel ist der primäre Weg, um eine bereitgestellte Website weiterzuentwickeln. Öffnen Sie Content Types im Admin und fügen Sie Sammlungen und Felder hinzu, bearbeiten oder entfernen Sie sie. Änderungen treten sofort in Kraft — die Content API, der Loader und die Bearbeitungsoberfläche lesen das Schema zur Laufzeit aus der Datenbank.

Siehe Sammlungen & Felder für die verfügbaren Feldtypen, Validierungsregeln und Widget-Optionen.

Nach der Änderung des Schemas regenerieren Sie die TypeScript-Typen, die Ihre Templates verwenden. Der Befehl emdash types liest das Schema von einer laufenden Instanz, sodass er direkt auf die bereitgestellte Website zeigen kann:

npx emdash types --url https://example.com

Schema von der CLI ändern

Die emdash schema-Befehle kommunizieren über die REST API mit einer laufenden Instanz, sodass sie gegen eine bereitgestellte Website genauso funktionieren wie gegen das lokale Dev. Authentifizieren Sie sich einmal mit dem Device Flow:

npx emdash login --url https://example.com

Alternativ erstellen Sie ein API-Token im Admin unter Einstellungen → API-Tokens und übergeben es mit --token oder der Umgebungsvariable EMDASH_TOKEN — nützlich für CI.

Dann entwickeln Sie das Schema mit den gleichen Befehlen weiter, die Sie lokal verwenden würden:

npx emdash schema add-field posts subtitle --type string --label "Subtitle" --url https://example.com
npx emdash schema remove-field posts legacy_field --url https://example.com
npx emdash schema create projects --label Projects --url https://example.com

Diese Befehle können in ein Skript eingecheckt werden, damit jede Umgebung die gleiche geordnete Änderung erhält. Die Befehle sind nicht automatisch idempotent: Das erneute Ausführen von create oder add-field gegen ein bereits existierendes Objekt kann fehlschlagen. Inspizieren Sie das Ziel mit emdash schema list oder get, protokollieren Sie, welche Umgebung jeden Schritt abgeschlossen hat, und stoppen Sie beim ersten Fehler.

Siehe die CLI-Referenz für die vollständige Befehlsliste.

Seed-Datei synchron halten

Die in Ihren Build eingebettete Seed-Datei bestimmt, womit eine frische Datenbank initialisiert wird: eine neue Preview-Umgebung, ein Disaster-Recovery-Rebuild oder ein zweites Deployment derselben Website. Wenn das Seed noch den Starter-Blog beschreibt, während die Produktion sich zu etwas anderem entwickelt hat, bootstrapt jede frische Umgebung mit dem falschen Modell.

Der Build bettet die erste gefundene Seed-Datei ein unter .emdash/seed.json, dem Pfad in package.json#emdash.seed oder seed/seed.json. Wenn keine vorhanden ist, wird ein eingebautes Standard-Seed (das Starter-Blog-Modell) eingebettet, und astro dev gibt eine Warnung aus.

Nach der Weiterentwicklung des Schemas einer bereitgestellten Website exportieren Sie das Live-Modell zurück in Ihr Repository. emdash export-seed liest eine lokale SQLite-Datei, und wrangler d1 export erstellt eine aus der bereitgestellten D1-Datenbank:

npx wrangler d1 export emdash-db --remote --output=./prod.sql
sqlite3 prod.db < prod.sql
npx emdash export-seed --database prod.db > .emdash/seed.json

Das exportierte Seed enthält die Einstellungen, Sammlungen, Taxonomien, Menüs und Widget-Bereiche der Live-Website. Fügen Sie --with-content hinzu, um Einträge einzuschließen. Committen Sie die aktualisierte .emdash/seed.json zusammen mit dem Code, der vom neuen Schema abhängt, damit eine frische Umgebung immer zu einem Modell bootstrapt, das der Code versteht.

Änderungen in einer Preview-Umgebung proben

Eine destruktive Schema-Änderung (Entfernen eines Feldes, Umstrukturierung einer Sammlung) wird am sichersten gegen eine Wegwerfkopie der Produktion geprobt.

Von einem Fehler erholen

• Ein Feld wurde versehentlich entfernt. Die Spalte und ihre Daten sind aus der Live-Datenbank verschwunden. Stellen Sie sie aus einem D1 Time Travel Point-in-Time-Backup wieder her, oder fügen Sie das Feld erneut hinzu und stellen Sie seine Werte aus einem früheren wrangler d1 export wieder her.
• Eine frische Umgebung wurde mit dem falschen Modell gebootstrapped. Das eingebettete Seed war veraltet oder fehlte. Aktualisieren Sie .emdash/seed.json (siehe Seed-Datei synchron halten), bauen Sie neu und richten Sie das Deploy auf eine leere Datenbank, um erneut zu bootstrappen.
• Schema und Templates stimmen nicht überein. Deploys und Schema-Änderungen sind unabhängig, also ordnen Sie sie bewusst: additive Schema-Änderungen (neue Sammlung, neues optionales Feld) zuerst, dann der Code, der sie verwendet. Für Entfernungen deployen Sie zuerst den Code, der das Feld nicht mehr verwendet, dann entfernen Sie das Feld.