WordPressとGatsbyの組み合わせは非常に強力です。WordPressはCMSとして完成されていますし、Gatsbyと合わせて使うための環境も整っています。また、WordPressのセキュリティー対策などもあまり考えなくて良くなります。ページの構成要素としてReactを手軽に使えるようになるのも大きいです。
エビスコムのこのサイトもWordPress&Gatsbyをベースにして管理していますが、なかなか便利です。
リクエストを頂くこともあるもので、うまくまとめられないかと原稿を書き始めるのですが…そのたびにちゃぶ台返しを食らっている感じでして、まとめきれるかは自信がありません。
そこで、WordPressとGatsbyを組み合わせる際に、個人的に大きな壁になっているポイントを残しておこうと思います。
GatsbyとWordPressの組み合わせ
GatsbyとWordPressを組み合わせて扱うのは簡単です。新規にプロジェクトを作成するのであれば、
$ gatsby new
<省略>
? Will you be using a CMS?
(Single choice) Arrow keys to move, enter to confirm
No (or I'll add it later)
–
▸ WordPress
Contentful
Sanity
DatoCMS
Shopify
Netlify CMS
<省略>
? Configure the WordPress plugin.
See https://www.gatsbyjs.com/plugins/gatsby-source-wordpress/ for help.
⦿ url : http://Server_address/graphql
This should be the full url of your GraphQL endpoint set up by WP GraphQL
という感じで、設定の済んだプロジェクトを手軽に用意することができます。
では、何が問題なのか？
Gutenbergの扱いです。
ネット上で Gatsby & WordPress に関する情報を探すと、WordPressをリッチテキストエディタベースのCMSとして扱っているものがほとんどです。
ただ、Gutenbergをリッチテキストエディタ的に扱うには、無駄なHTMLコードが多すぎます。そこで、Classic Editorをインストールしたくなるわけですが、WordPress 5.8での変化を見ているとオススメできる状況ではありません。
どうしてもリッチテキストベースで使うのであれば、TinyMCEベースのWordPressとして開発が続いているClassicPressの方がオススメです。WordPress 4.9をベースにしているため構造的にもシンプルですし、試した限りではWPGraphqlも問題なく動いています。
https://www.classicpress.net/
もっとも、リッチテキストエディタベースのCMSであれば、WordPressでなくても他に選択肢があります。
現時点でWordPressを選択するのであれば、Gutenbergを活かして、ブロックエディタを活用するのが自然だとおもいます。Gutenbergに匹敵するレベルの完成度を持ったブロックエディタも、ちょっと見当たりません。
GatsbyでGutenbergを活かす
GatsbyでGutenbergを活かす方法も非常にシンプルです。GutenbergのブロックのCSSをGatsby側に持ってくるだけですので。
CSSを持ってこれれば、Gatsby側で取得したコンテンツはレスポンシブ対応なものになります。あとは、コンテンツの周りやメニューなどを作成するだけで、構成としては非常にシンプルに仕上げることができます。
ただし、Gutenberg周辺のCSSに関する知識が必要です。CSSそのものだけでなく、その管理や出力方法など現状のWordPressにおいて非常に頭の痛いことの１つです。
さらに、それを理解した上で問題になるのが、GutenbergのブロックのCSSをGatsby側に持ってくる標準的な方法が確立されていないということです。
ネット上では、様々な方法が検討されていますが、どれも問題を抱えています。
@wordpress/block-libraryを使う方法
Gutenbergの公式パッケージである、@wordpress/block-libraryを導入して、
import "@wordpress/block-library/build-style/style.css"
import "@wordpress/block-library/build-style/theme.css"
といった形でCSSを読み込むことができます。これで、コアブロックに対応できます。
十分な気もするのですが、ブロックのコードの変更に追従してくれません。WordPressのアップグレードに合わせて、確認し、必要に応じてこちらも更新する必要があります。
また、プラグインで追加したブロックは全く考慮されていません。ブロックを追加するのであれば、そちらの対応も考える必要があります。
enqueuedStylesheets を使う方法
WPGraphQLを導入したWordPressでは、enqueuedStylesheets というフィールドを使うことができます。
これを利用してURLを生成し、各ページで使われているCSSを取得するという方法があります。
WordPressを起点としてCSSを管理できますし、プラグインで追加したブロックにも対応可能です。しかし、現状のgatsby-source-wordpressでは、このフィールドを扱うことができません。
その理由はこのあたりで読むことができますが、解決までにはまだまだ時間がかかりそうです。
https://github.com/gatsbyjs/gatsby-source-wordpress-experimental/issues/110
どうしてもという場合は、gatsby-source-graphqlを併用するという回避策もありますが…。
また、現時点のenqueuedStylesheetsでは、Global Stylesを取得できません。
Global Stylesも扱いたい
WordPress側での扱いもちょっと持て余し気味なGutenbergのCSSですから、仕方がないところではありますが、妥協するか力技で行くかの選択が必要な状況です。
構成が大きく変わらないのであれば、WordPressが吐き出したCSSを適度に編集して持ってきてしまうというのが一番簡単でしょう。
理想としては、WordPressを起点として、CSSを取得し、Global Stylesも扱えるようにしたいという感じでしょうか。そうなるとWPGraphQLをカスタマイズしてしまうのが手っ取り早いということになります。
enqueueされているCSSをフィルタリングした上で、Global Stylesと合わせてファイルに出力し、GraphQL経由で取得するといった形で試してみましたが、レスポンシブに加えて、ベースデザインの設定まで（WordPressの）GUIで管理できる環境が実現できます。なかなか便利です。
ただ、WordPressが落ち着いてくれるまでは、なかなか厳しいです。5.8での変更のおかげで、根本的なところから見直すことになりましたし…。
WordPressそのものが揺れ動いているために、WPGraphQLが動けず、それを受ける形の gatsby-source-wordpressも見守っているような現状です。WordPressそのものが落ち着いてくれないことには、どうにもなりません。
目的が明確だったり、自分で管理する環境であれば、チャレンジする価値は十分にあると思いますが、それ以外ではちょっとオススメしきれないのが正直なところです。
非常に強力な環境なだけに、もったいないのですが。
WordPress 6 あたりでは、落ち着いてもらいたいものです（無理っぽいですが…）。
