haruki256.comを、WordPressからHugoへ移すことにしました。
WordPressに障害が起きたわけでも、記事を書けなくなったわけでもありません。ブログの運用方法を見直した結果、動的なCMSを維持するより、Markdownを正本にして静的ファイルを公開する形のほうが、これからの使い方に合うと判断しました。
この記事では、移行前に確認したこと、WordPressを続ける案と静的サイトへ移る案をどう比べたか、その中でHugoを選んだ理由をまとめます。
まず全体像
WordPressに問題が起きたわけではない
移行を決める前に、まず現在のWordPressを調べました。WordPress本体と使用中のプラグインは更新できる状態で、公開中の記事も表示されています。
調査時点の投稿は7本で、そのうち1本はパスワード保護されていました。承認済みコメントは0件です。記事本文は標準ブロックを中心に作られており、Cocoon固有のショートコードにも依存していませんでした。
WordPress自体は問題なく動いていました。今回見直したのは、記事とサイトの管理方法です。
運用方法とWordPressの形が合わなくなった
記事を手元で編集して確認してから公開するには、最初からMarkdownファイルとして管理できるほうが扱いやすくなります。コードと同じようにgitで変更内容を確認できる点も、このブログの運用に合っています。
WordPressでは、記事本文の正本はサーバー側のデータベースにあります。エクスポートやAPIを使えば手元へ取り出せますが、普段編集する場所とgitで管理する場所が分かれます。
もう1つは、更新するものの多さです。WordPress公式ドキュメントでも、本体だけでなくテーマやプラグインを更新し、更新前にバックアップを取ることが案内されています。自動更新を使う場合でも、更新後の確認と、問題が起きた場合に元へ戻す方法は必要です。
この管理がWordPressの欠点だとは考えていません。コメント、管理画面からの編集、プラグインによる機能追加が必要なら、その分だけ動的なCMSを使う意味があります。
一方、現在のharuki256.comは、公開記事が少なく、コメントも使われていません。僕の条件では、公開サーバーでWordPress本体、PHP、データベース、テーマ、複数のプラグインを動かし続ける理由が小さくなっていました。
今なら移行コストを抑えられる
静的サイトへ移せるかどうかは、希望だけで決めず、既存コンテンツを調べて判断しました。
確認した結果は次のとおりです。
- 投稿は7本で、承認済みコメントは0件
- 記事本文にCocoon固有のショートコードは見つからない
- 画像を使う記事は限られている
- 既存のパーマリンクは
/年/月/日/スラッグ/の規則で再現できる - WordPress本体をすぐ削除せず、切り替え時に別フォルダへ退避できる
記事が数百本あり、コメントや複雑なプラグイン機能を使っていたら、同じ判断にはならなかったと思います。今回は、移行で失う機能が少なく、URLを保ったまま検証できる条件が揃っていました。
移行するなら今が一番小さく試せるタイミングでした。
WordPressを続ける案も残した
最初から静的サイトへの移行を前提にはしませんでした。まず比較したのは、次の3案です。
| 案 | 良い点 | 今回気になった点 |
|---|---|---|
| WordPressを続ける | 移行作業がなく、管理画面やプラグインをそのまま使える | Markdownとgitを正本にする運用とは管理場所が分かれる |
| Astroへ移す | 静的出力ができ、UIを作り込む選択肢も多い | 今回のブログにはNode.js環境と依存関係の管理がやや大きい |
| Hugoへ移す | Markdownを直接扱え、単体の実行ファイルで静的サイトを生成できる | テンプレートにはHugo固有の記法が残る |
Astroも標準では静的ファイルを出力でき、Markdownページにも対応しています。一方、開発環境にはNode.jsが必要です。
今回欲しかったのは、アプリケーション基盤ではなく、Markdownからブログを生成する小さな道具でした。その条件ではHugoのほうが単純でした。
Hugoを選んだ理由
HugoはGoで書かれた静的サイトジェネレーターです。Markdownを標準のコンテンツ形式として扱い、開発用サーバーで変更を確認してから静的ファイルを生成できます。
僕がHugoを選んだ理由は、速さそのものよりも、運用に必要な部品を減らしやすかったことです。このブログでは、Hugo本体、自作テンプレート、素のCSSとJavaScriptだけで構成できます。
記事はMarkdownファイルとして置き、gitで変更履歴を追います。公開環境に置くのは生成済みのHTML、CSS、JavaScript、画像です。問い合わせフォームのように静的ファイルだけで完結しない機能は、必要な部分だけ外部サービスへ分けます。
これなら、記事を書く環境とサイトを作る環境を同じリポジトリにまとめられます。
記事をHugo専用の形式にしない
将来Hugo以外のツールへ移る可能性も考え、記事はHugo専用の形式にしないことにしました。
そこで、記事本文は素のMarkdownにし、Hugo専用のショートコードは原則使わない方針にしました。見た目と動きはCSSとJavaScriptへ分け、Hugoのテンプレートは両者をつなぐ薄い層にします。
Hugoに依存する箇所は、別の生成ツールへ移るときのチェックリストとして一覧化しています。将来Hugo以外へ移るとしても、記事本文を変換し直さずに持ち出せる状態を目指しています。
記事の正本はMarkdownです。Hugoは、そのMarkdownを現在の公開サイトへ変換するために使います。
切り替えは戻せる状態で行う
移行を決めても、WordPressをすぐ削除することはしません。
まずHugo側で記事URLと表示を検証し、WordPressのファイルとデータベースをバックアップします。本番切り替え時はWordPress一式を別フォルダへ退避し、静的ファイルを配置する予定です。問題があれば元の配置へ戻せる経路を残します。
既存記事のURLも、原則として変更しません。URLを変える必要がある箇所だけ、切り替え時に転送を設定します。
静的サイトへ移しても、バックアップや公開後の確認は必要です。ただし、WordPress本体やプラグインの代わりに、手元のMarkdown、git、生成したファイル、公開手順を管理する形へ変わります。
まとめ
WordPressから移すことにしたのは、記事をMarkdownとgitで管理し、公開環境の構成を小さくするほうが、現在のブログ規模と今後の執筆方法に合っていたからです。
Hugoは、その条件を少ない部品で満たせる生成ツールとして選びました。記事本文にはHugo専用の記法をできるだけ入れず、将来ほかのツールへ移しやすい状態にします。
次は、WordPress時代の記事URLを変えずに、Hugo側でどのように再現したかをまとめます。