WordPress から移行する | EmDash CMS Everything

EmDash 管理画面を使って、WordPress サイトの分析、互換性のあるコレクションの準備、コンテンツのインポート、メディアのコピー、URL の書き換えを行います。インポートしたサイトが検証に合格するまでは、WordPress サイトを利用可能な状態に保ってください。

始める前に

次のものを用意してください。

WordPress データベースと wp-content/uploads のバックアップ。
メディアをコピーする予定がある場合は、ストレージを構成した EmDash サイト。
EmDash の管理者アカウント。WordPress のインポートには import:execute 権限が必要です。
完全な WordPress eXtended RSS（WXR）エクスポート、または WordPress サイトにインストールした EmDash Exporter プラグインのいずれか。

現在のパーマリンク構造、正規のオリジン、リダイレクト、メニュー、有効な投稿タイプ、タクソノミー、新しいサイトで保持する必要があるプラグイン所有のフィールドを記録しておいてください。

インポート方法を選ぶ

方法	使う場面	含まれるデータ
WXR アップロード	Tools → Export からエクスポートできる場合	エクスポートに含まれるデータ（投稿、ページ、カスタム投稿タイプ、タクソノミーのターム、再利用ブロック、著者、添付ファイルの URL を含む）
EmDash Exporter	WordPress サイトを管理していて、exporter をインストールできる場合	認証が必要なコンテンツに加え、対応するコメント、メニュー、サイト設定、SEO フィールド、タクソノミー、メディアメタデータ

exporter なしでサイト URL を入力しても、公開されている WordPress REST API を調べるだけです。この調査では WordPress の検出と、公開されている投稿、ページ、メディアの件数の集計はできますが、REST による直接のインポートは実行できません。

WXR ファイルをエクスポートする

WordPress で Tools → Export を開き、All content を選択して、XML のエクスポートファイルをダウンロードします。WXR ファイルは WordPress オリジン上のメディアを指しており、添付ファイルのバイトデータは含まれません。

EmDash Exporter に接続する

WordPress で Tools → EmDash Migration を開き、マイグレーションキーを生成します。そのキーを EmDash のインポートページに貼り付けます。

WordPress サイトの URL を入力することもできます。exporter が検出されたら、WordPress のアプリケーションパスワード画面で EmDash を承認します。ローカルの HTTP 開発サイトでは、認可コールバックに HTTPS が必要なため、WordPress のユーザー名とアプリケーションパスワードを手動で入力します。

管理画面からインポートする

EmDash のサイドバーで Import WordPress を開くか、/_emdash/admin/import/wordpress にアクセスします。
WXR ファイルをアップロードするか、exporter のマイグレーションキーを貼り付けるか、WordPress の URL を入力します。
分析結果を確認します。WordPress の投稿タイプごとに、対象コレクション、必須フィールド、既存フィールドとの互換性を確認します。
WordPress の著者を EmDash のユーザーにマッピングします。マッピングされていないソースの著者はゲストの Byline で表現できるため、表示上のクレジットは EmDash のログインを付与することに依存しません。
exporter でのインポートでは、メニュー、サイトタイトルとタグライン、ロゴと favicon、対応する SEO の値をインポートするかどうかを選びます。これらのスイッチは WXR の経路には含まれません。
インポートを開始します。EmDash は、エントリを作成する前に、不足している互換性のあるコレクションとフィールドを作成します。
添付ファイルが見つかった場合は、メディアのステップを実行します。EmDash はソースのバイトデータをダウンロードし、構成済みのストレージアダプターで保存して、一致するコンテンツ URL を書き換えます。

変換の動作

ステータス

インポーターは WordPress のステータスを次のようにマッピングします。

WordPress	EmDash
`publish`	`published`
`draft`	`draft`
`pending`	`draft`
`private`	`draft`
`future`、`trash`、または不明なステータス	`draft`

予約日時や WordPress の公開範囲のルールは、これらのステータスから再構築されません。公開する前に、インポートした下書きをすべて確認してください。

リッチテキストと再利用ブロック

Gutenberg のマークアップは Portable Text に変換されます。クラシックの HTML も同じコンバーターで処理されます。複雑なブロック、埋め込み、ショートコード、ページビルダーのマークアップ、プラグインが定義したブロックは、レンダリングされた EmDash サイトで確認してください。

WXR の wp_block エントリは sections としてインポートされます。通常のコンテンツコレクションにはインポートされません。

コレクションとフィールド

デフォルトの投稿タイプのマッピングには、post から posts、page から pages が含まれます。カスタム投稿タイプには、サニタイズされたコレクション slug が使われます。準備ステップでは、分析で必要となる標準のタイトル、Portable Text のコンテンツ、抜粋、アイキャッチ画像のフィールドが追加されます。

型に互換性のある既存のフィールドは再利用されます。型が一致しない場合、そのコレクションのマッピングはブロックされます。インポーターは既存のフィールドを別の型に強制変換しません。

カスタムフィールドと SEO データ

WXR の分析は、内部用でない post-meta キーを報告し、フィールド名と型を提案しますが、WXR のデータベースインポートは任意のメタキーをすべてコピーするのではなく、標準のインポート用フィールドに書き込みます。分析結果は、別途変換が必要になる可能性のあるフィールドのチェックリストとして扱ってください。

対象コレクションに一致するフィールドがある場合、EmDash Exporter の経路では、カスタムメタと Advanced Custom Fields（ACF）の値をコピーできます。インポートのスイッチが有効なら、対応するアイキャッチ画像のフィールドと、Yoast または Rank Math の SEO フィールドを作成して値を入力することもできます。シリアライズされた PHP の値、リピーター、フレキシブルコンテンツ、プラグイン固有の構造は、WordPress での表現が EmDash のフィールド型と一致すると決めつけず、確認してください。

著者と Byline

マッピングされた WordPress の著者は、エントリの所有者になります。表示上のクレジットには Byline を使います。ユーザーのマッピングがない場合、EmDash は WordPress の著者情報に基づいてゲストの Byline を作成または再利用します。

タクソノミー

カテゴリーとタグは、対応する EmDash のタクソノミー定義にインポートされます。exporter の経路では、カスタムタクソノミーの定義を作成できます。対応する EmDash の定義がない WXR のカスタムタクソノミーは、不足として報告され、その割り当てはスキップされます。

メディア

メディアの重複排除では、ダウンロードしたバイトデータの SHA-1 ハッシュを比較します。同じハッシュを持つ既存のメディア行は再利用されます。ファイル名と WordPress の ID は重複排除のキーではありません。

EmDash が添付ファイルをダウンロードしている間は、ソースサイトに到達できる状態を保つ必要があります。添付ファイル URL からのリダイレクトは、たどる前に検証されます。

部分的なインポートを再試行する

管理画面のインポートは既存のエントリをスキップするように設計されていますが、その照合の境界は重要です。

既存のコンテンツは、WordPress ID ではなく、コレクション、slug、ロケールで照合されます。
試行の間にソースの slug が変更された場合は、両方のエントリを確認し、重複を手動で解消してください。
メディアのステップを再実行すると、すでに保存済みでバイト列が同一のファイルが、コンテンツハッシュで再利用されます。
exporter のフローは、上限のあるチャンクで送信します。ブラウザーのフローを再開すると、コンテンツページが再実行され、スキップされたエントリからリレーションのマップが再構築されます。

管理画面は WXR の再開用ファイルを永続化しません。emdash import wordpress の --resume フラグは、変換後の JSON ファイルをディスクに書き出す別の CLI ワークフローのもので、管理画面のデータベースインポートを再開するものではありません。

切り替え前に検証する

インポートしたサイトをソースと照らし合わせて確認します。

投稿タイプとステータスごとにエントリ数を数える。
代表的な Gutenberg、クラシックエディター、ショートコード、ページビルダーのコンテンツを開く。
アイキャッチ画像とインラインのメディアが EmDash の URL から解決されることを確認する。
著者、Byline、カテゴリー、タグ、カスタムタクソノミー、翻訳を確認する。
exporter 経由でインポートした場合は、メニュー、コメント、サイトの識別情報、SEO フィールドをテストする。
古い公開 URL をクロールし、変更されたすべてのルートにリダイレクトを用意する。
下書きがログアウト状態の訪問者から引き続きアクセスできないことを確認する。

新しいサイトが本番環境で問題なく稼働し、ロールバックが不要になるまで、バックアップと WordPress のデプロイを保持してください。

トラブルシューティング

XML ファイルを解析できない

Tools → Export からファイルを再度エクスポートし、ダウンロードが完了したことを確認してください。エンコーディングを変更するツールで XML を編集しないでください。

コレクションが非互換とマークされる

既存のフィールドの slug は同じですが、型が異なります。再試行する前に、投稿タイプのマッピングを変更するか、Content Types でフィールドを調整してください。準備ステップは不足しているフィールドを追加しますが、既存のフィールドの型は変更しません。

メディアの URL をダウンロードできない

ソースの添付ファイルが WordPress のセッションなしで到達できることを確認してください。認証の背後にあるメディア、削除されたファイル、プライベートネットワークアドレスへのリダイレクトは個別に失敗し、メディアのエラー一覧に残ります。

テーマを適応させる

アーカイブのルートには getEmDashCollection() を、slug のルートには getEmDashEntry() を使います。entry.id はルートの識別子で、通常は slug です。entry.data.id は、リレーションのヘルパーが使う、保存されたコンテンツ ID です。

次のルートは、インポートした投稿をレンダリングします。

---
import { decodeSlug, getEmDashEntry } from "emdash";
import { PortableText } from "emdash/ui";

const slug = decodeSlug(Astro.params.slug);
if (!slug) return Astro.rewrite("/404");

const { entry: post, error } = await getEmDashEntry("posts", slug);
if (error) return new Response("Could not load the post", { status: 500 });
if (!post) return Astro.rewrite("/404");
---

<article>
  <h1>{post.data.title}</h1>
  <PortableText value={post.data.content} />
</article>

ルートとコンポーネントのマッピングについては WordPress テーマを移植するを、エンドポイントの仕様と正確な再試行の境界についてはコンテンツインポートを参照してください。