EmDash aktualisieren

Dieser Guide ist für Site-Betreiber: Personen, die eine auf EmDash aufgebaute Site betreiben und sie auf eine neuere Version bringen wollen. Er deckt das Paket emdash und @emdash-cms/cloudflare ab. Plugin-Pakete haben einen eigenen Guide, Plugins auf Ihrer Site aktualisieren, und Änderungen an eigenen Collections und Feldern sind in Eine deployed Site weiterentwickeln abgedeckt.

Releases und Versionsnummern

EmDash wird vor Version 1.0 veröffentlicht, und seine Versionsnummern folgen zwei Regeln:

• Ein Patch-Release, zum Beispiel 0.35.0 zu 0.35.1, enthält Bugfixes und kleine Verbesserungen.
• Ein Minor-Release, zum Beispiel 0.35 zu 0.36, enthält neue Features und jede Breaking Change. Eine Breaking Change ist in ihrem Release-Eintrag mit Breaking markiert, und der Eintrag nennt die Aktion, die sie von Ihnen verlangt.

emdash und @emdash-cms/cloudflare werden zusammen veröffentlicht und teilen eine Versionsnummer. @emdash-cms/cloudflare hängt von der exakt passenden emdash-Version ab, aktualisieren Sie die beiden Pakete daher in einem Schritt. Plugin-Pakete wie @emdash-cms/plugin-forms haben eigene Versionsnummern und deklarieren die minimale emdash-Version, die sie brauchen.

Die Releases-Seite hat einen Eintrag pro Paket und Version. Vor einem Update lesen Sie die emdash-Einträge zwischen Ihrer installierten Version und dem Ziel sowie denselben Bereich für @emdash-cms/cloudflare, wenn die Site auf Cloudflare läuft.

Bevor Sie aktualisieren

Erstellen Sie ein wiederherstellbares Datenbank-Backup und ein separates Medienspeicher-Backup. EmDashs JSON-Export kann eine Site nicht wiederherstellen, und Core-Migrationen haben keinen betrieblichen Undo-Schritt. Backups und Wiederherstellung beschreibt den nutzbaren Wiederherstellungspunkt für jede Datenbank.

Prüfen Sie die Node.js-Version auf dem Rechner, der die Site baut, und bei einer Node.js-Bereitstellung auf dem Server. Erste Schritte listet die unterstützten Versionen.

Die Pakete aktualisieren

Die Befehle unten nutzen pnpm und eine Site aus einem Cloudflare-Template. Bei einer Node.js-Bereitstellung lassen Sie @emdash-cms/cloudflare weg.

Deployen und überprüfen

Deployen Sie den Build wie jede andere Änderung. Der folgende Befehl deployt eine Cloudflare-Site; bei einer Node.js-Bereitstellung starten Sie den Serverprozess mit dem neuen Build neu.

pnpm wrangler deploy

Mit dem Standard-Laufzeit-Migrationsmodus auto wendet die deployed Site ausstehende Core-Migrationen bei ihrer ersten Anfrage an. Um sie anzuwenden, bevor neuer Code Traffic erhält, und um die deployed Datenbank danach zu prüfen, folgen Sie Core-Datenbankmigrationen verwalten. Ihr Befehl emdash migrate --check beendet sich mit Non-Zero, wenn die deployed Datenbank ausstehende oder unbekannte Migrationen für die installierte Version hat.

Nach dem Deploy öffnen Sie das Admin, laden mindestens eine öffentliche Seite, bearbeiten und veröffentlichen einen Wegwerf-Eintrag und laden eine Wegwerf-Mediendatei hoch und abrufen sie. Wenn die Site geplante Aufgaben oder sandboxed Plugins nutzt, prüfen Sie auch diese Pfade.

Hinweise für bestimmte Releases

Die meisten Releases brauchen nichts über die Schritte oben hinaus. Die Einträge unten decken Releases ab, die Daten geändert haben, die EmDash bereits speicherte, und sagen, wann das eine Aktion von Ihnen braucht.

Geändert: Referenzfelder binden an Relations

Ein reference-Feld hielt früher die ID des Zieleintrags in einer Spalte der Collection-Tabelle und nannte seine Ziel-Collection in einer Feldoption, die das Admin-Panel nicht setzen konnte.

Ein Referenzfeld ist jetzt ein Eintragswähler, der von einer Relation gestützt wird, und seine Links leben außerhalb der Collection-Tabelle. Das Update bindet jedes Referenzfeld, das eine Ziel-Collection nannte, an eine neue Relation und kopiert die Eintrags-IDs in seiner Spalte als Links hinein, sodass das Feld ein Wähler mit intakter Auswahl wird. Die Spalte bleibt stehen und das Update löscht nichts.

Ein Feld bleibt ungebunden, wenn es:

• keine Ziel-Collection nennt oder eine nennt, die nicht mehr existiert
• als searchable oder indexed markiert ist
• den Relations-Slug {collection}_{field} braucht und dieser Slug bereits vergeben ist
• in verschiedenen Locales desselben Eintrags unterschiedliche Einträge auswählt, bei irgendeinem Eintrag

Der letzte Punkt betrifft, wo Links leben. Ein Link gehört zur Übersetzungsgruppe eines Eintrags, sodass eine Auswahl von allen seinen Übersetzungen geteilt wird, während die alte Spalte pro Locale war. Ein Feld, dessen Locales widersprechen, hat keine einzelne Auswahl zum Übernehmen — sie zusammenzuführen würde jeder Locale die Einträge der anderen geben, und eine Locale-Antwort zu wählen würde den Rest verwerfen — daher lässt das Update das Feld in Ruhe und beide Werte in der Spalte lesbar.

Zwei Fälle, die wie Widerspruch aussehen, sind es nicht. Locales, die eigene Übersetzungen eines Eintrags nennen, haben diesen Eintrag einmal ausgewählt, sodass das Update das Feld bindet und der Link zu jeder eigenen Version der Locale auflöst. Eine Locale, die nichts ausgewählt hat, widerspricht keiner anderen Locale, sodass das Update das Feld bindet und die eine Auswahl der Gruppe für jede Übersetzung gilt, einschließlich der leeren.

Ein ungebundenes Feld verhält sich weiter wie zuvor. Seine Spalte hält die Eintrags-ID, der Wert speichert und lädt, und das Feld kann weiterhin indexiert und als Inhaltslisten-Filter genutzt werden. Im Eintragseditor rendert es als Textfeld statt als Wähler.

Was soll ich tun?

Öffnen Sie einen Eintrag in jeder Collection, die ein Referenzfeld hat. Ein Feld, das als Wähler rendert, braucht nichts. Für ein Feld, das noch als Textfeld rendert, folgen Sie Ein Feld ohne Relation binden, das die Relation erstellt und die gespeicherten IDs des Feldes als Links kopiert. Auf einer Multi-Locale-Site klären Sie, auf welchen Eintrag jede Übersetzung zeigen soll, bevor Sie binden, da das Binden eine Auswahl für alle behält.

Wenn die Site nach einem Update bricht

• Der Build schlägt fehl, oder eine eigene Seite fehlerhaft zur Laufzeit: Lesen Sie die mit Breaking markierten Release-Einträge für die übersprungenen Versionen und nehmen Sie die genannten Änderungen vor.
• Ein Plugin lädt nicht: Lesen Sie den eigenen Release-Eintrag des Plugins und Plugins auf Ihrer Site aktualisieren.
• Ein Fehler nennt eine Astro-API oder ein @astrojs/*-Paket: EmDash erfordert Astro 6 oder neuer. Astros Upgrade-Guide erklärt, wie Sie astro und seine offiziellen Integrationen zusammen aktualisieren.
• Um zur vorherigen Version zurückzukehren, installieren Sie die passenden vorherigen Paketversionen neu und deployen Sie dieses Artefakt erneut. Neuinstallieren macht Core-Migrationen nicht rückgängig. Wenn das vorherige Artefakt die migrierte Datenbank nicht nutzen kann, stoppen Sie Traffic und stellen Sie die Pre-Update-Datenbank und das Artefakt zusammen wieder her; stellen Sie Medien nur wieder her, wenn das Update sie geändert hat.