Drupal 7 から WordPress への移行方法
今回は Drupal 7 から WordPress への移行方法についてまとめたのでそのことを書きます。
なぜ Drupal 7 から WordPress に？
Drupa 7 は 2021 年の 11 月に 公式のメンテナンスが終了することが決定しています（追記: その後 1 年延長されて 2022 年 11 月になりました）。
その時点での Drupal の最新版は Drupal 9 ですが、 Drupal 9 はその「内部構造」や「利用に必要な知識」「適切な保守の方法」等において Drupal 7 とは大きく異なるソフトウェアです。 Drupal を追いかけ続けている人にとってその違いは大したものではありませんが、そうではない人たちにとっては非常に大きな違いです。
また、詳細の説明は割愛しますが、 Drupal 9 は Drupal 7 よりもニッチな CMS です。 広範な守備範囲を持ちシェア的に大成功を収めた Drupal 7 とは異なり、 Drupal 9 はより狭い範囲で大きな強みを発揮する「尖った CMS 」になっています。
そのため、 Drupal 7 のメンテナンス終了後の移行先として Drupal 9 が最適であるとはかぎりません。 おそらく、現在 Drupal 7 で運用されているサイトの半分以上は Drupal 9 と WordPress の 2 つのうちどちらかを選ぶなら Wordpress を選んだ方がサイト運営者が幸せになる可能性が高いと思います。 これは Drupal と WordPress を実際のクライアントプロジェクトで利用してきた経験に基づく印象であり、近年のシェアトレンドから立てられる予測です。
ということで、今後数年のうちに情報ニーズが高まるであろう「 Drupal 7 から WordPress への移行方法」についてのお話です。 日本国内では特に「 WordPress と Drupal の両方をちゃんと扱える人」「 Drupal から WordPress への移行経験を持つ人」が割合として少ないので、興味のある方には貴重な情報になるのではないかと思います。
お話の前提として、対象のサイトは「ビジネス用途のサイトである」という仮定を措いています。 個人のサイトは想定していないのでご了承ください。
以下、 Drupal 7 を Drupal 、 WordPress を WP と表記します。
全体的な流れ
大きな流れとして、まず現状の把握を行ってから全体的な方針を決定します。 方針が決まったら実際に移行作業を行い、必要に応じて差分の更新を行ってから、最後に問題がないかをチェックして完了です。
- 現状の把握
- 方針の決定
- 移行の実作業
- 差分の更新
- チェック
状況次第では移行後のサイトの運用中に追加作業が発生することもあります。
各ステップの詳細
1. 現状の把握
まず最初に行うべきは現状の把握です。
最初に Drupal で作られた現行サイトの全体像の把握に努めます。 具体的には機能的特性・非機能的特性・コンテンツ等の一覧を作成します。 ユーザーアカウントの数が多い場合はアカウントやロール、権限周りで複雑な作り込みが行われている場合は権限周りの情報も抽出します。 ファイルやデータベースを見る必要があるものも中にはありますが、ほとんどの情報は一般ユーザー向け画面・管理画面を確認すればわかるはずです。 構築時の企画書や仕様書等のドキュメントが残っている場合は（残っているべきですが……）それらもモレなく集めてきます。
プロジェクトメンバーの中に Drupal のことがわかる人がいない場合は、以下の情報が役立つかもしれません。
- コミュニティ提供のモジュール（ WP のプラグインに相当するもの）は通常ドキュメントルート以下の
sites/all/modules/以下に格納されています。 - 同様にテーマは
sites/all/themes/以下に格納されています。 - 管理者やユーザーがサイトからアップロードしたファイルは通常ドキュメントルート以下の
sites/default/files/やsites/default/private/に格納されています。 - 管理画面へのログインフォームの URL は
http://example.com/user/loginです（http://example.com/userでも OK ）。 - Drupal アソシエーション公式のモジュール一覧は Module project | Drupal.org にあります。ここには複数のモジュールがパッケージされた「プロジェクト」という形でモジュールが公開されています。
- WP の WP-CLI に相当するターミナルユーティリティとして Drush というものがあります。
ここで収集した情報がその後のすべての作業の土台になるので、先を急がず網羅的に調べておくことが大切です。
2. 方針の決定
現状の把握が終わったら次に行うのは移行方針の決定です。 何をどのように移行するのかという全体的な方針を決定します。 具体的には、主に機能的特性・非機能的特性・コンテンツについて、どこからどこまでを移行するのか、そして、どのように移行するかを決定します。
ここで重要なのは「 Drupal サイトの WP での再現」をゴールにしないことです。 Drupal も WP も CMS というくくりでは同じですが、主要機能もデータモデルも内部構造も異なります。 Drupal サイトでやれていたことを WP サイトで実現することはたいていの場合可能ですが、そんなことをやっても得られるメリットは薄く余計なコストがかかるだけです。 せっかく移行するからには、現行の Drupal に引っ張られずに移行先の WP のメリットを理解しその強みを最大限活用できる形を追求するべきです。
サイトの規模が大きい場合は必ずスプレッドシート等を使ってサイトマップを作成します。 サイトマップを作成したら、アクセス解析等で得られた情報をもとにコンテンツの優先順位の決定、取捨選択、整理を行います。
「どのように移行するか」という点については、大きく「手作業で移行するかプログラムを書いて自動化するか」という選択肢があります。 例えば、メニューやウィジェット（ Drupal におけるブロック）等は数がかぎられるので、わざわざプログラムを書くよりも手作業で移行した方が効率的です。 一方、固定ページや記事等のコンテンツについては、手作業が必ずしもよいとはかぎらないので、どのようなやり方がよいのかを総合的に判断します。
ちなみに、今回は移行先が WP ということを前提にしてお話をしていますが、実際には現状把握の後に最適な移行先の見極めと決定を行う必要があります。 統計的に見て WP が Drupal の有力な移行先であることは間違いありませんが、絶対に WP にすべき強い理由が無いかぎり WP にこだわない方がよいと思います。 移行先に WP を選ぶ場合も、サイトのすべてを WP で賄う必要はありません。 更新系のコンテンツは WP で、問い合わせはクラウド型の CRM で、と切り分ける方が全体的な ROI が上がる可能性もあります。 特にウェブサイトの出来・パフォーマンスが事業に与えるインパクトが大きい場合は、移行先の決定は慎重に行うべきです。
3. 移行の実作業
方針が決まったら実際の移行作業を進めます。 よくある進め方は、コンテンツ以外の構築を WP で進めながら並行でコンテンツ移行を進めるやり方です。 コンテンツ以外の構築の進め方は新規でのサイト構築の場合とそう変わらないので、説明は割愛します。
コンテンツの移行作業は一般に次の 3 ステップに分かれます。
- Drupal サイトからのコンテンツの抽出
- コンテンツの加工・整形
- WP サイトへのコンテンツの登録
サイトの規模がそこまで大きくない場合は手作業でひとつずつ移行し、一定の規模以上であればプログラムを書いて一括での移行を検討すべきです。 私の経験では 100 ページ〜の規模になると手作業でやるのが辛くなってきますが、一概に「○ページ以上ならプログラムで一括がよい」という共通の線引きはありません。 各コンテンツの規模や必要になる整形作業の複雑さ、リライトの必要性、予算や時間等を総合的に考慮してよりよいやり方を選びます。
Drupal サイトからコンテンツを抽出する方法にはさまざまなやり方がありますが、コマンドラインから JSON 等の形式でダンプする方法がかんたんでおすすめです。 私が特定のコンテンツタイプ（エンティティタイプ×バンドル）のコンテンツを全件一括で抽出するために作って実際に使った Drush コマンドを GitHub に置いてあるので、興味のある方は参考にしてください。
Drupal のデータベースはカスタムフィールドの単位でテーブルが細かく分かれているので（標準的なインストールで 50 テーブル以上になります）、 SQL を書いてデータベースから直接データを抽出するやり方はおすすめしません。 Drupal の API を使う方が断然効率的で正確です。
状況によっては、加工が不十分なコンテンツを WP サイトに先に登録してしまってそれから加工・整形してしまった方が効率的な場合もあります。 その場合は事前にすべて加工・整形を完了させることにこだわってはいけません。
プログラムでの一括登録は一発で完璧にできることはまれなので、練習用の WP インスタンスを作って何度も試す、こまめにバックアップを取る、といった対応が必要です。 複数人が並行で作業をする場合は、バックアップを使って前の状態を復元したときに作業の進捗がわからなくなり、作業が滞ったり修正したはずの場所が先祖返りしたりといったことが起こりうるので、何らかの形で作業ステータスや進捗を見える化するとよいでしょう。
4. 差分の更新
移行中に現行サイトに更新が発生する場合は、差分の更新が必要になります。 コンテンツの数が多い場合や更新の頻度が高い場合派特に、更新が発生する度にコンテンツ全件の移行のやり直しが必要になると非効率なので、差分だけを移行できる仕組みを作ることが必要です。 その場合は、新規のコンテンツの追加だけでなく、既存のコンテンツの変更や削除にももれなく対応できるように注意が必要です。
5. チェック
コンテンツ以外の構築とコンテンツの移行がすべて完了したら、作業はひとまず完了です。 後は、 WP サイト上でのコンテンツの内容や見栄えに問題が無いか最終チェックを行います。
規模がそこまで大きくない場合は目視で全ページチェックすればよいですが、ある程度以上の規模になって全件チェックが難しいあるいは非効率な場合は何かしら別の方法でのチェックを検討します。 全ページチェックをしない場合は、どのページをチェックするのかを関係者間で事前に議論して決めておくと後々スムーズです。
以上で移行は完了です。
ということで Drupal 7 から WordPress への移行方法についてでした。
WordPress がきちんと理解できている人がプロジェクトに 1 人いれば Drupal の経験者がいなくても移行プロジェクトは問題なく進むと思いますが、どうしても Drupal をよく知る人が必要な場合等はお気軽にお声がけください。
ちなみに、逆の「 WordPress から Drupal への移行」を検討されている方には、 Drupal エキスパートであるアクト・ブレインさんの記事等がご参考になるかと思います。
関連記事
今回は移行先が WordPress の場合に限定したお話でしたが、移行先を限定しない一般的な脱 Drupal の進め方についても過去に書いているので、興味のある方は参考にしてみてください。
追記
別ブログにも Drupal 関連の記事を書きました。 興味のある方はご覧になってみてください。