技術blogをWordPressからAstroに移行
WordPressからAstroに乗り換えた。
背景
- 技術blogをWordPressで構築していて、それなりにしっかりした構成(ECS Fargate, ALB, Docker, RDS)にしていた
- 学習目的も兼ねていたのでしっかいしていたけど、コストがかかる。月額50〜100ドル
- 節約したい
要件
- 既存のblog記事を全て移行した状態とする
- Wordpressの記事の本文以外の情報、つまり日時、カテゴリ、タグ、URL、アイキャッチ画像、本文画像などを可能な限り維持すること
- blogはMarkdown形式に変換し、今後はMarkdownで書いていく状態とする
移行先の選定
技術blogなので、SaaS系ならQiitaかZennが良さそう。
でも利用規約に縛られながら書くのは嫌だし、Zennはimportができなさそう。デザインはすごく良いのだけど。
microCMSなどを組み合わせるのもいいけど、そこまで必要ではない。CMSよりは静的サイトの方が良さそう。以前に調査したときにGatsbyが一番筋が良さそうで自分にあっていると思ったのでそれを選定しようかなと思ったのだが、Astroもなかなか良さそうだったのでこちらにチャレンジすることに。
移行調査
まずは調査。
- https://zenn.dev/aono/articles/7d2c0277512bf4
- https://zenn.dev/trictrac/articles/4c843861f7d7c03e054f
- https://qiita.com/akashixi/items/9653d0a6522117618e0f
- https://www.alpha.co.jp/blog/202401_01/
- https://zenn.dev/yukiyada/articles/d5681300a7fc28
- https://docs.astro.build/ja/guides/migrate-to-astro/from-wordpress/
WordpressをHeadless(記事データのGraphQL API)として、フロントをGatsbyとする方法もあるようで、Wordpressのエディタを使いたいならば良い方法だとは思う。ただ、Wordpressのサーバコストは払えないので、この方法は今回は不採用。
microCMSもいいのだけど、リッチエディタやCMSが必要かというとそうでもなくて、Markdownをファイル管理するだけで十分であった。
また、Gatsbyの場合はGraphQLを挟むけど、Astroの方はMPAとして完全にstaicにもできるようで、その点は嬉しい。
記事データを全てファイル化してAstroに取り込んで、以後はmarkdownや画像ファイルをgitリポジトリ管理する方針に決定。
移行
かなりいろいろカスタマイズする羽目になったので、Astroは非技術者にはあまりおすすめできないかなという印象。
URL
私のもとのblog(WordPress)では https://tech-blog.tsukaby.com/archives/172
というURLであり、Astroのblogテンプレートで生成した初期コードでは http://localhost:4321/blog/using-mdx/
というURLになっている。そのため、このまま記事を移動してもURLが合わない。別途301をかければ良い話でもあるが、面倒なので同じURLにする。
src/pages/blog
を src/pages/archives
に変更しつつ、 index.astro
内の各種ページへのリンクを変更。
記事の降順
記事を降順に変更。
const posts = (await getCollection('blog')).sort(
- (a, b) => a.data.pubDate.valueOf() - b.data.pubDate.valueOf()
+ (a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf()
);
データの用意
npx wordpress-export-to-markdown
詳細は割愛。他の記事でいろいろ解説されているが、このツールを使ってWordPressの記事のXMLをMarkdownに変換。
ありがたい。
またデフォルトではファイル名が意図したものではないので、post_id.mdにmvでリネームしておいた。
schema変更
前述のツールで生成したmdの冒頭にはdescriptionとpubDateがない。
Astroのblog templateだとデフォルトではこれらは必須になっている。
descriptionはmeta descriptionに使われているだけで不要だと思ったので、config.ts
でdescription: z.string().optional(),
として、optionalにした。
このあたりとか私は本業でzodを使っているし、使っていなかったとしても技術者であれば変更できると思うが、被技術者にはカスタマイズは厳しいと思う。
仕事でもAstro使えるかな?と思ったけど、このあたりが絡んでくるとマーケやセールスに活用してもらうにはひと工夫要りそうで厳しい。
技術者がカスタマイズすればいいという話でもあるけど、そういうことを極力減らしたいからWordPress等のCMSが流行ってるのよね。
話がそれたが、dateは全mdファイルへ置換を実行してpubDateに変換。
heroImage
もないが、WordPress側から持ってきたmdではcoverImage
となっているので、ここも単純に置換。
画像
画像はwordpress-export-to-markdown
でDLされるのでそれでも良いのだが、いくつかDLに失敗しているものがあったので、aws s3 cp
で手動でDLしてきて、public/images
以下に配置した。
前述のheroImage
や記事本文内の画像のパスなども必要に応じて適宜置換したりして調整。
WordPress時代は正方形に近い画像をアイキャッチとしていたが、Astroのblogテンプレートでは横長の長方形を前提としたデザインになっているので、一部のCSSを調整して、正方形画像でも大幅に崩れないように調整。
その他
ヘッダにLinkedInのリンクとSVGアイコンを追加。Astro blogテンプレートではBootstrapのSVG画像を使っているようだったのでそこと統一。
他にも色々実施。
- ページのタイトルを変更
- TOPページは不要なので削除して記事一覧ページに差し替え
- 日付表示をja-JPに変更
- デフォルトで生成された不要なmdなどを削除
- 新しい.astroのコンポーネントを作成し、GTMのJSタグを追加
- Astro公式のチュートリアルを参考にしつつタグ一覧ページを作成
Astroで早速記事を書いてみた所感
この記事自体がそうなのだが、特に不便を感じない。強いて言えば画像を投稿したくなったときにWordPressの方が楽だなと感じる。
エディタについてはもともとWordPressの方が使いやすいと感じることもなかったため、特に不便には思っていない。
デザインをある程度自分で調整したりタグ一覧ページがデフォルトで無かったりなど、そういう不便さは感じたので、全部用意されているか簡単にアドオンできるWordPressは偉大だなと感じた。
ただ、これでコストを大幅に削減できるので、満足。