2020年12月11日金曜日

Travis-CI と GitHUB連携で WordPress プラグインの PHPUnit によるテストを実行する（PHP 7.4対応）

 もうすぐ PHP 8.0対応のWordPress 5.6がリリースされる（2020年12月8日予定）ということで手持ちの公式プラグインを Travis-CIにてチェックし始めました（WP CLI 2.4.0 の wp scaffold plugin-tests プラグイン名 で吐き出すてｓ）。ところが、いつの間にか PHP 7.3以上については Travis-CIが PHPUnit 8.x（PHP8.0.0-devは PHPUnit 9.x）を使うため、PHPUnit 7.x までしか対応していない ため、現行のWordPressでは下図のようにエラーがでて動かなくなっていました。１年前ぐらいは問題なかったのですけどね。WordPress 5.6からは PHPUnit 8.x をサポートするそうです。この記事は WordPress 5.6がでる前（WordPress 5.6 RC2〜RC3）のときに検証した結果です。 WordPress 5.6も検証していますが、PHPUnit 8.x は未検証です。

付録（後述）で、MAMPを使った PHPUnitテストも説明しています。
また GitHubとTravis-CI 連携はできているものとします。そのやり方は検索したらいろいろと情報がでてくるでしょう。



PHP 8.0.0-devはうまくいかず

また数日調べたり、試してみましたが PHP 8.0.0-dev については、うまくいきませんでした。というわけで、こちらは素直に WordPress 5.6が出てから考えることにしました。


PHP 7.3/7.4 利用時に Travis CI に PHPUnit 7 を強制させる

PHPUnit 8.x対応の WordPress 5.6がでたら不要になるかもしれませんが、2020年12月1日現在は、WordPressが PHPUnit 7.x 以下しか対応しないため、やむを得ません。

変更するのは「.travis.xml」です。また composer.json がないと 「Composer could not find a composer.json file in XXX 」のようにエラーがでる場合があります。

したがって追加や変更点は

  • .travis.xml の変更
  • composer.json
  • phpunit.xml.dist の test-sample.php の除外設定をコメントアウトする
    （<!-<exclude>./tests/test-sample.php</exclude> -->）
の三点です。

詳細は
のコードを参考にしてみてください。

なお WP-CLIが吐き出す PHPUnit （wp scaffold plugin-tests）に含まれる .travis.xml は、２点古い書き方があります。

  1. matrix キーは、jobs キーへ変更（matrixはjobsへのエイリアス）したので、今後は jobs キーを使うこと
  2. sudo: は廃止キーだから削除推奨

また、PHP 7.3, 7.4 については、Travis CIで失敗しても許容するように、allow_failures キーを設定しておきます。ここで指定しておけば失敗しても Travis CIのジョブとしては失敗とはみなされないということになります。

まず jobに PHP 5.6〜 7.4を追加します。 PHP 7.4については WordPress 5.6（リリース候補）も含めておきます。

うまくすべてが成功していれば、下図のように allow_failures に含めた PHP 7.3と 7.4でもテストが成功していることがわかります。なお、ここでの WordPress nightlyバージョンとは、WordPress 5.6 RC2あるいは RC3を指します。

付録：MAMPを使った PHPUnitテスト方法

2020年12月9日時点（日本時間）においては、 WordPress 5.6の日本語版もリリースされました。ただ PHPUnit 8.5.13 を実行しようとすると

Error: Looks like you're using PHPUnit 8.5.13. WordPress requires at least PHPUnit 5.4 and is currently only compatible with PHPUnit up to 7.x.
Please use the latest PHPUnit version from the 7.x branch.
とでます。
をみる PHPUnit 9以降は PHP8以降のみサポート。PHPUnit8 は PHP7.1以降のサポートだとか。とりあえず、ここでは PHPUnit 7でのやり方を説明します。

検証環境

  • macOS Big Sur (11.0.1）
  • MAMP 5.7 （最新の6.2 は Apacheの80 ポート利用でコケるのでまだ使っていない）
    • PHP 7.4.2
  • zsh（シェル）
  • プラグインテストの準備
  • svn をインストールしておきます（Big Surには標準搭載されていない）
    • Xcodeには含まれなくなったため、Homebrew をインストールして、 brew install svn からインストールできます。

STEP 1.  MAMPの phpや mysql等コマンドを優先する PATHを通す

ターミナルが起動しているときのみの一時的な有効化になりますが、
ターミナルを起動して次の2つのコマンドを、順番に実行してください。
＊bash/zsh 両シェル対応

export php_path="`ls -d /Applications/MAMP/bin/php/php* | tail -1`"
export PATH="${php_path}/bin:/Applications/MAMP/Library/bin:$PATH"

これによって、MAMP内の最新 PHPを php コマンドに一時的に割り当てます。
which php
でパスが /Applications/MAMP/bin/php/php7.4.2/bin/php （今回の場合）になっていることを確認しておくことが重要です。

STEP 2. wp scaffold plugin-tests が吐き出す bin/install-wp-tests.sh の変更

  • https://github.com/kimipooh/view-shortcodes/blob/master/bin/install-wp-tests.sh
のうち、下記の赤文字の部分を削除してください。
MySQL 5.6以降、コマンドラインから DBへのアクセスにパスワードを指定することは、セキュリティ上好ましくないので警告を出してできないようになっているようです。
  • mysqladmin: [Warning] Using a password on the command line interface can be insecure.
回避するためには、「パスワードを入れてmysqlコマンドを実行すると「Warning: Using a password on the command line interface can be insecure」が表示される」などの記事にあるようにファイルにパスワードを記載してそれをコマンドに読み込ませるという方法もありますが、ここでは素直にパスワードをキーボードから入力することにします。

変更前（bin/install-wp-tests.sh）
  • mysqladmin create $DB_NAME --user="$DB_USER" --password="$DB_PASS"$EXTRA

変更後（bin/install-wp-tests.sh）
  • mysqladmin create $DB_NAME --user="$DB_USER" --password $EXTRA

こうすることで MAMPの初期設定（MySQLポート 8889、ユーザー、パスワードともに root）であれば、

STEP 3. テスト用 WordPress のインストール

bash bin/install-wp-tests.sh view-shortcodes root 'root' 127.0.0.1:8889 latest

というコマンドを叩くことで、WordPress最新版（latest）が、 

/var/folders/_6/ユニークキー/T/wordpress/

あたりにインストールされるでしょう。

STEP 4. PHPUnit7 のダウンロードと実行

  • https://phar.phpunit.de/phpunit-7.phar
より PHPUnit 7の最新版をダウンロードします。
phpunit7 とリネームして
chmod 755 phpunit7 と実行権限を付与しておきましょう。
これをパスが通っている場所に移動しておきます。
MAMP限定なら、/Applications/MAMP/Library/bin にいれておけばよいです。
STEP 1 で上記へのパスは一時的に有効になっているはずです。

あとは、 テスト環境野整った プラグインフォルダで

phpunit7

と実行すれば

Installing...
...
...
OK (1 test, 1 assertion)

のようにテストされるはずです。

2020年12月11日 @kimipooh

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

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 件のコメント:
    ラベル: ,

    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 プラグインで止める（自作）

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

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


    各ウェブサイトの設定において、先頭から
    • /?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= があるかのいずれか
    上記をすべて満たす場合に、トップページへリダイレクトする

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

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

    参考：

    対策２. 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

    投稿者 時刻: 0 件のコメント:
    ラベル: ,

    2020年1月27日月曜日

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

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

    さて、これまではうまくいっていたのにだめになった理由は次の通りでした。
    にあるように、2019年1月1日以降の証明書については、２つのルールが追加されており、これに対応する必要があったのでした。
    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

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

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



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



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

    参考



    2020年1月27日 @kimipooh




    投稿者 時刻: 0 件のコメント:
    ラベル: ,

    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 に参加される皆様、あと１ヶ月ちょっとあとにお会いしましょう！

    2020年1月11日 @kimipooh

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