EmDash を更新する

このガイドはサイト運用者向けです。EmDash 上に構築されたサイトを動かし、より新しいリリースへ移したい人向けです。emdash パッケージと @emdash-cms/cloudflare を扱います。プラグインパッケージには独自のガイド サイト上のプラグインをアップグレードする があり、独自のコレクションとフィールドの変更は デプロイ済みサイトを進化させる で扱います。

リリースとバージョン番号

EmDash はバージョン 1.0 より前にリリースされ、バージョン番号は次の 2 つの規則に従います。

• パッチリリース（例: 0.35.0 から 0.35.1）はバグ修正と小さな改善を運びます。
• マイナーリリース（例: 0.35 から 0.36）は新機能とあらゆる破壊的変更を運びます。破壊的変更はリリースエントリで Breaking とマークされ、エントリはあなたに求めるアクションを述べます。

emdash と @emdash-cms/cloudflare は一緒にリリースされ、1 つのバージョン番号を共有します。@emdash-cms/cloudflare は一致する正確な emdash バージョンに依存するため、2 つのパッケージを 1 ステップで更新してください。@emdash-cms/plugin-forms のようなプラグインパッケージは独自のバージョン番号を持ち、必要な最小 emdash バージョンを宣言します。

リリースページ にはパッケージとバージョンごとに 1 エントリがあります。更新前に、インストール済みバージョンからターゲットまでの emdash エントリを読み、サイトが Cloudflare 上で動く場合は @emdash-cms/cloudflare についても同じ範囲を読んでください。

更新の前に

復元可能なデータベースバックアップと、別途のメディアストレージバックアップを取ってください。EmDash の JSON エクスポートではサイトを復元できず、コア移行には運用上の取り消しステップがありません。バックアップと復旧 に各データベースの利用可能な復旧点が説明されています。

サイトをビルドするマシンの Node.js バージョンと、Node.js デプロイの場合はサーバー上のバージョンを確認してください。はじめに にサポートされるバージョンがあります。

パッケージを更新する

以下のコマンドは pnpm と Cloudflare テンプレートから作成したサイトを使います。Node.js デプロイでは @emdash-cms/cloudflare を省略してください。

デプロイと検証

他の変更と同じ方法でビルドをデプロイします。次のコマンドは Cloudflare サイトをデプロイします。Node.js デプロイでは新しいビルドでサーバープロセスを再起動してください。

pnpm wrangler deploy

デフォルトのランタイム移行モード auto では、デプロイ済みサイトは最初のリクエストで保留中のコア移行を適用します。新しいコードがトラフィックを受ける前に適用し、その後デプロイ済みデータベースを検証するには、コアデータベース移行の管理 に従ってください。その emdash migrate --check コマンドは、デプロイ済みデータベースにインストール済みバージョン向けの保留または不明な移行があるとき非ゼロで終了します。

デプロイ後、管理画面を開き、少なくとも 1 つの公開ページを読み込み、使い捨てエントリーを編集して公開し、使い捨てメディアファイルをアップロードして取得してください。サイトがスケジュールタスクや sandboxed プラグインを使う場合は、それらの経路も検証してください。

特定リリース向けの注意

ほとんどのリリースは上記の手順以外を必要としません。以下のエントリは、EmDash がすでに保存していたデータを変更したリリースを扱い、それがあなたからのアクションをいつ必要とするかを述べます。

変更: 参照フィールドがリレーションにバインドされる

かつての reference フィールドは、対象エントリーの ID をコレクションのテーブル上の列に保持し、管理パネルが設定できないフィールドオプションで対象コレクションを指定していました。

参照フィールドは今や リレーション に裏打ちされたエントリーピッカーであり、そのリンクはコレクションテーブルの外にあります。更新は対象コレクションを指定していた各参照フィールドを新しいリレーションにバインドし、列内のエントリー ID をリンクとしてコピーするため、フィールドは選択を保ったピッカーになります。列はそのまま残り、更新は何も削除しません。

フィールドが未バインドのままになるのは次の場合です。

• 対象コレクションを指定していない、またはもう存在しないものを指定している
• searchable または indexed とマークされている
• リレーションスラッグ {collection}_{field} が必要で、そのスラッグが既に使われている
• 同じエントリーの異なるロケールで異なるエントリーを選択している（いずれかのエントリーで）

最後の点はリンクの置き場所に関するものです。リンクはエントリーの翻訳グループに属するため、1 つの 選択はそのすべての翻訳で共有されます。一方、古い列はロケールごとでした。ロケールが食い違う フィールドには持ち越せる単一の選択がありません — マージすれば各ロケールに他方の エントリーを渡すことになり、1 つのロケールの答えを選べば残りを捨てることになります — そのため更新は フィールドをそのままにし、両方の値を列で読めるようにします。

食い違いに見える 2 つのケースはそうではありません。1 つのエントリーの独自翻訳を名指しする ロケールは、そのエントリーを一度選択しただけなので、更新はフィールドをバインドし、リンクは各 ロケール自身のバージョンに解決します。何も選択していないロケールは他のロケールと矛盾しないため、更新は フィールドをバインドし、グループの 1 つの選択が空のものを含むすべての翻訳に適用されます。

未バインドのフィールドは以前と同様に振る舞います。列はエントリー ID を保持し、値は保存・読み込みされ、フィールドは引き続きインデックスされコンテンツリストのフィルタとして使えます。エントリーエディターではピッカーではなくテキストボックスとしてレンダリングされます。

何をすべきか？

参照フィールドを持つ各コレクションでエントリーを開いてください。ピッカーとしてレンダリングされるフィールドには何も不要です。まだテキストボックスとしてレンダリングされるフィールドについては、リレーションを作成しフィールドの保存済み ID をリンクとしてコピーする リレーションのないフィールドをバインドする に従ってください。マルチロケールサイトでは、バインドがすべての翻訳で 1 つの選択を保つため、バインド前に各翻訳が指すべきエントリーを決めてください。

更新後にサイトが壊れた場合

• ビルドが失敗する、または独自のページがランタイムでエラーになる: 飛ばしたバージョンの Breaking 付きリリースエントリを読み、そこに書かれた変更を行ってください。
• プラグインが読み込めない: プラグイン自身のリリースエントリと サイト上のプラグインをアップグレードする を読んでください。
• エラーが Astro API または @astrojs/* パッケージを名指しする: EmDash は Astro 6 以降を必要とします。Astro の アップグレードガイド が astro とその公式統合を一緒に更新する方法を説明します。
• 前のリリースに戻すには、一致する以前のパッケージバージョンを再インストールし、その成果物を再デプロイしてください。再インストールはコア移行を取り消しません。以前の成果物が移行済みデータベースを使えない場合は、トラフィックを止め、更新前のデータベースと成果物を一緒に復元してください。更新がメディアを変えた場合のみメディアを復元してください。