yuheijotaki.com

Shifter Headless をさわってみる

f:id:jotaki:20191122165357p:plain

Shifter Headless とは

これまでのShifter = WPの静的書き出しは、「Shifter Static」と呼ばれ、今回新しくWP（REST API）をHeadlessCMSとして使うのを「Shifter Headless」と呼ぶようです。
前回のShifter（Static）の記事：https://jtk.hatenablog.com/entry/2019/11/24/124457

料金

データ転送

  • 1000GB => $900/月
  • 100GB => $72/月
  • 10GB => $48/月

アカウント初回登録後1週間は無料プランあり

手順

会社の技術調査も兼ねて無料枠で使ってみました

Shifterへログインして「Headless」を選択後、サイト名を入力。
2〜3分でWordPressこみこみのサーバーが立ち上がりました。 f:id:jotaki:20200610133317p:plain

WordPress管理画面は Shifter Dashboard に書いてある情報を入力。（ユーザー名は admin ）
最初は英語版ですが、いつものWordPress管理画面です。 f:id:jotaki:20200610133334p:plain

WordPressの管理画面URLから /wp-admin/ を取ったURLでは Headless用のテーマが適用されています。
もちろんnoindexがはいっています。 f:id:jotaki:20200610133326p:plain

プラグインも互換性があるものは最初から入っている。
けど、プラグインの新規追加はできない。 f:id:jotaki:20200610133342p:plain

RESTだけでなくGraphQL配信もできそう。 f:id:jotaki:20200610133348p:plain

ユーザーも作成可能。 f:id:jotaki:20200610133353p:plain

サイトURL+ /wp-json/ を付与するとAPIができてることを確認 f:id:jotaki:20200610133400p:plain

Shifter DashboardからWordPressサーバーをストップしても、WPやAPIのURLは変わりませんでした。 f:id:jotaki:20200610133404p:plain

フロントエンドのスターターはGitHubにおいてあります https://github.com/smartcatdev/WordPress-REST-API-Sample-App

感想

プラグインの新規追加ができない点

これはデフォルトで入っているプラグインでしかWPの拡張ができないので、WordPressのコンテンツ管理周りでできることとしては下記が中心になるかなと思います。

  • カスタム投稿タイプの作成（Custom Post Type UI）
  • カスタムフィールド作成（Advanced Custom Fields）
  • クラシックエディターの有効化（Classic Editor）
  • テーブル入力まわりの強化（TablePress）
  • 投稿順序の並び替え（Intuitive Custom Post Order）
  • ページリダイレクト管理（Redirection）
  • ユーザー権限のカスタマイズ（User Role Editor）
  • コンテンツ移行（All-in-One WP Migration）

主要な機能は最低限カバーされている感がありますが、2つ懸念があります。

1.プラグインに依存していたサイトの移行が難しそう

旧サイトからの移行の場合、そちらで使用していたプラグインの機能は再現難しそう（Staticでも同じでしたが）なので、その点機能やコードの改修が出てくるかなと思います。
例えばWP-PageNaviの機能をフロントでやろうとすると結構大変な予感がしています。
小規模であまりテーマもいじってないですよーなサイトならやりやすそうです。

2.細かいところに手が届かない場合も

2つめはふだんのWordPress案件でよく使っているプラグインも使えないので、WordPress開発もできるしって理由が第一でこれを使うと大変なことにはなりそう。
functions.phpを触ることもできないので、ちょっとコード書いて管理画面の使い勝手よくするみたいなことも難しい。まぁフロントエンド向けなのでそうなのですが。
Headless CMSなので配信側で使うものという捉え方が必要で、残りはフロントでコネたりフォームはSaaS使うとかそういう選定はWordPress外でまた必要になる。

ちなみに自分がいつもいれるプラグインでないのは、

  • Duplicate Post
  • All in One SEO Pack
  • Admin Menu Editor

あたりで、がっつり管理画面側の最適化だったので、わりとどうにかしやすい方だと思います。

セキュリティ面（WPのサーバー・APIアクセス）やサーバーの安定性が不透明

WAFをいれているってことなのですが、管理画面のIP制限ができなそうだったり、APIもURL叩けば表示されるので、そのあたり厳密な案件は難しいかもしれないです。
あとはmicroCMSとかも同じですがサーバどれだけ落ちる可能性があるのかとか、そのあたりも許容できる案件とか使い方になってくるかなと思いました。

まとめ

WordPress開発を多めにやってきた人間からすると、プラグインの使用限度がネックになってしまうなと思います。
ただWordPressサーバーの構築や管理もいらないし、そのあたりのやりたいことと手間暇との天秤かける感じになるかなと。

WordPressのCMSの管理画面って長い時間かけて5.xまで来ているので、そうそうに他のCMSで更新が完璧にしやすいのは出てこない気がしますし、そこもShifter Headless使う理由になりますね。
グーテンベルクに慣れている人はどれだけいるかわかりませんが、今まで触ったことがある母数も相当多いでしょうし

  • 機能要件固まっていて、WPでめちゃめちゃ難しいことしない
  • セキュリティ要件もそこまで厳しくない
  • 更新する人がWordPress管理画面に慣れている
  • 開発側もモダンにやりたい（NuxtやGatsby）

このような案件だと使うメリット多いと感じました。

参考リンク