PHPのニュースをきっかけに、WordPressからEmDashへの移行を試してみた | UNIX Cafe

昨今のPHP関連のニュースをきっかけに、WordPressで運営しているサイトの今後を考えるようになりました。

WordPressは、記事を書いて公開するには便利な環境です。一方で、PHP、WordPress本体、テーマ、プラグインと、更新を確認するものもあります。今の構成を続ける場合も、別のCMSへ移る場合も、自分で維持していける仕組みにしておきたいところです。

そこで、WordPressの代替候補として「EmDash」を試してみることにしました。

今回は、ブラウザー上のデモで日本語の記事の公開表示を試すところから始め、Macにローカル環境を作りました。ローカル環境とは、自分のMacの中で動かす検証用の環境です。そこへ実際のWordPressの記事や商品リンク、広告データを移すところまで進めています。

この記事では、移行を試した経過と、使って分かったメリット、つまずいた点を紹介します。環境構築の詳しい操作手順は省略し、移行を考える際に確認しておきたい点をまとめています。2026年10月27日時点の記録で、本番サイトの切り替えはこれからです。

PHPのニュースから、サイトの運営環境を見直す

2026年10月21日、PHPの重大な脆弱性を修正するセキュリティ更新が公開されました。WordPress公式からも、PHPの更新と、利用しているホスティング会社の対応を確認するよう案内が出ています。

この問題はWordPress固有の不具合ではなく、PHP側の問題です。WordPress本体を更新するだけで対応できるものではない、と公式の告知でも説明されています。WordPress公式：Critical PHP Security Release

まず必要なのは、現在動いているサイトの実行環境を確認することです。移行先を調べている間も、現行サイトの更新対応は必要になります。PHPの告知は続いているため、具体的な対応はPHP公式のニュースやホスティング会社の案内で確認してください。

そのうえで、今後のサイトをどのような環境で運営していくか。今回のEmDashの検証は、その選択肢を実際に触って確かめるために始めました。

移行先の候補にしたEmDashとは？

EmDashは、WordPressと同じように、管理画面から記事を書いて公開できるCMSです。CMSとは、記事や画像を管理し、サイトを更新するための仕組みです。投稿や固定ページ、画像などを管理する画面があり、普段の編集作業をブラウザーから行えます。

技術面では、Webサイトを作るための仕組みであるAstroを基盤に、TypeScriptというプログラミング言語で作られています。ソースコードが公開されているオープンソースのCMSです。

2026年9月28日に1.0が発表された、比較的新しいCMSです。EmDash 1.0の公式発表では、人が使う編集画面に加え、AIや外部ツールから操作する仕組みも紹介されています。

WordPressで使っていたテーマやプラグインを、そのまま有効化できるわけではありません。記事を取り込む機能はありますが、見た目や独自の機能については、EmDash側で作り直す必要があります。

今回の構成は、次のようにしました。

Workersがサイトを動かす場所、D1が記事などのデータを保存する場所、R2が画像などの保存先、という構成です。現在はローカルで検証しており、本番用の環境へ配置する作業は残っています。

EmDashのメリットとして注目したこと

管理画面を使いながら、必要な項目を作れる

ブログを移しても、普段の記事編集は管理画面で続けたいところです。今回の試用では、日本語のタイトルと本文を入力し、公開画面に表示できることを確認しました。

さらに、今回作った商品リンクのように、商品名、説明、画像URL、購入先のURLをひとまとまりのデータとして管理できます。必要な項目を決めて、管理画面から編集できるようにする。この作り方は、ブログで繰り返し使う情報と相性がよさそうです。

商品カードの管理機能は、今回こちらで追加したものです。最初からPochipp相当の機能が入っている、という意味ではありません。

表示とデータを整理しながら作れる

記事の一覧、サイドバー、見出し、関連記事などを、サイトに合わせて調整できる点も魅力です。今回も、トップページと記事一覧で同じカード部品を使うようにしました。

共通部分を一つにしておくと、後から見た目を変更するときにも、ページごとの違いを減らせます。ただし、こうした調整にはAstroやCSSなどの作業が必要です。管理画面だけで、すべての見た目を変更できるわけではありません。

PHPを使わない構成と、プラグインの設計

PHPを使わない構成を選べることは、今回EmDashを検討する理由の一つです。ただ、移行後もEmDash本体や依存するパッケージの更新は続きます。保守する対象と方法が変わる、と考えています。

プラグインには、隔離された環境で動くSandboxed形式と、サイトと同じプロセスで動くNative形式があります。隔離や権限を考えた設計には注目していますが、すべてのプラグインが同じ条件で動くわけではありません。公式ドキュメント：プラグイン形式の比較

今回のローカル環境ではSandboxed pluginsは有効にしていません。ここは製品の設計として調べた内容で、実際に隔離動作を検証した結果ではありません。

今回の移行で役立ったAIとの作業

今回の移行作業も、AIと相談しながら進めています。元のデータを調べ、表示処理を直し、商品リンクの管理方法を変える、といった作業を小さく区切って進めました。

機能が増えてくると、何を変更したのかも把握しにくくなります。そのため、途中から作業の区切りを明確にして、コードの変更履歴を記録するGitを使い、変更を区切りごとに保存する「コミット」を残すようにしました。また、記事や設定を保存するデータベースも、別にバックアップしています。AIを使う場合も、変更を確かめて戻せる状態にしておくことは大切です。

まずはPlaygroundで、日本語の記事を試した

最初に触ったのは、公式のPlaygroundです。自分の環境を用意する前に、管理画面や編集操作を試せます。体験時の表示はv1.3.1でした。

日本語のタイトルと本文を入力し、デモ内の公開表示でも文字化けせず表示できました。ここでは、自分の本番サイトを公開するのではなく、デモ環境で読者向けの表示を試しています。設定画面から管理画面の言語を日本語に切り替えることもできましたが、一部には英語の表記が残っていました。

最初に少し迷ったのは保存です。Saveボタンを探していたのですが、編集画面にはすでに「Saved」と表示されていました。自動保存された下書きと、読者に見える公開版を分けて扱う必要があります。

また、本文を日本語に直しても、トップページの記事カードには英語が残りました。これは概要欄のExcerptが別の項目だったためです。本文だけでなく、一覧に使われる情報も確認する必要がありました。

Playgroundでは、新しい画像をアップロードしようとすると制限を示すメッセージが出ました。既存のサンプル画像は利用できたので、この段階ではそれを使って試しています。デモ環境での制限として、通常環境での検証とは分けて記録しました。

検索では日本語タイトルを見つけられましたが、日本語本文の語句で結果が出ないケースがありました。対象の本文が公開版に反映されていたかなど、切り分けが残っています。日本語本文検索については、引き続き確認する項目です。

WordPressの記事を移して、手を入れたところ

ローカル環境を用意して実際の記事を移すと、管理画面での試用だけでは分からなかった作業が出てきました。特に確認が必要だったのは、記事の見た目と、WordPress側で追加していた機能です。

トップページだけでなく、記事一覧もそろえる

トップページを整えた後、「記事をもっと見る」を押すと、記事一覧のレイアウトが変わる状態になっていました。そこで、記事一覧もトップページと同じカード配置とサイドバーを使う形に変更しました。

記事内では、h2の帯に白文字と黒文字が混ざっていたため、緑の帯に白文字で統一するCSSへ修正しました。見出し内の太字やリンクにも、本文用の文字色が適用されていたことが原因でした。

トップページが整っても、そこから先のページまで同じように整うわけではありません。一覧、次のページ、個別の記事へと、実際に読者が進む順番で確かめる必要があります。

地図の埋め込みや、日本語の設定を確認する

記事に入れていたGoogleマップについては、WordPressから記事などを書き出したXMLファイルと照合し、取り込み後の埋め込みを修復する処理を用意しました。この書き出し用の形式はWXRと呼ばれます。地図の前後にある説明文も残すようにしています。

日本語で運営するため、既定言語をjaにそろえ、カテゴリなどのデータも整理しました。管理画面の表示を日本語にする設定と、記事やカテゴリがどの言語のデータとして扱われるかは、別に確認する部分でした。

本文の文章だけを見ていると、地図や共通パーツの不足は見落としやすいものです。記事下のAI表記やサイドバーのブログパーツも、掲載位置を含めて調整しています。

Pochippは商品リンクとして作り直した

WordPressでは、Amazonの商品紹介にPochippを使っていました。EmDashではWordPressのプラグインをそのまま動かせないため、商品情報を使ってHTMLの商品カードを表示する形にしました。

元のデータには、商品名、説明、画像URL、AmazonのアフィリエイトURLが残っていました。これを使い、まず9商品のカードを表示する処理を作りました。既存の記事では、12記事・20か所にPochippの参照がありました。

最初は商品情報をファイルにまとめましたが、リンクを変更するたびにファイルを編集するのでは、日常の運用が面倒です。そこで、管理画面に「商品リンク（広告タグ）」を追加しました。

商品情報を共通のデータとして持ち、記事側から参照する構成です。一つの商品を複数の記事で紹介していても、リンク先の変更を一か所で管理できます。

新しい記事では、まず管理画面で商品リンクを登録・公開します。次に、その商品を識別する名前である「スラッグ」を、次の例のようなタグに入れて記事の独立した段落に入力します。すると、公開ページに対応する商品カードが表示される仕組みです。このタグ記法も今回追加した仕組みで、EmDash標準の記法ではありません。

[ad_tag slug="sample-product"]

sample-productは架空の入力例です。実際には、管理画面で登録・公開した商品リンクのスラッグに置き換えます。

今回引き継いだのは、商品情報と既存のアフィリエイトリンクです。価格の自動更新やクリック集計までは再実装していません。Pochippの機能を全部再現するのではなく、今回のサイトで使いたい範囲を決めて作りました。

AdSenseは、広告名が移っていてもコードが空だった

AdSenseでは、もう一つ分かりやすい問題がありました。取り込んだデータに「記事下」「記事内」「追尾サイドバー」の広告名はあったのですが、広告コード自体が入っていませんでした。

WordPressの元のXMLを調べると、コードは通常の本文ではなく、ad_imgという項目に保存されていました。こうした、本文とは別に保存される追加情報を「カスタムメタ情報」と呼びます。そこから3種類のコードを復元し、EmDashの「広告タグ」にコードを編集する欄を追加しました。

現在は、元のコードとの一致と、データベースへの保存を確認したところです。ページへの広告表示処理と、本番での配信確認はまだ行っていません。

公式の移行ガイドにも、WXR経由では任意のメタ情報がすべて自動で書き込まれるわけではないと説明されています。今回の広告コードは、その確認が必要だった具体例でした。公式ドキュメント：WordPressからの移行

広告の件数や名前がそろっているだけでは、移行できたとは判断できません。何が保存され、それをどう表示するかまで確認する必要がありました。

WordPressから移行する前に、確認しておきたいこと

今回の作業を踏まえると、移行前に次の項目を一覧にしておくと、確認しやすくなります。

WordPressのXMLエクスポートには画像のURLが含まれますが、画像ファイル本体が入っているわけではありません。画像の取得と確認が終わるまでは、取得元のWordPressサイトを維持しておく必要があります。これは公式の移行手順でも案内されています。

URLにも注意が必要です。同じドメインを使い続けても、その後ろに続く記事の場所を示す部分（パス）が変われば別のURLになります。今回のEmDash側は/posts/記事のスラッグという形です。ここでのスラッグは、URLの一部として記事を識別する名前です。WordPress側のURLと照合し、古いURLから新しいURLへ読者を案内する転送を考える作業が残っています。

また、Gitにコミットしたからといって、記事や画像まで保存されたわけではありません。今回も、コードはGit、記事や設定はデータベースのバックアップとして分けて残しています。画像の保存先も含め、復旧できる形にしておく必要があります。

費用についても、CMS本体のライセンス料だけでは決められません。実行環境や画像保存などの利用料に加え、移行時に作り直す手間と、その後の保守も考えることになります。今回は表示速度の測定や、月額費用の比較までは行っていません。

ここまでにできたことと、これから確認すること

ここまでの作業は、ローカル環境で記事の表示を整え、商品情報と広告コードを管理する仕組みを用意するところまでです。

最近追加した管理機能については、型チェックやテスト、データベースの照合で確認した部分があります。作業環境の制限で、ブラウザーからの一連の操作確認が残っているものもあります。実装できたことと、運用できることを順に確かめていく段階です。

自分のサイトに必要な機能から、移行を考える

今回試してみて、EmDashは、記事を書く管理画面を持ちながら、サイトの仕組みを自分の用途に合わせて整理していけるCMSだと感じています。特に、商品リンクを共通のデータとして管理する構成は、今後の更新にも使いやすそうです。

一方で、WordPressで動いていた機能が自動ですべて移行できるわけではありません。地図、商品カード、広告コードなどを、一つずつ確認して作り直す作業がありました。

記事中心のサイトで、必要な表示や管理項目を組み立てながら運営したい場合には、検討する価値があります。既存のテーマやプラグインに多くを任せているサイトでは、その代替方法と、誰が保守するかを先に考えておきたいところです。

まずは実際の記事を少し移し、普段使っている機能がどこまで再現できるか確かめる。今回も、その繰り返しで少しずつ形になってきました。

次は、本番環境への配置と、URLや広告配信を含めた確認です。現在のサイトを維持しながら、切り替えに必要な作業を進めていきます。