昨日、Wordpressで運営していたブログをGatsbyに移行させる作業を行いました。(といっても、中身を写しただけなのでデザインはデフォルトのままですが・・・)
その途中、いくつかハマったポイントがあったので、移行手順と合わせて解説していきます。
##Gatsbyとは
GatsbyはReactベースの(静的)サイトジェネレータです。詳しくはこの記事を見てください。超わかりやすいです。
Reactベース静的サイトジェネレータGatsbyの真の力をお見せします
ざっくり言うと、Wordpressで構築していたブログやLPをReactで構築できるよってことです。Wordpressの便利なダッシュボード画面はありませんが・・・
Wordpressと比較した場合のメリット・デメリットを箇条書きにすると、こんな感じです。
メリット
- SPAで構築できる
- Reactでガリガリ書けるのでカスタマイズの自由性が高い
- バージョンをGitで管理できる
- markdownでも記事を書ける
デメリット
- テーマレベルでのSEOを自分で施す必要がある
- プラグインが圧倒的に少ない
SPAで構築できるのが素晴らしいメリットだと思っていて、ページ遷移時のロード時間を無にできるのでUXの大幅な向上が期待できます。
また、「Wordpressで記事更新 → Gatsbyアプリの自動ビルド」のパイプラインを組んでおけば、非エンジニアの人でも気軽にGatsbyブログを更新することができそうです。
ただ、Wordpressのように基本的なSEOを施された基本テーマなどは(多分)存在しないので、自分で考えながらデザイン、マークアップを行う必要があります。そういう意味ではハードルが高いかも。
Gatsbyへの移行手順
Gatsbyにブログを移行する場合、大きく分けて2つのアプローチがあります。
- Wordpressの記事データをGatsbyに移行させる
- gatsby-source-wordpressを使って、ビルド時にWordpressからデータを取得する
一からGatsbyでブログを始めるなら1のアプローチでよさそうですが、既存のWordpress
から移行する場合、ちょっと面倒そうです。
Wordpressから記事データをcsvで落とし、記事タイトルなどをmarkdownに変換する・・・といった手順が必要になるからです。
幸い、「gatsby-source-wordpress」というパッケージを使えば、Gatsbyアプリがビルドされる際にWordpressから各種データを取得することができるので、今回はこれを使うことにしました。
Gatsbyアプリを生成する
なにはともあれ、まずはGatsbyパッケージをインストールしましょう。(node.jsがインストールされている必要があります。)
npm i -g gatsby
グローバルに導入するのが嫌な方は、適当なディレクトリを作って、-gオプションの代わりに--save-devを指定します。
Gatsybyアプリの生成は非常に簡単で、コマンド一発です。(前の手順で--save-devオプションを指定した場合は、binファイルの中にある実行ファイルのパスを指定する必要があります)
gatsby new (アプリ名) https://github.com/gatsbyjs/gatsby-starter-hello-world
これでGatsbyアプリが生成されます。
また、gatsby-source-wordpressを最初から含まれているスターターも公開されており、
gatsby new (アプリ名) https://github.com/GatsbyCentral/gatsby-starter-wordpress
で導入可能です。こちらのほうがgraphQL周りの設定が最初からある程度行われているので、よりスムーズにWordpressからデータ取得ができます。(gatsbyではデータ取得にgraphQLを使います)
gatsby-config.jsの編集
wordpressと連携させるには、ルートにあるgatsby-config.jsファイルの編集が必要です。ただ、変更内容は簡単で、以下のように「baseUrl」と、「includedRoutes」を変更するだけでOK。
plugins: [
'gatsby-plugin-react-helmet',
'gatsby-plugin-sass',
{
resolve: 'gatsby-source-wordpress',
options: {
// WordpressのURLを指定
baseUrl: 'programmer-beginner.com',
hostingWPCOM: false,
protocol: 'https',
useACF: false,
auth: {},
verboseOutput: false,
// 叩きに行くrest apiのpath
includedRoutes: [
"**/categories",
"**/posts",
"**/pages",
"**/media",
"**/taxonomies",
"**/users",
"**/tags",
],
},
},
ここまでできたら、「gatsby build」や「npm run build」でビルドが可能になります。(開発サーバーを立ち上げる場合は「gatsby develop」、または「npm run start」)
あとは、githubにリポジトリを作り、pushしておきましょう。
Netlifyにデプロイする
Netlifyは静的サイトを簡単にデプロイ、公開できるサービスです(無料)。
デプロイ手順も非常に簡単で、githubと連携し、デプロイしたいブランチを選択するだけ。
詳しいデプロイ手順はググってみてください。
wordpressの記事更新をフックに、Gatsbyアプリをビルドする
gatsbyはリアルタイムにwordpressからデータを取得するのではなく、ビルド時にまとめて取得するようです。
そのため、wordpress側で記事を更新しても、そのままではgatsbyには反映されません。記事更新のたびに手動でビルドしてもいいのですが、それはめんどくさすぎてちょっと...ってなりますよね。
ということで、調べてみたら「JAMstack Deployments」というWordpressプラグインがあり、それを導入してNetlifyのプロジェクトApiを入れれば、記事更新などのイベントをフックにNetlifyでの自動デプロイが可能になるようです。
まだ試していませんが、とりあえずこの方法でやってみる予定です。
Gatsby移行時のハマりポイント
移行作業時にハマったポイントが3つあったので、それらについて解説します。
権限がないpathを叩きに言ってしまう
gatsby-config.jsにincludedRoutesの記述がない状態でbuildすると、全てのrest api pathを叩きに行くのですが、その中に権限がないpathが含まれていると401エラーなどが発生します。
akismetとかのプラグインの設定情報はいらないので、includedRoutesに欲しい情報だけを取得するように記述しましょう。
タグや記事が一つも存在しないとgraphQL実行時にエラーが出る
graphQLでデータを取得した際に、そのデータが空だと以下のようなエラーが発生します。
error Cannot query field "allWordpressTag" on type "Query". Did you mean "allWordpressPage", "allWordpressPost", "wordpressPage", "allWordpressCategory", or "allWordpressWpMedia"?
GraphQL request (3:11)
2: {
3: allWordpressTag(filter: { count: { gt: 0 } }) {
^
4: edges {
error gatsby-node.js returned an error
GraphQLError: Cannot query field "allWordpressTag" on type "Query". Did you mean "allWordpressPage", "allWordpressPost", "wordpressPage", "allWordpressCategory", or "allWordpressWpMedia"?
とくにタグは設定していない人が多いと思うので注意です。(自分もそうだった)
Xサーバーの設定により、/wp-jsonへのアクセスが弾かれる
これの解決に2時間くらいかかって、途中で半泣きになりそうでした。
build時にwp-jsonへGETリクエストを送りますが、Netlifyでデプロイした場合にのみ、403エラーが発生します。
ブラウザで普通に閲覧できるし、ターミナルから直接curlで叩いても問題ないし...で詰みそうになっていましたが、原因はWordpressを乗っけているXサーバーにありました。
どうやら、Xサーバーは海外IPからの/wp-jsonへのアクセスをデフォルトでは弾くようになっているようです。
WordPressの「REST API」に対する国外IPアドレスからのアクセス可否を変更できる「REST API アクセス制限」機能追加のお知らせ
Xサーバーにログインし、この制限を解除することで無事デプロイできました。
まとめ
SEOの面で考えると、Wordpressで運営するほうが無難かな、とは思います。
ただ、デザインやSEOをしっかり考えて構築すれば、技術的なポートフォリオとしても活躍しそうです。
移行だけなら難しくないので、興味がある人はぜひ一度トライしてみてはどうでしょうか?