ブログをWordPressからFreshに移行した過程の紹介②【技術選定と記事の移行】

どうも。Reoです。

このブログをWordPressからFreshに移行した話の続きです。

前回「背景編」を踏まえて、今回は実際にどのように着手していったかを紹介していきます。

Obsidian にやることを書き出す

WordPress製のブログを別のナニカに移行するにあたり、何をやる必要があるのか、どういうブログを目指したいかを書き出していきました。

とってもざっくりです。 上から順にうまく書き出していったわけではなく、思いついたことをメモしていっています。

現状をまとめる

そもそも現状ってどうなってるんだ？というのが気になったのでまとめました。

記事の構成とかもまとめました。

手順を考える

これもざっくりです。 各リンクで、それぞれまとめています。

このリンク内でそれぞれ何が書いてあるかざっくりと紹介します。

uruly.xyzで使う技術を選定する

• [[Deno Fresh]]
• GitHub submodule

とだけ書いてある。全然選定してないですね。決定版かも。

Obsidianの保管庫をブログとリンクさせる

Obsidian のディレクトリ構成が書かれていました。

└── post
    ├── 2024-09-11-slug1
    │   ├── index.md
    │   └── images
    │       └── hoge.png
    └── 2024-09-11-slug2
        ├── index.md
        └── images
            └── hoge.png
└── private
    ├── 2024-09-11-slug3
    │   ├── index.md
    │   └── images
    │       └── hoge.png
    └── 2024-09-11-slug4
        ├── index.md
        └── images
            └── hoge.png
└── draft
    ├── 下書き.md

完成版とはちょっとだけ違いますが、だいたいこんな感じになっています。

ブログを書く手順として、以下のようにしたいと書かれています。

1. draftで下書きを書く。
2. 日付を冒頭につけたディレクトリに必要な画像フォルダ images と.mdファイルを入れる
3. 公開する時に postディレクトリにぶち込む。
4. 公開後に非公開にしたい場合は postディレクトリから privateディレクトリに入れ直す。

だいたい本番でもこんな感じでやっています。

uruly.xyzのフロントエンドの実装について

Deno Freshを使いたい！ということで Deno Fresh について 調べてみた。

と一言だけです。

（Deno Fresh についての中でめちゃくちゃお勉強メモがあります。）

uruly.xyzのデプロイ方法について

開発は、Push したらデプロイされる方式であって欲しい。 記事の修正は即時反映がいいけれど、デプロイ時間があってもいいのか考える。

WordPress の記事をマークダウンにして書き出す

後述しますが、ツールを使えば簡単にできそうだなというイメージだけしていました。

実際にこの方法を用いました。

WordPressの記事をMarkdown形式に一括出力する方法より、1度xmlとして保存してから、node.jsのツールを使って変換する。

wordpress-export-to-markdown

uruly.xyzのマークダウンのattributes

実際に記事を書く時にマークダウンに追加したいattributesを考えてありました。

- title
- date
- categories
- coverImage
- tags

Deno Freshをお勉強しよう！

とにかく Fresh を使ってみたいという気持ちが大きかったので、まずはお勉強を始めました。

Deno をはじめよう

まずは、Deno 自体のお勉強を少し行いました。

Deno 日本語マニュアルを一通り読みました。例のところは試していませんが、途中のサンプルは実際に手を動かしながら読みました。

Fresh のドキュメントを読もう

Fresh のドキュメントは英語なので、そのまま読むとふわっとした理解になってしまうのが明らかだったので、翻訳をしました。ChatGPTに投げていました。

基本はドキュメントを翻訳して、もったいないのでそのままObsidian 上に残しておいただけですが、グラフビューを見るといっぱい勉強したんだなぁって気になりました。

Freshもドキュメントを読みながら実際に動かしてみて勉強しました。

ドキュメントを全部読むってことはしたことがなかったんですが、普通にいいですね。実際に使っていないことも多いですが、全体のフワッとした概要を知っているだけでも捗りました。

これで、移行先をFreshにする覚悟ができました。

WordPressの記事をマークダウンに変換する

Freshではマークダウンで書かれた記事を配置する予定だったので、これまでWordPress上で書いてきた記事はマークダウンに変換しなければいけません。

この方法についての詳しくは別記事で書きます↓ (TODO: 書いたらリンク貼る)

参考と使ったツール

WordPressの記事をMarkdown形式に一括出力する方法の記事を参考に、wordpress-export-to-markdownを使いました。

フォークしてカスタマイズ

WordPressでエクスポートした export.xmlには、カスタムフィールドやコメントの値が入っていますが、wordpress-export-to-markdownの機能には、それらの値を吸い出す機能がありませんでした。

リポジトリをプライベートでフォークさせてもらい、自分用にカスタマイズをしました。

WordPressでは自作プラグインで「追記」という機能を作っていました。カスタムフィールドを使っています。

これは、addition.md としてエクスポートするようにしました。

また、「参考リンク」という機能もカスタムフィールドで作っていましたが、その部分は記事の最後に追記するという実装をしてエクスポートするようにしました。

コメントも持ってきました。 今までコメントくれた方、ありがとうございます...！大事にかかえてきました。

現在はコメントフォーム機能を未実装なのですが、そのうち作ろうと思います。読んだよーだけでも嬉しいです。

Obsidianの保管庫として開いてみる

Obsidian 上でexportした記事を開きます。

年ごとに保存され、画像は各投稿の imagesフォルダに入っています。 また、追記を書いた時は各投稿のフォルダの中に additionsフォルダを作り、追記コメントを入れました。

コメントはファイル名を Dateにして保管しています。

この状態で、Obsidian上で画像が表示されなかったので、画像が表示されるように画像パスも修正してエクスポートするようにしています。

GitHubにリポジトリを作る

マークダウンになったWordPressの記事をGitHubで管理するようにしました。

詳細については別途記事を書きますが、これにて無事に全てのWordPress上のコンテンツをマークダウンに変換し、GitHubで管理できるようになりました。

どうやってFreshとコンテンツを紐づける?

さて、Freshのお勉強も終わり、既存の記事もマークダウンに変換できたところで最難関の「どうやってFreshとコンテンツを紐づけるのか」問題に直面しました。

この問題の解決策としてあげられた候補は以下の通りです。

• GitHub APIを利用する これは5000回/hourの制限があるらしい。絶対大丈夫っしょって思うけど、一旦保留。
• GitHub サブモジュールで紐づける ✅ 大成功 まずはこれを試す。
• なんかしらのDBを通す
• コンテンツ自体をFreshで配信する

大成功した方法しか結局試していません！

GitHubサブモジュールで紐づける

これについても詳しくは別途記事を書きます。

（TODO: FreshでGitHubサブモジュールからコンテンツを取得する記事を書く）

Fresh のリポジトリを親とし、コンテンツのリポジトリを子とします。

ひらめき

Freshの公式ブログ記事「# How to Build a Blog with Fresh」にて、Freshでのブログの作り方が書かれています。

ここではブログのコンテンツは、Freshプロジェクト内の posts に入れられます。

my-fresh-blog/
├── .vscode
├── posts        　👈 ココ
├── routes
├── static
├── deno.json
├── dev.ts
├── fresh.gen.ts
├── import_map.json
├── main.ts
├── README.md
└── twins.config.ts

postsの中にブログ記事のコンテンツである first-post.mdが配置されます。

この部分だけ別のリポジトリにしたくない？と思い、サブモジュール化を思いつきました。

これにより、API等や外部DBを使わずに Deno.readTextFile を使って、内部のコンテンツを取得しています。

同期は一手間

git サブモジュール機能を使うのは初めてだったんですが、サブモジュール側のコンテンツを更新した後に、親のFreshも更新しなければ変更は反映しません。

開発時は、コンテンツを更新したら git submodule update --remote を行ってコミットをしながら変更を反映させていました。

最終的には以下の workflow を実装して、コンテンツのリポジトリを更新すると再デプロイするようにしています。

• サブモジュール側に workflow (Freshのworkflowを実行する)
• Fresh 側の デプロイ時の workflow にサブモジュールの更新を組み込む

コンテンツとFreshを紐付けてローカルで記事を表示し、それがデプロイ後にも表示された瞬間は嬉しかったです。

まとめ

そんなこんなで、以下のような構成に決まりました。

	これまで	これから
フロントエンド	WordPress	Fresh 🍋 (フルスタック)
コンテンツ管理	WordPress(MySQL)	GitHub サブモジュール (DBは使っていない)
サーバー	Xserver	Deno Deploy(サーバーレス)
コンテンツエディタ	WordPress の Classic Editor	Obsidian
ローカル環境	VVV	Deno 環境
デプロイ方法	wordmove	Deno Deploy

つづくかも

あとは地道にFreshで構築をしていくだけなんですが、何か書けることがあったら続きます。