ブログをWordPressからHugoに移行した
前々からブログをWordPressで運用するのをやめたいと思っていた。 すったもんだのすでにようやくHugoで運用するようにできたので、経緯やら苦労したところなどを書き残しておきたい。 まだ作業途中ではあるのだが、いい加減記事の更新もしたいので書いておく。
以前のブログはWordPressで運用していた。 自分でテーマをいじったり、関連記事の表示に自分でクエリをカスタマイズしてごにょごにょしたりして、ある程度カスタマイズして使っていた。 だが、それも途中からだんだんと面倒くさくなっていた。
理由としては、ローカルでいじる際にいちいちvagrantでWordPress環境を立ち上げてカスタマイズしなければならなかったからだ。 カスタマイズしたらカスタマイズ下で、wordmoveを使ってテーマを更新したりが必要になる。 あげく、途中でSassのソースファイルを喪失してしまった。おかげでスタイルシートをいじるのが著しく困難になってしまい、もうこりゃだめだとWordPressでのブログ運用をやめることにしたのだ。
そもそも記事の更新もMarsEditを使ってMarkdownで書いて送信するだけ(WordPressの管理画面はまず使わない)という状況だった。 もうここまでくるとWordPressで運用する意味ないよね、というのがHugoに移行した経緯だ。
最初はHugoではなくGatsbyでやろうとした。
実はコンテンツデータはGatsbyを使ってWordPressから引っ張ってきてMarkdownファイルにしたので、Gatsbyへの移行作業も無駄ではなかったりする。
GatsbyはReactコンポーネントを使ってWebサイトを組み上げていくので、デザインはとてもしやすいと感じた。 テーマも豊富でその点はものすごくやりやすかった。
にもかかわらずGatsbyへの移行を断念したのは、GraphQLが辛かったというのが大きい。
GraphQL自体は私は好きである。 本格的に触ったことはないが、軽く触って便利だなぁ、面白いなぁと思っている。 ただ、静的サイトジェネレータとしてブログを運用する観点においては、GraphQLは過剰すぎると思う。 単にローカルにあるMarkdownファイルを読み込んで、いい感じにサイトを構築してくれれば十分なのだが、ローカルにあるMarkdownファイルを捜査して、その上でGraphQLを使って読み出すというのが無駄な手間に感じられて仕方がなかった。 ローカルのファイルとリモートのWordPressのコンテンツを一緒に扱うこともできるので、その点は便利だったりするが、私はそこまでの機能を求めていない。
致命的だったのはGatsbyではページネーションの処理があまりに面倒くさかったことだろう。 ページネーションというのは、例えば記事の一覧画面である。 一画面に10記事表示して、表示しきれない分は次のページに移動して表示するアレだ。
Gatsbyではこのページネーションを自分でハンドリングする必要がある。 xページ目に表示されるページを、自分で別途作成しないといけない。 GraphQLのクエリで記事を全件取得して、1ページに表示する件数ごとに新たにページコンテンツを生成して・・・みたいなことが必要だった。 記事一覧はなんとか作り上げたものの、これを例えばタグ一覧、カテゴリ一覧ごとにやる必要があるのかと思った瞬間、こりゃだめだとGatsby化は諦めたのだった。
ページデザインとかは確実にGatsbyの方がやりやすかったのだが、ブログの運用をするにはちょっと不便すぎた。
他の静的サイトジェネレータを探したところ、Hugoに白羽の矢が立った。 Golangの勉強にもなっていいかなと思って手を出した1。
Hugoのいいところは、WordPressのような感覚でサイト構築ができるところだ。 一定のルールに従いテンプレートファイルが適用され、サイトが構築されるのである。 WordPressをさらに簡潔にしたようなテンプレート適用ルールで、だいたいlistとsingleだけで事足りる感じである。 (もっとも、それはカテゴリをなくすつもりでやってるからであるが) WordPressで培った感覚が、全てではないものの流用できるので、その点ではWordPressから移行するにはちょうどよい感じであった。
最初のうちはGolangまったく調べずにHugoへの移行作業に取り掛かったのだが、さすがにgotourくらいはやっておいたほうがいいと思う2。 クラスがなくて、構造体をレシーバーとした関数を定義することでメソッドを実現する仕組みなどは、gotourをやることでようやく理解できた。 このあたりはKotlinやってるので理解しやすかったかもしれない(構造体をレシーバとした関数定義のあたり)。
ただ、Hugo自体はGolangで作られているのだが、あんまりGolangっぽくない。 というのも、テンプレート内にコードのようなものを埋め込んで記事データを表示したりするのだが、テンプレート自体はWordPressと異なり実行プログラムではないのである。 Hugoにおけるテンプレートは、Hugoのプログラムで読み込まれる、文字通りのテンプレートなのだ。
テンプレートにおいて{{}}でくくった部分が、Hugoのプログラムで認識され、その中身が処理されて置き換えられる仕組みなんだと思う。
したがって、テンプレートファイルにプログラムっぽいものを書きはするものの、ここにブレイクポイントをおいて処理を止めることができない3。
ではどうやってデバッグするのかというと、変数を{{ printf "%#v" . }}のようにして出力して確認するしか方法がない。
この点はとてつもなく不便だった。
しかも出力される内容がよくわからず、変数としては持っているはずなのにpublicな変数ではないからアクセスできないとか、どうやったらアクセスできるのか調べる手段がよくわからず苦労した。
godocを読めばわかるのかもしれないが、これもまた読み方がさっぱりわからず。
もうHugoのドキュメントを読むしかなかった。というかそれが全てである。
ちなみに{{ printf "%#v" . }}の.はなんやねんという話だが、これはJavaなどでいうところのthisのようなものだ。
使う場所によってページコンテキストを表してたりするが、まあこれはそんなにややこしいものではない。
それ以上にややこしいのは、テンプレート内にコードを書くのがかなり大変ということだろうか。
例えばif (a > 10)みたいなif文を書くと思うが、Hugoでは{{ if gt a 10 }}と書く。
まあこれくらいならそんなにややこしくないのだが、では配列のx番目のデータを参照するみたいなことをやろうとすると、これがまたややこしい。
a[0]みたいな指定はHugoではできない。
代わりにindex a 0のようにする。
このあたりがややこしい。
HugoはWordPressを使うほどではないシンプルなブログ運用にはちょうどよいと感じた。 Gatsbyと比べると、特に工夫する必要もなくページネーションをいい感じにできるのがよい。
WordPressとは違ってよく使う処理を独自の関数にして使い回す、みたいなことはできないが、テンプレートのpartial機能を使うことで、コンポーネントの再利用が簡単にできる。
また、Hugo自体にSassのコンパイルやCSSのminify処理(PostCSS処理)をする機能が含まれており、そのあたりの初期設定に頭を悩ませることなく実行できるのはとてもよいと感じた。 (ちなみに途中まで存在に気づかず、自前でnode-sass使ったりしてコンパイルしていたのは内緒だ)
これでvagrant(virtual box)の無駄なイメージファイルともおさらばできるので、そういう意味でも快適になった。 記事の更新頻度もちょっとずつ上げていきたいなと思う。