WordPress テーマを Astro と EmDash に移植する
WordPress テーマを一対一のコード変換ではなく、フロントエンドとコンテンツモデルの翻訳プロジェクトとして扱う、実践的なテーマ移行の考え方。
WordPress テーマを EmDash に移植するときは、一対一のテンプレート対応表を探すところから始めない方がよいです。
そのやり方は、古い結合をあまりにも多く引きずり込みがちです。WordPress テーマは、プレゼンテーション、CMS 前提、ヘルパー論理、副作用を歴史的には理にかなった形で混ぜがちですが、モダンなフロントエンドスタックでは窮屈になります。
よりよいアプローチは、テーマが実際に何をしているかを切り分けることです。
まずテーマの本当の責務から
Astro のコードを書く前に、現行テーマを平易な言葉で棚卸しします。
次を洗い出します。
- ページ種別
- 共通レイアウト
- ナビゲーションのパターン
- アーカイブの挙動
- 再利用可能な UI コンポーネント
- テーマ固有のデータ要件
これで、再構築が必要なものと単純化できるものの地図ができます。
ファイルではなく「挙動」を翻訳する
WordPress のテーマファイルは、EmDash では重要な単位ではありません。有用な単位は、レンダリングされた体験です。
Astro と EmDash では、典型的なテーマは次のようになります。
- ページ種別ごとのルート
- 共通構造のレイアウト
- 再利用 UI のコンポーネント
- ビジュアルシステムのスタイル
- テーマが前提とするコンテンツモデルのスキーマ定義
従来の「動くまでテーマにロジックを足していく」パターンより、ずっと健全な分離です。
パリティを追う前にコンテンツモデルを再構築する
ターゲットのコンテンツ構造を理解する前に旧 HTML 出力を保とうとすると、テーマ移行は失敗しがちです。
WordPress テーマがカスタム投稿タイプ、投稿メタ、ショートコード、ブロック固有の前提に依存しているなら、まず EmDash ネイティブのコンテンツタイプとフィールドに翻訳する必要があります。
そうしないと、Astro 層が弱いスキーマを補う役になってしまいます。
サイトがまだコンテンツ移行フェーズにある場合は、WordPress から EmDash への移行ガイド から始めてください。
旧デザインの良い部分は残す
WordPress テーマのすべてを捨てる必要はありません。通常は次が正解です。
- 情報設計は維持する
- ブランドシステムは維持する
- うまくいっているページパターンは維持する
- レガシー実装の荷物は取り除く
編集者と読者にとって馴染みのあるサイトを保ちつつ、Astro に PHP 時代のテーマ構造を無理に真似させなくて済みます。
意図的に書き直すべきもの
移植の際、ほぼ常に再設計した方がよい部分があります。
functions.phpに結びついたものすべて- テーマヘルパーに隠れたロジック
- 壊れやすいショートコード駆動のレンダリング
- プラグイン依存のビジュアルコンポーネント
ここが「忠実な移行」がしばしば技術的負債の移転になる場所です。
成功の実用的な基準
成功したテーマ移植とは、実装の細部をすべて保ったものではありません。次を満たすものです。
- 読者が気にするコンテンツ体験を保つ
- 編集者により明確な構造を与える
- フロントエンドの保守をしやすくする
- セキュリティとランタイム結合を減らす
Astro と EmDash が強いのはここです。テーマコードを聖域のように扱うのではなく、モダンなフロントエンドプロジェクトとしてプレゼンテーション層を再構築できます。