Shifter をさわってみた
WordPress の静的ホスティングサービス Shifter を検証で触ったのでメモしておきます。
今回採用には至らず、無料プランで試した範囲の内容です。
概要
WordPress の静的ホスティングサービスってなんだろと思ってましたがざっくり Shifter の特長として認識したのは
- 静的HTMLで書き出される（.php動的されない）
- CloudFront での配信
- 管理画面は常時稼働（アクセス）されず、編集が必要なときのみ稼働
の2点が大きいかなと
それを受けての大きいメリットは、
- 配信が高速
- WordPress のセキュリティホールつかれてもphp動いていないので安心
ということ
デメリットとしては、
- 有料（無料プランもありますが）
- 即時反映できない（数分生成が必要）
- 管理画面が2段階（Shifter管理画面 => WordPress管理画面）
ですかね。
あまり裏側のこと分かっていないので目立つ部分だけですが。
やりたかったこと・できなかったこと
既存で動いている・運用している WordPress サイトを Shifter を使って静的HTML配信。
これに関して、自身の調査前の認識と違う所がShifter触ってみるとありました。
大枠の流れや仕組みを図にまとめたのはこちら。
一番大枠の部分ですが、
既存のWordPress環境にShifter環境（機能）を追加する、ではなく
既存のWordPress環境を新規のShifter環境に移行する、必要があることです。
サーバーレス/マネージドホスティングと謳っているので、そういうことなのねという感じでした。
既存 => Shifter環境への移行
公式 で移行の際は All-in-One WP Migration を推奨しており、これでやってみるとコンテンツからテーマまで移行できました。
Shifter環境ではおすすめできないプラグイン
プラグインに関しても動作が出来ない可能性が高いものは 公式 にのっています。
Shifter環境では動かない機能
いくつかのブログにも載っている通り動的生成される要素や機能は再現が難しいです。
- 検索
- お問い合わせフォーム
など。
ただこれに関しては未検証ですがShifter側が公式で代替の方法を作っている
- getshifter/wp-serverless-search: A static search plugin for WordPress.
- getshifter/wp-serverless-forms: Replace PHP form actions with API and WebHook driven services such IFTT, Basin, FormKeep, Formspree, custom Endpoints and more.
あと今回はパーマリンク周りで全部 Custom Permalinks を使っていて、 /.html などにしていましたがそれが /.html/ になってしまうとか細かい所で調整や妥協が必要そうなところがでてきてしまいました。
Shifter側のサーバーは触れない
WordPressサーバーへFTPクライアントなど経由で接続できない（はず）なので、img/css/js などのアセット類はルートではなくテーマフォルダ内に置く必要があったりする。
テーマは手動で管理画面のテーマページからアップするか GitHubリポジトリとの連携 もできるみたい
.htaccess的な設定も直接触れなかったり、/wp-content/ 以下もアクセスができないので、例えばプラグイン一気に移行して、WPのバージョンやphpが既存と新環境（最新版）が合ってなかったりしてプラグイン有効化して止まると管理画面が真っ白状態になってしまったこともありました。（サポートに問い合わせれば解決かな）
その時はこれも未検証ですが ローカル環境つくって やるのが正解っぽい感じです。
まとめ・今後
上記で挙げた、移行に際しての懸念やもう少し要検証の要素があったこと、
Shifter管理画面 => WordPress管理画面 => 編集 => html生成 => デプロイ のフローを複数人で運用していくことが今は難しそうなどもあり、今回は見送りになりました。
ただ最初にあげたメリットをどこかで生かしてWordPressサイト作りたいと思うときも出てくると思うので、そのときにまた検証からはじめて使ってみたいと思っています。
参考：