当メディアサイトは長らくWordPressのテーマとして運用していましたが、今回SSGを使って完全な静的サイトへの運用に移行しました。ただ、投稿記事のデータはこれまで通りCMSとしてWordPressで運用していくので、ヘッドレスCMSとしてテーマを改修し、ページテンプレートは静的ページとしてフロントエンド側で用意していく形になります。今回はWordPressをヘッドレスCMSとして、ページテンプレートはNuxt.jsのSSGを使ったJamstackという構成のサイトを作成するまでの流れをまとめていきたいと思います。  

ヘッドレスCMSとは？

従来型のCMSは投稿データをデータベースに書き込む、またはデータベースから呼び出す機能に加え、そのデータを出力するウェブページ自体もサーバー側のプログラムで用意されるような一体型の形となっていました。それに対してヘッドレスCMSはデータベースへの読み書き（管理画面などのインターフェースを含む）と、そのデータをウェブページ側に送るためのAPIの仕組みだけを持つ構成になります。   つまり、ウェブページ側はフロントエンドで用意することになり、ヘッドレスCMS側ではあくまでデータの登録・呼び出しだけを担うというものになります。ですのでサーバー側でPHPなどのプログラム言語でページが生成されなくなります。ヘッドレスCMSにはWordPress以外にも様々なものがあり、それぞれ特徴があるのでまた改めて記事として紹介してみたいと思います。WordPressのテーマ作成では投稿データを表示するページテンプレート作成を合わせて行うのが一般的ですが、今回はヘッドレスCMSとして使うので、投稿の機能とAPIなどに関連する処理だけを用意しておきます。  

Jamstackとは？

Jamstackは「JavaScript」「API」「Markup」の頭文字をとった新しいウェブサイトの構築手法で、その名の通りAPIから取得したデータをHTMLとJavaScriptを使って静的サイトとしてホスティングする構成となります。ですので、表示速度の向上やセキュリティリスクの軽減、また静的ホスティングで公開できるお手軽さなどのメリットがあります。もちろんページコンテンツもJavaScriptを使って動的に更新することも可能です。   ただし、事前にAPIからデータを取得して静的サイトとしてビルド作業が必要になるため、従来型のCMSのように投稿した内容をすぐに公開することができなかったり、構築するためにはフロントエンドの知識が必要になります。Jamstackでは静的サイトをビルドする手段として、SSG（Static Site Generator）と呼ばれる機能が搭載されたフレームワークが使われます。Next.js、Gatsby.jsなどいろんなものがありますが、今回はNuxt.jsを使って静的サイトを作成していきます。  

SSGとは？

SSGはStatic Site Generatorの略で、静的サイトをビルドするためのツール・機能のことを指します。SSGを使うことで、APIから取得したデータを動的なページとして展開するのではなく、データごとに個別の静的HTMLとしてウェブページが生成されるようになります。   SSGはを使うにはJavaScriptのフレームワークを使うのが一般的で、有名なものですとNext.js、Gatsby.js、Nuxt.jsなどがあります。今回はNuxt.jsを使いますが、Nuxt.jsではVue.jsをベースとしたフレームワークで比較的導入しやすく、また静的サイト生成のためにサイトマップの生成など便利な拡張機能や仕様がたくさん用意されています。実際に下記のコマンドを実行するだけで静的ページを一括してビルドすることができます。

$ nuxt genarete

 

WordPressをヘッドレスCMSとして使うテーマを作成

作業としては大きく2つのフェーズに分かれます。バックエンドとしてCMSを準備するのとフロントエンド側でサイト自体を作成していく感じですね。まずはWordPressでヘッドレスCMSを構築していきます。もし、すでに通常のWordPressテーマとして運用されている場合でもそのまま移行できるかと思います。   WordPressではテーマとして最低限「index.php」と「style.css」の2つのファイルが必要となります。今回はヘッドレスCMSとして機能させるためにAPIのエンドポイントなどの処理を作成していく必要がありますので、これらに加えて「functions.php」のファイルを用意します。下記のようにこれがミニマムな構成となります。

theme
  - index.php
  - style.css
  - functions.php

  今回はすでにWordPressの通常のテーマとして運用しているところからの移行ということで、ページテンプレートや各種コンポーネントも残しつつ、API関連の処理をそのまま追加する形で進めていきました。特に不要であれば削除しても良かったのですが、一応投稿内容をプレビューすることもできるのでメリットもあるのではないでしょうか。新規で作成する場合にはわざわざページテンプレートを作らなくても良いですね。   1. APIのエンドポイント作成 WordPressをヘッドレスCMSとして使う際に最も重要となるAPIのエンドポイントを作成する作業を進めていきます。functions.phpにそれぞれ処理を記述していきます。WordPressではデフォルトでAPIのエンドポイントが用意されていますが、取得できる記事の上限が10記事になっているなど、そのままでは使いにくいものとなっているのでカスタマイズしたものを用意してあげる必要があります。   独自エンドポイントの作成方法については、以下の過去記事に詳しくまとめていますのでご参考ください。 （参考記事） ・WP REST APIでクエリパラメーターを操作してWordPressの投稿データをリストで取得する ・WP REST APIで独自エンドポイントのカスタマイズで投稿記事を全件取得できるようにする ・WP REST APIで独自エンドポイントにパラメーターを使ってキーワード検索や個別記事を取得できるようにする   今回は下記のようなエンドポイントをカスタマイズで追加しました。ここに関しては機能要件によって変わってくるかと思います。

- 各投稿タイプ別全記事
- 各投稿タイプ別個別記事
- 各投稿タイプ別直近数件記事
- 各投稿タイプ別投稿件数
- 各タクソノミー別全ターム情報
- 全コメント情報取得
- キーワード検索結果

  今回はNuxt.jsのSSGで静的サイトを構築していく形になるのですが、ビルドする時にAPIで取得したデータは全てJavaScriptの中に静的データとして出力されてしまいます。そのため、エンドポイントを最適化してある程度データを細かくしておかないとデータ用のスクリプトファイルがとても大きなサイズになったり、ビルド時間が増える、API経由でデータ取得時にサーバー側でタイムアウトエラーになる、などの問題が発生するので、無駄なデータが不用意に取得されないように工夫する必要があります。（多分全記事取得もページごとに区分けするなど改善の余地はありそうですが、とりあえず今回はフロント側で処理することにしました、、）   エンドポイントのカスタマイズが完了したら実際にGETメソッドで実行してみますと、WordPressの投稿データがJSONの形式で返ってきていることが確認できますね。取得するデータはこの時点であらかじめフロントエンド側で扱いやすいようにキーと値を整理しておくといいですね。   2. その他管理画面カスタマイズや投稿データのクエリに関する処理 あとは、CMS側で必要となる機能や処理を適宜実装していきます。WordPressにおいては、カスタム投稿の追加、カスタム分類の追加、管理画面のカスタマイズ、ユーザー権限別の分岐処理、カスタムフィールド関連の対応、その他プラグインの設定などなど、、過去記事にもいろんなケースに使えるサンプルをあげていますのでご参考に。 （参考記事） ・WordPressで管理画面内をカスタマイズするtips ・キーワード検索でカスタマイズした検索機能を実装する ・WordPressのfunctions.phpに記述しておくと便利なコードまとめ   3. サイトURLのリダイレクト設定、検索エンジンのnoindex設定 ヘッドレスCMSの場合、WordPressをウェブサイトとして使う必要は無くなるので、プレビュー用として残しておく場合でなければサイトURLに対しては、フロント側の動的ページのURLにリダイレクトしておくといいですね。index.phpにPHPのヘッダー関数などでリダイレクト設定を行います。 【index.php】

<?php
  header('Location: https://example.com/blog/');

  また、検索エンジンのインデックスに登録されないようにnoindexの設定も合わせて行っておきます。   4. その他不要プラグインの削除および整理 ウェブサイトはWordPressと切り分けられた静的ページで運用されるため、従来のWordPressサイトで必要だったプラグインも変わってきます。基本的にはセキュリティ用のプラグイン、投稿データをバックアップするプラグイン、投稿関連や管理画面のカスタマイズ、エディター周りで必要なプラグイン程度になるのではないでしょうか。   メタ情報をカスタマイズするプラグイン、パーマリンク設定のプラグインなども特に使わないので削除対象になってきます。もちろん、ページテンプレート上で利用するプラグインも不要になります。   今回、WordPressテーマとしてのCMS運用からヘッドレスCMSの運用に移行するにあたり実施した作業としてはこんな感じでしたが、サイトの機能要件や状況によっては他にも必要となる作業はあるかもしれません。また、いろいろと試行錯誤しながら進めていたのでもしかしたらこれ以外にもやっておくべき施策も発生する可能性があるかもしれませんが、その際には改めて加筆していきたいと思います。  

---

  ウェブ制作においてはJamstackは近年注目されているアーキテクチャとしてよく話題になりますが、実際にメリットやデメリット、また必要な知識などもまだまだ情報として少ないのかもしれません、次回以降も引き続きヘッドレスCMSを使ったJamstackなサイト制作のフローをまとめていきたいと思います。