2020年11月22日日曜日

Kansai WordPress Meetup@大坂 #6 参加して・・・ #WPmeetupOsaka


プログラム

プログラムは、 #5だが、実際には #6だった模様。このイベントは大半がビデオオンでの参加が印象的だった。

以下、発表を筆者が聞いて、筆者なりに理解した内容をネットで調べた情報などを加味した上で記載しています。そのため、必ずしも発表者の意図した内容になっていない場合もあります。

質問は、Twitter に #WPmeetupOsakaのハッシュタグを使って行うというのがベースとなっていた。

WordPress で Headless フロントエンド



発表者：岡本 秀高氏

Headlessを利用するにあたってのデータ取得は、

  • WP API（WPコアが提供するREST API）を使う
  • WP GraphQL（プラグイン）
    • WordPress のデータを GraphQLで扱える
    • 過去に破壊的変更があったので注意
とりあえず WP APIを使って始めるのがよいが、カスタム投稿やフィールドが増えてくると GraphQLも検討の対象になるようだ。
いずれにせよ GETかPOSTでデータをいくつも引っ張ってくる必要がある。

Webサイトの表示方法は、SSR / SPA / SSGある

Client Side Rendering（SPA）・SSR・SSG を整理してみた（雑草魂エンジニアブログ）

  • SPA = Single Page Application（描画：ブラウザ上）
    • Ajax でデータを取得して表示というのが多い（Webアプリなど）
    • WordPress だと Reast で REST API利用するような形態
    • データ取得したときにサニタイズしておくのが無難（されているはずだが）
  • SSR = Server Side Rendering（描画：サーバー上）
    • すべて JavaScript でやるので、SEO / OGPで一手間必要
    • JavaScript の読み込みサイズが肥大化しやすい
  • SSG = Static Site Generator（描画：CI / ローカルなどサーバー上）
    • React での SSGとして、Next.js（自前実装必要）, Gatsby (GraphQL 利用) などがある。
    • サイトで表示するHTMLを事前に生成する（Movable TypeのGenerate のようなもの）# WordPressのHTML静的化プラグインのようなものか...
    • HTML化することにあるので、表示速度がはやく、WordPressやDBに障害がおきてもウェブサイトはダウンしない。
    • ビルド（HTML化）しないと公開できない（全ページをビルドし直す）。250ページぐらいだと2分ぐらい掛かった経験がある。
    • ページ数に比類してビルド時間がかかる
    • ビルドのデバッグが少し大変
関連情報

    SSR で Webサイトを作る


    FrontityでWebサイト（Note.js のサーバーを動かす必要がある）
    などもあるが、WordPress のテーマがやっていることを別のシステムでやっているだけなので、車輪の再発明ではないかという話はある。

    JavaScript でフロントエンドをなぜ作るのか


    開発環境・公開サーバーの用意が楽
    共有可能なコンポーネントが作ることができ、利用できる

    Reactstrap / Material Design / Foundation 等を使ってマークアップの共有化ができる

    筆者感想

    筆者はデジタルキューブのAMIMOTOマネージドサーバーを利用して WordPressをいくつか管理運用している。そのうちの一つが、裏側で WordPress を動作しつつ StaticPress用な静的HTMLへビルドして、表のサイトを表示するということをやってもらっている。これがまさに SSG のような手法であり、今後はそちらのほうがいいのかもしれない。WordPressのStaticPressのようなプラグインは開発が停止してしまうこともあり、何度か変えた覚えもあるため。

    以下、筆者が気になった質問を書き出してみた。

    質問１（筆者）

    https://twitter.com/kimipooh/status/1330390365359190017

    WordPressの静的HTML化プラグインのようなものでウェブサイトを作っているものもあるのですが（そのサイト自体はもう更新しないのでいいのですが）、今後同じような運用形態が必要な場合、SSGを使うのがよいのかどう判断したらいいでしょうか。規模でしょうか。 #WPmeetupOsaka

    回答

    これも SSGといえる。１つや２つのサイトを作るぐらいで Next.js などを利用した SSGを使うのはコストパフォーマンスが悪いと思うので、 WordPress テーマを静的HTML化するのがよいとは思う。ただし、WordPress プラグインは内部PHPで静的HTML化処理をしており、大規模サイトなどではパフォーマンスが悪い場合が出てくる。そのため、デジタルキューブが提供を始めた Shifter のように外部から静的HTML化するという手もある。

    質問２

    どこから始めたらいい？

    回答

    とりあえずやってみたいというなら、Frontity がよい。

    • Frontity -> Gatsby -> Next.js

    らしい。

    質問３

    既存の WordPress で運用方法（SSR / SPA / SSG）を変更するときの気をつけることは？

    回答

    ウィジェットがうまく行かない可能性がある。プラグインやテーマが吐き出す CSS は Headless は自動取得できず、それぞれ調べて追加しないといけないので、既存テーマままで、移行するのはナンセンス。テーマ部分は作り直したほうがいい。

    質問４

    Headless を作ったサイトの管理運用は普通の人（WordPress でのサイト担当者）はできる？

    回答

    Headless をある程度理解している人に管理運用を担ってもらったほうがいい。

    運用現場からお伝えします！ Headless CMS を使ったJamstack 構成の運用


    発表者：Hiromi Ito 氏

    Jamsrack は始めて聞いた言葉。
    をみると、JAM = JavaScript/APIs/Markup とのこと。
    • コンテンツ担当者にとっては、WordPress の画面なのでとっつきやすい
    • マルチ管理しなくてよい
      • １つ書いたら、複数サイトに同時更新できる
    • 本番前には Staging でチェック
      • マスターと Staging の２つのサイトが動いていて、Staging のほうでチェックしてから、マスターを更新するようにしている
    • エラー時はログで判断する必要あり
      • Headless CMS ==> Static Site Generator ==> CDN / Hosting という構成になると、どこの工程でどうなっているかはログをチェックし、それらのサーバーやシステムを管理するエンジニアとコンタクトする必要あり
    関連情報
    質問１

    エンジニアに相談する頻度は？（発表者に対する質問）

    回答

    立ち上げ時はかなりの頻度だが、安定してきたらあまりない。

    質問２

    Headlessを導入する意味は？個人が利用するブログ程度だと？
    一日一度程度の更新ぐらいで。

    回答

    更新をどうするかは、サービスごとにちがうが、基本的には更新は全データを更新することになる。少し時間がかかるぐらいと思えばいいぐらい。ただプレビューをどうすればよいかとかの問題はでてくる。そのため、個人ブログや数人が少しのコンテンツを更新するぐらいだと、WordPress 単体のほうがコストパフォーマンスは圧倒的に大きい。
    ただ小規模サイトでもセキュリティを気にする担当者を納得させたり、速度を気にする場合には Headless もありうる（Headlessをどの手法で使うかにもよるが）。

    WordCamp Japan 2021 (オンライン) 実行委員募集をしているとのこと！

    今回は日本全体としてやるとのこと！


    2020年11月22日 @kimipooh
    投稿者 時刻: 0 件のコメント:
    ラベル:

    2020年11月2日月曜日

    リバースプロキシ（nginx）環境下で、WordPressのメニューが更新できない（エラーになる）

     保存しようとすると、下記のエラーがでます。

    • 204 recv() failed (104: Connection reset by peer) while reading response header from upstream
    これは時間がかかり過ぎて接続が切れたというものです。

    様々な解決方法（後述）を試しましたが、うまくいかず最終的には次の方法で解決しました。なおリバースプロキシが原因と特定できたのは、クローンサイトを手持ちのローカル環境で再現すると、遅いながらも問題なくメニューが保存できたこと。まぁ遅いのは１つのサーバーの多数のウェブサイト（WordPress含む）を動作させていて、リソースが足りていないことが原因の１つではあったものと思う。特殊な事例なので記録に残しておく。

    リバースプロキシキャッシュのバッファー調整


    次の３つの数値を調整する。
    • proxy_buffer_size 64k;
    • proxy_buffers 4 128k;
    • proxy_busy_buffers_size 128k;

    今回は、赤文字の部分を
    • proxy_buffers 100 128k;
    とすることで問題解決できた。
    ようは、バッファーの受け皿としてバッファーサイズが足りていないのではなく、最大個数がたりていなかった（4→100とした）のだった。

    PHPの調整


    下記をいろいろしたが解決せず。結局リバースプロキシのバッファー設定の問題だった。

    2020年11月2日 @kimipooh

    投稿者 時刻: 0 件のコメント:
    ラベル: ,
    登録: 投稿 (Atom)