久しぶりの投稿ですが、新年始めての投稿になります。 しばらく投稿が滞りましたが、これには深い理由がありまして、 みてわかるようにこのブログSo Far, So Techを12月から年始にかけてせこせこと Gatsby+Netlifyでリプレース作業をしていました。
結果的に1ヵ月ほど仕事の合間にせこせこ作業して今回無事リプレースを終えることができました。 Wordpressのブログよりまだまだ機能は少ないですが、今後も必要そうな機能をたしていこうかな なんて思っております。
Wordpressからの移行作業では紆余曲折いろいろなことがありましたので、 なんで機能豊富なWordpressをやめてGatsbyでサイトを作ろうと思ったのか、 移行で苦労した部分などをまとめます。
なぜWordpressをやめたか、なぜGatsby+Netlifyを選択したのか?
まず、なんでWordpressをやめたのかというところですが 大きく分けてここらへんになると思います。
- Wordpressのコードと向き合う勇気がもてなかった。
- CSS書くのがつらい。
- コードがgit管理できない。コードミスると一発でサイトが動かなくなる。
- もっとカジュアルに記事をかきたい。(Markdownなど)
一応箇条書きにしましたが、Wordpressをやめたかった理由は
「Wordpressのコードと向き合う勇気が持てなかった」
という一言につきると思います。
Wordpress導入当初は、ブログを書くために導入コストの低いWordpressを選択しましたが、 ブログを続けているうちにだんだんとWordpressがつらくなってきました。
普段の開発の仕事はPHPを書いているわけでもないし、Wordpressを使って仕事している わけでもないのでWordpressと悪戦苦闘しながら現在の標準になっているような開発 の仕方を取り入れていくことに全くもってメリットを感じませんでした。
cssを書くにも、コードを修正する、ソースを管理するにもなんにしても Wordpress独自の手法をインプットしつつこのサイトに適用していくといく作業が非常に 苦痛に感じられました。
その点、GatsbyはReact+Graphqlで静的サイトを構築できもちろん普段使い慣れた npmパッケージも利用できるので自分の技術スタックとの親和性や興味の観点からで もピッタリでした。
記事をコードとして編集して、コミットしてmasterにプッシュすれば記事が公開 されるというのが普段の開発と同じようにできるので、仕事しながら記事を書く上で 抵抗なく使えます。
まぁ色々と理由はあるのですが、 単純にGatsby使うとReactでコード書きながら自分のサイトを思い通りに構築できるので、 移行作業そのものが楽しかったですし、今後もストレス少なくサイトのメンテを行えそうです。
リプレースにあたってやったこと
Wordpressからgatsbyに移行するにあたってやったことを載せておきます。 Wordpressはやはり機能豊富でgatsbyで一から全部作っていくのはなかなか 骨がおれましたが、だいたいどのサイトでも以下の作業は必要かな という感じです。
AMP対応は結構大変だったので、ここは個人の判断でリプレース前に対応するか、 リプレース後に対応するかというところは決めれば良いのではないでしょうか。
- 記事の移行
- 画像の移動
- Wordpressの機能の再現
- AMP対応
記事の移行
WordpressはAPI機能があるのでそれを使えば、Wordpressで記事を書いてGatsby 側でAPIを叩いて記事を生成するということができそうなのですがWordpressとの 関係をなるべく切って行きたかったので、既存の記事をSQLでcsvとして出力して スクリプトを書いてmarkdownに変換してきました。
スクリプトは慣れているrubyで書きました。 https://github.com/version-1/blog/blob/master/scripts/wp2md/index.rb (一度変換したあとは使っていないのであまり綺麗ではないです。)
gatsbyではマークダウンのヘッダに記事のタイトルやテンプレートの情報を 書き込むのでcsvから必要な情報を抜き出し、ヘッダに書き込み、記事部分は そのままcsvのものを突っ込むようなスクリプトです。
wordpressで記事は基本的にhtmlで書かれますが、markdownがhtmlのタグ も許容しているので記事部分はそのままコピーしています。
ただescapeされているhtmlを元に戻す作業など地味だけど大変な作業もありました。
画像の移動
画像の移動はとりあえず、手元から配信する感じにすればいいやーという 甘い考えで取り組みました。 画像はwordpressの物をそのままコピーしてきてもよかったのですが、 どの記事でどの画像を使っているのかが一発でわかると楽なので、
[ 記事ディレクトリ ] +- index.md
|- image1.png
|- image2.png
のような形で保存されるように工夫したりしました。
こちらもスクリプト書いて対応しました。 https://github.com/version-1/blog/tree/master/scripts/fetchImages
ただ、手元に画像を保存してgatsby-imageで画像を読み込む感じにしたところ 開発中でも都度画像がblobに変換されるのでビルド時間がのびて開発中とても ストレスフルな状態になったので、 画像は外部に置く感じにしてs3 + cloudflareで配信するようにしました。 (手元に画像はあったので階層構造そのままs3にアップロードしました。)
Wordpress機能の再現
自分で実装するとわかるのですが、WordpressおよびWordpressテーマ、プラグインには豊富な 機能があり、自分で実装するとそのありがたみがわかってきます。AMPなどもそうですが、 ありがたみを感じながら、Wordpressとの縁を断つべく感謝の移行作業の一覧はこちらです。
- レイアウトの変更
- ページネーション
- sns ボタン
- GA
- Adsense
- ogp
- rss
- 404ページの作成
これら全部が全部自前で実装したわけではなく、プラグインを導入したりしたものが ほとんどなのですが、wordpressで実装されていた機能を洗い出し取捨選択して実装していく 一連の作業がそれなりに骨が折れました。
Adsenseの埋め込みなどは、記事外部には自由にreactコンポーネントで実現できるのですが 記事内(マークダウン内)にどうやってAdsenseをはめ込むかなどは考えて実装しました。
Gatsbyという記事を採用する以上ここの大変さはある程度しょうがないですが、リプレースに むけて本当に必要な機能を絞り込んで実装していくのが大切かなと思います。 実際現状関連記事の表示や月別アーカイブ、タグ機能、検索などなど機能が不足しているので おって実装していく形です。
AMP対応
これが4つの中で一番大変でした。単純な記事のAMP化もあるのですがvideoタグやiframeなど などそれぞれのタグが必要だったりadsense, gaなども個別で対応必要だったりして大変でした。
当初はプラグインがあるので「これで行けんじゃね??」と思っていたのですが、 プラグインが思うように動かず自分で実装しました。 (jsdomがうまく動かずとりあえずissueだけあげときました。)
自分で実装してnetlifyにあげた時にこれだけのAMPエラーが見えた時はさすがに心が折れかけました。
gatsbyでのAMP対応は大変だった分学びも多かった気がするので別途記事にするかもしれません。
Gatsby導入をオススメする人の特徴
今回Gatsby+Netlifyでブログをリプレースしましたが、 やっぱり自分の興味ある技術を使って開発をしていくと多少大変でも面白みがありました。
そんな中で、実際にGatsby導入をおすすめする人の特徴をまとめると こういう感じになります。
- Wordpress辞めたい
- ブログも普段の開発同様の運用にしたい
- Reactが使える(使えるようになりたい)
- 英語のドキュメントが読める
ここまで色々と書きましたがGatsbyで実際にブログを構築していくにはそれなりの 技術力が必要だと感じています。日本語の情報はやはり少ないですし英語のドキュメントを 読みながら試行錯誤していく必要があります。
ただ、Gatsby+Netlifyのような構成でブログを構築すればほぼお金がかからず (ドメイン代くらい) にすむのでレンタルサーバ+Wordpressよりは安くすみそうですし、 Reactを初めしたWebフロント力をつけていくことができます。
Wordpressやめたいんだけどなんか良いCMSライブラリないかなぁなんて人にはオススメです。
まとめ
今回のリプレースは大変でしたが、Graphql使ったりnetlify使ったり、Reactのコード書いたりで 楽しみながら作業させてもらいました。
AMP対応などなどそれぞれの知見は記事にできればなと考えておりますので折を見て投稿していきます。
では。