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のようなプラグインは開発が停止してしまうこともあり、何度か変えた覚えもあるため。

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

    質問1(筆者)

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

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

    回答

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

    質問2

    どこから始めたらいい?

    回答

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

    • Frontity -> Gatsby -> Next.js

    らしい。

    質問3

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

    回答

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

    質問4

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

    回答

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

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


    発表者:Hiromi Ito

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

    エンジニアに相談する頻度は?(発表者に対する質問)

    回答

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

    質問2

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

    回答

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

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

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


    2020年11月22日 @kimipooh

    2020年11月2日月曜日

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

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

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

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

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


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

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

    PHPの調整


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

    2020年11月2日 @kimipooh

    2020年3月11日水曜日

    WordPress では /?author=数字 で WordPressのユーザー名(ログインID)が漏洩してしまう件の対応について

    何が問題か


    WordPress では、
    • WordPressサイトのURL/?author=数字
    にアクセスすることで、
    • WordPressサイトのURL/author/ユーザ名
    に自動転送される仕組みになっています。
    これを悪用すれば、
    • WordPress のユーザー名に割り当てられている「すべての」ユーザー名(ログインID)を知られてしまいます。
    このことは
    にあるように脆弱性診断システムなどで脆弱性ありと判断される場合があります。

    対策しているかどうかの確認方法


    コマンドラインツール curl を使えば(macOS には標準搭載)、たとえば、 http://example.com に WordPressのサイトがあるとすると
    • curl -v -D -  "http://example.com/?author=1"
    と Mac ならターミナルから入力することで、標準出力にヘッダー情報が出てきます。
    そこの location: をみると
    • location: http://example.com/author/ユーザー名/
    になってユーザー名が見えてしまっています。これが存在しない場合、ユーザー名でない場合には何らかの対策がされているということになります。

    実際にウェブサーバーログをみると、
    ?author=1
    ?author=2
    ?author=3
    ?author=4
    ...
    など大量にスキャン(ポーリング)されているサイトもありました。

    ユーザー名が漏洩したからといって即座に問題になるとは限らない


    先に説明しておきますが、ログインのユーザー名が漏洩したからといって、それだけで不正ログインされるわけではありません。一般的にはパスワードが必要だからです。しかしながら、他のサイトとパスワードを同一(パスワードの使いまわし)をされていれば、もし他のサイトからパスワードが漏洩してしまうとログインできてしまいます。ですので別途ログインについては、下記のようなセキュリティ対策を施しておくのがよいです。
    • IPアドレス制限
    • 認証にクラウドサービス(Google認証等)をつかう
    • 総当り攻撃(ブルートフォース攻撃)への対策(一度に大量アクセスを防止)
    などです。そうすれば、たとえユーザー名が漏洩したとしても問題はなくなります。

    とはいえ、WordPress にどのユーザーがログインできているのか知られることは嫌ですよね。ですので対策したほうがよいでしょう。
    ここでは

    1. ウェブシステム側で止める
    2. WordPress プラグインで止める(自作)

    に絞って備忘録として残しておきます。

    対策1. ウェブシステム側で止める


    各ウェブサイトの設定において、先頭から
    • /?author=***  = 404エラーとする
    • /author/*** = トップページへリダイレクトする
    これが可能なら、WordPress に到達する前に止めることができるのでウェブサイトへの負荷が減ります。
    /author/** のケースは、 /hogehoge/author/** を除外するかどうかが、ややこしくなります。たとえばカテゴリー名に使った場合とかです。とはいえ、author は予約語でもあるので、まぁそこは除外するでよいでしょう。

    Apache での設定方法


    WordPress側では、RewriteBase が設定されているはずなので
    • RewriteRule ^\?author=(.*)? / [NC,R=404,L]
    • RewriteRule ^author/(.*)? / [R=302,L]
    の2つを追加すればよいです。
    管理者画面側では、?hogehoge=**&author=**
    となるので、管理者画面では除外できるはずです(未検証)。
    うまくいかなければ、RewriteCond ルールなどを併用すればいいでしょう。筆者は NGINX しかほぼ触っていないので、詳細は

    NGINX での設定


    nginx は if 文など条件を入れ子構造にできないという問題があります。
    したがって細かな条件を書くのが超大変です。
    ここではドメインやサブドメイン直下(http://example.com やhttp://hogehoge.example.com/) のように http://example.com/hogehoge というサブディレクトリに保存されていないと仮定すると、汎用性がある設定としては、

    set $rp_flag  flag;   
    set $rp_flag2 flag; 

    if ($request_uri ~ "^/wp-admin/"){
            set $rp_flag false;
    }
    if ($request_uri ~ "^/author/"){
            set $rp_flag2 "${rp_flag2}_true";
    }
    if ($args ~ "author=(.*)"){
            set $rp_flag "${rp_flag}_true";
    }
    if ($rp_flag = flag_true){ 
            return 404;
    }
    if ($rp_flag2 = flag_true){
            return 302 /;
    }


    上記コードでは、

    1. /wp-admin/ (管理画面)は対象外(リダイレクトしない)
     *つまり公開している側のみリダイレクトする
    2. /author/ か GETパラメーターに author= があるかのいずれか
    上記をすべて満たす場合に、トップページへリダイレクトする

    ということになります。
    「1」が必要な理由は、管理画面の投稿や固定ページ等で各ユーザーごとに一覧を表示するのに、author パラメーターが使われているためです。それは必要だろうという判断です。

    このように、フラグを文字連結させた上で、それを文字判定させる手法になります。
    さらに、requiest_uri に ? があるとパラメータ扱いになって、$args に保存されるという仕様もあってなおややこしい。

    参考:

    対策2. WordPress プラグインで止める(自作)



    ウェブサーバーのほうで止めることができない場合(設定をいじれない)もあると思います。その場合には、テーマの functions.php に書くなどの方法もありますが、サイトが大量にあるとやってられません。
    公式プラグインだと WP-CLIコマンドなどで一括インストールが可能になるので、その設定をしていれば、
    • wp @all  plugin install  プラグイン名  --activate
    プラグインを作成してそれを公式プラグインに登録しちゃえばよいのです。
    幸い筆者は WordPress の公式プラグインをいくつかアップして、メンテナンスしているのでそのあたりのやり方は知ってます。

    ただ問題はどのような手法で止めるのかがかなり悩みました。

    など速度低下が著しい模様。wp_safe_redirect をつかうのも同様じゃないかなぁと思います。そこで結局は
    で提示された方法を採用しました。また /author/ の場合を追加して、その場合にはトップへリダイレクトすることにしました。author=数字 は明示的に攻撃しているといってもいいですが、 /author/ はもしかして誤って入力したかもしれず、表示されないよりはリダイレクトにしたほうがいいかなぁという想いです。つまりは、
    1. 管理画面以外(公開されている部分のみ)に適用
    2. QUERY_STRING に「author」項目がある = 404エラー
    3. REQUEST_URI に /author/ があること =  トップへリダイレクト
    4. redirect_canonical にも対応し、自動補正時にもチェックが走るようにする
    という感じです。

    2020年3月11日 @kimipooh

    2020年1月27日月曜日

    コマンドツールで MAMP を SSL 対応しよう! - macOS Catalina (10.15) 編 -

    基本的なところは
    の通りです。Safari、Chromeでは確認済み。Firefoxは警告(警告: 潜在的なセキュリティリスクあり)がでますが、これは前から。まぁ自前でオレオレ証明書を作って、自分で承認する確信犯(テスト環境のため)ですから、それを検知してくれるのはいいんですけど、アクセスはできることと、SafariとChromeでは警告はでないので、Firefoxの警告を消す努力はもういいやって感じです。

    さて、これまではうまくいっていたのにだめになった理由は次の通りでした。
    にあるように、2019年1月1日以降の証明書については、2つのルールが追加されており、これに対応する必要があったのでした。
    1. ExtendedKeyUsage (EKU) extension にて serverAuth に対応すること
    2. サーバー証明書の有効期限は、825日以下にすること
    です。これを探すまで超苦労したのでメモしておきます。なおそれ以外としては
    • 証明書は、RSA 2048bit 以上、TLS であること
    • SHA-2(SHA-256)を使うこと(SHA-1は駄目よ)
    • Subject Alternative name extension を設定すること
    は従来どおりになります。

    mamp-enable-ssl.csh (GitHUB)

    において、configファイルで
    1. ExtendedKeyUsage (EKU) extension にて serverAuth に対応すること
    2. サーバー証明書の有効期限は、825日以下にすること
    3. 証明書は、RSA 2048bit 以上、TLS であること
    4. SHA-2(SHA-256)を使うこと(SHA-1は駄目よ)
    5. Subject Alternative name extension を設定すること
    に対応しています。

    1. [user_cert] と [v3_req]において、下記を追加
       extendedKeyUsage = serverAuth
    2. [CA_default]において、有効期限を 700日の設定を追加
       default_days = 700
    3. [req] において、
       default_bits = 2048
    4. [CA_default]において、SHA-2 (256)の設定を追加
      default_md = 256
    5. [usr_cert] と [v3_req] において、subjectAltName = @alt_names を追加
      [alt_names] において
      DNS.1 = localhost
      を追加。
    DNS.1 = localhost というのは、実際にサイトでつかうDNS名
    [alt_names]
    DNS.1 = localhost
    DNS.2 = *.test

    など複数の指定が可能になる。
    逆にここでちゃんといれておかないと駄目ってことになります。

    上記対応を1つでもしていないと、もれなくChrome君が



    といってきます。すべて対応すれば表示されなくなり



    のように安全だといってくれますね!
    macOS 10.15 になって一番苦労したのはこれかもしれない...

    参考



    2020年1月27日 @kimipooh




    2020年1月11日土曜日

    #33 WP ZoomUP 新年座談会 & WordCamp Asia 情報交換会 に参加して #wordpress #WPZoomUP

    WordCamp Asia 2020 に参加することになって、それ関連で WP ZoomUp というオンラインの WordPresss 勉強会・情報交換会を知りました。ちょうど WordCamp Asia 2020 がテーマになっていたので初参加してみました!

    Photo by @WP ZoomUP (twitter)
    プログラム
    WP ZoomUPをささえる会
    WP ZoomUP公式報告

    WordCamp Asia 2020 はアジア初開催のフラッグシップ WordCamp!



    Photo by @WP ZoomUP (twitter)
    ということで、私も早い段階から参加申し込みをして楽しみにしています。ちょうど2019年9月にバンコク(タイ)にいく用事があったので、実際に会場となる ICON SIAMにいってきて、どうやっていくのかを
    でまとめたりしています。

    Photo by @WP ZoomUP (twitter)

    WordCamp Asia 2020 ではグッズ販売をしているらしいですが、これは Swag Store での事前注文だそう。現地で直接買えるのはわぷーグッズぐらいみたいですね。

    ブレイクアウトセッション


    Zoom の機能「ブレイクアウトルーム」を使って4-5名に分かれて自己紹介をしたり、今年の抱負を話し合ったりと少人数グループでディスカッションできたのはよかったです! Zoom は何度か使っていましたが、この機能を体験したのは初めてでした。これいいですね!

    タイ語講座


    何度かタイにいっていますが、基本的に英語+ジェスチャーでやってなんとかなっているので、一般的なやり取りはなんとかなると思います。でもやっぱりタイ語がわかっていると楽しいだろうなと思いますね。

    *カー(女性)、クラップ(男性)が最後につける(プはほぼ発音しない)

    こんにちは! = サワディー カー(クラップ)

    って感じですが、こちらはサーバーのホスト名に東南アジアのこんにちは(タイ語なら sawasdee)をいくつかつけていたこともあって馴染み深いものです。

    マイ = Not 
    パイ = Go

    ぐらいはわかってましたが、それ以外は知らないので楽しく聞いてました!
    私がメモしたのは次の通り、男性なので最後にクラップをつけていますが、女性ならこれを全部「カー」に置き換えてください。
    • ありがとう! / Thank you!
      • コープン(マー / very)クラップ
    • いくらですか? / How much?
      • カオライ クラップ
    • (タクシーにて) ICON SIAM まで行ってください。 / (In taxi) Please go to ICON SIAM.
      • パイ ICON SIAM クラップ
    •  (レストランなどにて) 辛くしないでください。/ (At restaurants) Please don’t make it hot/spicy.
      • マイ ペッ クラップ(マイ(Not)とマー(Very)は意味が真逆なので発音注意だそうだ)
    •  (レストランなどで) お勘定、お願いします / (At restaurants) Check, please.
      • チェック ビン(でいいんじゃない、他の言い方は難しくて)
    • トイレはどこですか? / Where is the rest room?
      • ホン(部屋) ナム(水) ユー(ある) ナイ(どこ) クラップ
    • 辛くないのはどれですか / Which not spicy?
      • アンナイ マイ ペッ クラップ(ペッ マイ クラップ?でOK)
      • ペッ マー(very):とても辛いのーになるので注意
    • 美味しい
      • アロイ
    • Yes / No
      • チャイ(sure)  / マイ チャイ(not sure)的な感じ (受け答えに使うのか)
      • クラップ / マイ クラップ(純粋な Yes / No)のようなものもあるけど、あまりそういうのは使わないようだ。
    • ちょっとまってください
      • ロウ(待て) ベッ ヌン クラップ
    とまぁそんな感じかなー。

    タイでやってはいけないボディランゲージ


    タイでは王室不敬罪というのがあり、これが一番やってはいけないこと。ようはタイ王室に関して批判的なことをいってはいけないってこと。王室不敬罪で禁錮28年 国連がタイ政府に法改正要請(BBC News Japan)にあるように罪が極めて重くなるんですよね。

    それはともかくこの会議では
    • 中指を立てる行為
    • 頭を触る行為
    は駄目なことで
    • ハグ
    はあまり良くない(初対面とかよく知らない人)
    • 握手
    あまりしない

    ってことのようです。

    助け合いのコミュニティ


    参加者でチャットのリンクをクリックをうまくできない人がいて、その人に対してみんながフレンドリーにどうしたら解決できるかというのをやっていたのが非常に印象的でした。オンラインチャットというその人の端末環境が見づらい環境にも関わらず、画面共有の機能を駆使したり、いろいろなところにうまくリンクできるように書き込んだりなど、工夫を凝らしていました。こういうのが WordPress コミュニティなんですよね!

    では WordCamp Asia 2020 に参加される皆様、あと1ヶ月ちょっとあとにお会いしましょう!

    2020年1月11日 @kimipooh

    2019年12月8日日曜日

    WordCamp Osaka 2019 セッションデイ(2日目)に参加して #wcosaka2019 #WordCamp

     (photo by @wordcamposaka)

    筆者は実行委員の広報チームで翻訳を担当してきて、当日はPR班として Twitterでのツイートを頑張っておりました。当日は大勢の人たちが来て、そしてスポンサーブース、セミナー、懇親会もとても盛況で活気が伝わってきてよかったです!


     (photo by @wordcamposaka)

    懇親会最後に実行委員有志から実行委員長のお二人にサプライズプレゼントをしました!「大感謝 名前」のラベルが入ったお酒と有志からの寄せ書きです。いずれのデザインも実行委員の手によって作られました!これには実行委員長も最初は驚き、そして写真にあるように満面の笑みを浮かべ、それからしばらくして号泣。まわりも釣られて何名かが号泣!という感じになりました!感動やこれまでの苦労、達成感が後から押し寄せたのでしょうか。こういうのいいですよね!

    さて「ブログを描くまでが WordCamp」と言われています。そう、WordCamp で体験したことをブログを通じてより広めて、より多くの人に知ってもらいたいという思いもあるんじゃないかなと思っています。すでに一日目はブログを公開していました。

    WordCamp Osaka 2019 コントリビューターデイ(1日目)に参加して #wcosaka2019 #WordCamp

    以下は、二日目になります。


     (photo by @wordcamposaka).

    メインセッションは、ライブ中継(https://www.youtube.com/watch?v=47qD2o3S3Aw)されてました!これらのセッションについては、WordPress tv(https://wordpress.tv/)に後日掲載されます。
    二日目であるセッションデイは、Twitter 班として張り付いていたため、ガッツリとセッションは見てませんでした。


      (photo by @wordcamposaka).

    いくつかみたセッションは盛況でしたね!

    今回会場の都合でわぷーカフェとして飲食物を提供している部屋のみ、イベント側が用意した飲食物のみ飲食可能ということでした。筆者も PRチームとしてこの部屋にスタンバって Tweet を頑張ってましたよ!


     (photo by @wordcamposaka)


    またレジン工作は子供の楽しんでましたね!



     (photo by @wordcamposaka)

    セッション:Google検索最新情報 2020





    毎年聞いていて、これは聞いておきたい!ということで遅めの昼食をささっと食べて参加しました。個人的にも雑談でき、いろいろ興味深い話が聞けてよかったですね。

    PHP バージョンをあげる手順(ハンズオン)



     (photo by @wordcamposaka)


    参加したわけではなく、この部屋に PR班として常駐していたため話を聞けた!という感じです。いくつかのレンタルサーバーの担当者が参加しているので、とても実践的だったなと思います。各レンタルサーバーの担当者が、そのレンタルサーバを使っている参加者にはりついて直接サポートするという豪華なハンズオンです!すごいですね!知り合いは、まさに PHP7 へのアップデートを相談されていたということで、とてもタイムリーで貴重な情報を得ることができたと感動していました!また来年も来る!っていってました。これこそまさにイベントをして良かったなと思う瞬間ですね!

    昼飯






    大阪工業大学梅田キャンパスの21階にある菜の花食堂で食べました!
    美味しかったのですね!ただ14時ぐらいに食べたことと、わぷーカフェでお菓子を食べすぎてちょっと胃もたれ気味です (T_T;

    懇親会




     (photo by @wordcamposaka)

    とにかくものすごい人数が参加して熱気や活気あふれる懇親会だったなと思います!

    また来年もいきたいですね!その前に、WordCamp Asia 2020 が来年2月にバンコク(タイ)であります。どうやら日本から70名ほど参加されるようで、全体として1000人を超える規模になるとか!ものすごい規模になりそうです!筆者も参加予定でワクワクしますね!筆者は10月にバンコクにいく用事があったので、会場となる ICONSIAM に行ってきました!そのことは、WordCamp Asia 2020 の会場に行ってみよう!で紹介しています!英語ができないけどとりあえず申し込んだっていう人もいますし、とにかくいろいろな経験や体験をしたいのなら参加してみてはどうかなと思います!

    2019年12月8日 @kimipooh

    2019年12月7日土曜日

    WordCamp Osaka 2019 コントリビューターデイ(1日目)に参加して #wcosaka2019 #WordCamp

    通勤ラッシュに巻き込まれつつ、8時半ごろに会場入り。
    クリスマスの時期ですよねぇ。

    2日 目のセッションデイについてのブログはこちら






    実行委員(スタッフ)のユニフォームは、パーカーでした!



    朝から多くの実行委員が集まってきました。実行委員長も健在です!
    会場のWi-fi ありますが、ちょっと遅い感じはしますね。

    さて今日はコントリビューターデイ。日本の WordCamp で初めてコントリビューターデイをしたのが、WordCamp Osaka の前身になる WordCamp Kansai の 2014年にあたり WordCamp Kansao 2014でした(「日本のWordCampで初めての試み!コントリビューターデイってなんだ?」参照)。このコントリビューターデイとは、WordPress の何かに貢献しようっていう催しです。WordPress について歓談やディスカッション、相談するだけでも、誰かの刺激になったり、何らかのヒントで新しいものが生み出される可能性もあります。

    挨拶&チーム分け



    今回始めてコントリビューターデイにきたって人がかなりいたことに驚きました!いいですね!いくつかのチームに分かれて作業するということで、チームメンターの紹介とそれぞれのチームでどのようなことをするのかの紹介がありました。

    • 全体のメンター:Mike Schroder 氏(WordPress 5.3 のリードをされていた、Core やメディアコンポーネンツについてになるけど、でも何でも聞いてもいいよって感じ)
    • Core チームメンター:Kite 氏(WordPress 本体のメンテナンス、Gutenberg 含む)
    • WP-CLI チームメンター:Sumida Ippei 氏(WP-CLI コマンドのメンテナンス)
    • Help Hub チームメンター:Tachibana 氏(WordPress のマニュアル移行・翻訳)
       参考:日本語版CodexからHelpHubへの移行ボランティアを募集中
    • Polyglots チームメンター:高野氏(翻訳)
    • WordPress.tv チームメンター:Hayashi 氏(WordCamp セッションの動画編集やアップロード、字幕をつける)
    • Theme Review メンター:Shiva Shanker Bhatta 氏, Ganga Kafle 氏(テーマレビューのリードをしている、インドのネパールから来訪。すでに公式リポジトリへ申請しているテーマの審査をやってみる)
    • Community チームメンター:額賀氏、GOUTEN 氏(WordPress Meetup の申し込みやオリエンテーション、 ダイバーシティースピーカートレーニングの翻訳、WordPressの記事)
    • JP WordPress Hosts Community チームメンター:Taniguchi 氏(WordPress のホスティング。PHP5.3使っているけれど、どのサーバーがいいだろうとか)

    筆者は、筆者開発のプラグイン改良でもしようかなーと漠然的な感じでしたが、プラグインチームがなかったので、よくお世話になっている WP-CLI について貢献できるようになっておこうかなと思い立ちました。

    WP-CLI チーム


    公式マニュアル:https://make.wordpress.org/cli/handbook/contributing/

    記事:https://make.wordpress.org/cli/2018/07/14/contributing-to-wp-cli/

    GitHub: https://github.com/wp-cli/


    事前準備


    1. WordPress.org のアカウントを作る
    2. WordSlack のアカウントを作る
    3. WordSlack にログインして、#cli チャネルを追加する
    4. GitHub アカウントを作る
    5. https://github.com/wp-cli/ の good-first-issue ラベル を探してみる
       これは初めてやる人用で、初めてでなければ rejectされる
    6. composer のインストール
    7. hub のインストール(brew install hub)*こちらは必要ならという感じ
    8. 何をするか決まったら WordSlack の #cli でつぶやいて、リポジトリを Fork する
    9. Forkしたものをローカルにクローンする
    10. クローンしたディレクトリで、composer install --prefer-source を実行する
       参考:https://make.wordpress.org/cli/handbook/pull-requests/#setting-up


      1. Script ./utils/git-setup-pre-commit-hook handling the post-install-cmd event returned with error code 1 とでてインストールが失敗する
      2. 一度クローンしたディレクトリを消して入れ直しても同じエラー
      3. ここの情報「.git/hooks/pre-commit を作れ」と、ここの情報「git clone https://github.com/mautic/mautic.git にある ./build/hook/pre-commit を使え」を参考に、https://github.com/mautic/mautic.git の ./build/hook を .git/hooks にコピーした。 
      4. すると警告はでるもののインストールできた。

        うーん、何故だかスッキリしない!昼食を食べた後にもう少し検証
      5. 検証結果
         git clone URL : OK
         Sourcetree (3.0 (200) でも4.0 (232)でも)最新ので Clone すると、上記エラーがでてしまうことが判明。Soucetree 内蔵の git が少し古い(2.20.1)のが原因なのかなぁ。システムのほうは 2.21.0 だし。
    11. クローンしたディレクトリの bin/wp を wp コマンドとして実行できるようにする
       cd クローンしたディレクトリ
       alias wp="`pwd`/bin/wp"
    12. branch を切る


    ちなみに参加者はエンジニアばかりだった(バックエンドエンジニアが多い)。まぁそうですよね。

    https://github.com/wp-cli/wp-cli/issues/4874 にチャレンジ


    STEP 1. コーディング

    Remove `WP_CLI\Utils\is_bundled_command( $command )` again #4874
    ということなので、is_bundled_command を探すと、

    php/utils.php
        function is_bundled_command( $command ) {

    tests/test-bundled-commands.php 
    $result = Utils\is_bundled_command( $command );

    の2つがヒットしました。

    1. tests/test-bundled-commands.php  は削除
    2. php/utils.php
         function is_bundled_command( $command ) {
    はコメントも含む関数ごと削除

    STEP 2. コードテスト


    1. Code style sniffers

    composer phpcs

    で問題なければ次へ

    2. Function tests

    mysqlデータベースが必要。もし準備が出来ていなければ
    env: mysql: No such file or directory
    Script run-behat-tests handling the behat event returned with error code 127
    Script @behat was called via test
    のようなエラーがでる。

    筆者の macOS はちょっと前にクリーンインストールしてしまったので、mysqlは入っていない。Homebrew はインストールしていたので、「Macでmysqlを扱う方法
    を参考に、

    brew install mysql
    にてインストール
    brew services start mysql 
    にて MySQL データベースを起動
    mysql -uroot
    で mysql データベースにログインできることを確認
    なおこのデータベースはパスワードなしで特権ログイン(root)できる。まぁ一時的なインストールだからいいでしょう。
    mysql> create user 'wp_cli_test'@localhost identified by 'password1';
    にて、wp_cli_test ユーザーを作成(パスワードは password1)
    mysql> create database wp_cli_test;
    にて、wp_cli_test データベースを作成
    mysql> GRANT ALL PRIVILEGES ON wp_cli_test.* TO "wp_cli_test"@"localhost" IDENTIFIED BY "password1";
    wp_cli_testユーザーに wp_cli_test データベースに権限を付与するコマンドでエラー
    ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by "password1"' at line 1
    によれば、mySQL 8 からコマンド構文がかわったとのこと。
    mysql> GRANT ALL PRIVILEGES ON wp_cli_test.* TO "wp_cli_test"@"localhost";

    かな。

    composer behat

    かなり時間がかかります。

        Error: Error establishing a database connection. This either means that the username and password information in your `wp-config.php` file is incorrect or we can’t contact the database server at `127.0.0.1`. This could mean your host’s database server is down.

    とエラー。
    をよく見ると、mySQL 8の場合の注意事項がありました。

    mysql> ALTER USER 'wp_cli_test'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password1';

    を追加したらいいのか。

    composer behat

    ...
    .F-------............................................................. 1260
    ...

    (::) 失敗したステップ (::)

    01. $ wp db query 'UPDATE wp_blogs SET domain = NULL'
        
        ERROR 1048 (23000) at line 1: Column 'domain' cannot be null
        cwd: /var/folders/t7/3x5g378s45s246158trdylvm0000gn/T/wp-cli-test-run-framework.feature.313-5de9f542b305c0.53752291/
        run time: 0.43459987640381
        exit status: 1
        In step `And I run `wp db query 'UPDATE wp_blogs SET domain = NULL'`'.         # vendor/wp-cli/wp-cli-tests/features/steps/when.php:29
        From scenario `Display a more helpful error message when site can't be found'. # features/framework.feature:313
        Of feature `Load WP-CLI'.                                                      # features/framework.feature

    197 個のシナリオ (196 個成功, 1 個失敗)
    2139 個のステップ (2131 個成功, 7 個スキップ, 1 個失敗)
    15m33.818s

    うーん、もうちょいか。しかしテストに15分かかるのね・・・。

    > run-behat-tests
    /***/wp-cli/vendor/bin/run-behat-tests: line 12: jq: command not found
    (23) Failed writing body

    と最初に jq コマンドがないというのが気になりますね。
    によれば、 brew install jq でインストールしてみた。

    composer behat

    jq エラーはなくなったものの、同じところでエラー出ますねー。

    *エラー出たところだけ再テストは
    composer behat-rerun
    で出来る。

    しかしこれは、mySQL 8 ではまだうまくいかないのですかねぇ。
    https://qiita.com/sato11/items/ba887a5655217f60f2a2
    を参考に、mySQL8 を消して 5.7をいれてみる。

    brew services stop mysql
    brew remove mysql
    brew cleanup

    https://qiita.com/sato11/items/ba887a5655217f60f2a2 をみて削除
    /usr/local/etc/my.cnf も削除

    brew install mysql@5.7
    brew services start mysql@5.7
    /usr/local/opt/mysql@5.7/bin/mysql -uroot
    ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

    sudo touch /tmp/mysql.sock
    brew services restart mysql@5.7

    でも駄目だなぁ。まぁこれはやめて mysql 8 の環境に差し戻し。

    あらためて

    composer behat

    ここで時間切れ(16時30分)。


    3. Units test

    composer phpunit

    こちらは 2 の functions test の前にやってみたが問題なく通過した。

    上記すべてのテストを一括でやる場合には

    composer test

    とのこと。

    pull request までいけなかったのは残念ですが、テスト環境の構築やそのためのエラー解決方法については体験できてよかったと思います。

    筆者は過去のコントリビューターデイで何をしていた?


    間近の 2年(2017年以降)だと、プラグイン開発、プラグインのマニュアル作成、翻訳をおもにやってました。






    昼食





    かっぱ横丁にある古潭老麺(古潭ラーメン)で食べました。


    閉会

    以下筆者が聞いて覚えている内容。そのため発表が正確に反映されていないことに注意。

    Core チーム発表

    Core については subversion を使わずにできるようになっているということ
    git で出来るとのこと

    WP-CLI チーム

    good first issue から貢献できそうなものを探してやってみという形態だった
    pull requests が 1件できて、作業中が2件あった。

    Help Hub チーム

    古い Wikiページ から新しいシステム(Help Hub)へ移行するというものだった。
    皆で文体などのルールを読んでもらった上でやってもらった。
    26文章が更新されていた。


    Polyglots チーム

    かなり進んだ。

    WordPress.tv チーム

    WordPressを知っていますか?(15分動画)に日本語字幕をつけた。
    1人1分担当し完成して公開したよ!
    その他にもやった。

    Theme Review チーム

    レビューは言語とコーディングの壁があって大変だった。
    けれども、全くレビューをしたことがなかった方を 3名迎えることができたことが非常に大きいとのこと。

    Community チーム

    いろいろ出来た模様

    JP WordPress Hosts Community チーム

    本当に PHPバージョンアップすると生きて帰れない(トラブって大変なことに)人もいるので、PHP のバージョンアップのライフサイクルなどのノウハウの共有を行った。そしてどのようにユーザーが利用しているサーバー上で WordPress を快適に使えるかについてディスカッションし、その結果をまたフィードバックしたいということ。

    実行委員長より

    明日のセッションデイの紹介

    懇親会(スピーカー&実行委員)





    WordCamp ではおなじみのスピーカーとの懇親会。いろいろ歓談できて楽しかったです!

    日時が変わって本日はセッションデイ!
    いろいろおもしろい話がきけることを楽しみにしています!

    2019年12月7日 @kimipooh