2021年5月13日木曜日

【Google Workspace 専用】 WordCamp Japan 2021のお知らせを Google Chat で通知してみよう！(GAS利用) #wcjpn21

　6月20日から 1週間オンラインで開催される WordPress イベント

　https://japan.wordcamp.org/2021/ より登録可能（無料）

というイベントがもうすぐあるので、ウェブサイトでの告知なども加速していきます。今回はオンラインかつ無料のため、期間は1週間ありますが１週間のうち出張可能な期間はどこかなど悩むことなく気軽に参加できます。皆さんも WordPress にご興味があれば、是非登録してみてください！

さて、筆者も実行委員としていろいろやっているので、最新情報チェックを仕事のコミュニケーションとして使っている Google Chat で通知を受けられるのが便利だよなぁと思いました。まぁ Slack なども使ってますので、IFTTT 経由で Slackチャネルに自動通知はできるんですけど、Slackは登録数が結構多いこともあり、常時起動するとなにかに集中しているときに横槍が入りやすいので見たいときにたちあげているんですよね。また Google App Script でそうしたことができるスキルを会得したいというのも目的としてあります。

WordCamp のサイトは WordPress で構築されていますから、RSS情報があります。あとはそれをよく使っている Google Apps Script で手軽にささっと Google Chat へ投稿できたらハッピーです。思い立ったら即実行です！

注意点

この手法は、Google Workspace 専用の Google Chat の WebHook 機能を利用しています。だからこそ手軽にできるわけですが、そうではない場合には Google Chat API 経由での利用になるでしょう。そちらについては、GoogleChat のREST APIを叩いてみるよスペース情報をとってくる編(Qiita)などを参考にしてみてはと思います。将来的には無料版 Google アカウhンとでも WebHook機能が使えるといいですね！

手順

ATOM形式のRSSのURLを取得
RSS情報のうち最新データの日時を目視で確認する
投稿先の Google Chat にて Webhook を設定する
取得したRSS情報のうち、最新データを指定した Google Chat へ投稿（Bot）する、Google Apps Scriptコードを新規作成する
成功したら、投稿した「スレッド」情報を取得し、次回から同一スレッドへ投稿するよう改変
毎日自動実行するようにトリガーを設定する

手順を理解することが目的のため（自身の備忘録にもなる）、コードについては必要最小限にしています。運用しだせば、「1日以内のRSS情報を取得してデータがあれば Google Chat へ投稿」というのが一般的だと思います。しかしながら、まずはテストする必要があり、日々更新されていないサイトの場合には、1日以内のデータがない可能性があります。したがって、目視で最新データの日付を確認し、その日付を含むように◯日以内という設定をする必要があることに注意。

これがうまくいけば、Google Alert （特定キーワード検索結果をRSSを利用した RSS情報も投稿も可能になるので、いろいろできそうだなと感じています。

参考情報

GASでrssやatom(Google News)を読み込む (Qiita)
【GAS】RSSの更新を毎日確認してメールを送る (知識のアウトプットをするブログ）
Google Apps ScriptでのDateオブジェクトの各生成方法、日付と時刻を分ける (いつも隣にITのお仕事）
GASでgoogleトレンドのRSSを取得しスプレッドシートに保存（Qiita)
GoogleアラートをGoogle Hangouts Chatに連携する（Denen blog）
GASからhangout chatにPostする（Qiita)
Google Chatにスレッドを指定してポストする (Qiita)
Webhookとは？ (Qiita)

STEP 1. ATOM形式のRSSのURLを取得

WordPress の RSS情報は、ATOMを始めいくつかのフィードが用意されています。
今回利用するのは、ATOM形式のため、WordPressサイト/feed/atom/ がURLになります。WordCamp Japan 2021 のサイトの場合には、

https://japan.wordcamp.org/2021/feed/atom

になります。

STEP 2. RSS情報のうち最新データの日時を目視で確認する

Google Chrome など ATOM形式のRSS情報のソースを表示できるツールを使って、

https://japan.wordcamp.org/2021/feed/atom

にアクセスします。

＊以下、ソースの説明をしますが、タグの属性は説明に必要な部分以外削除しています。また、説明をする上で分かりづらいタグも消してます。

各記事は

<entry>記事ソースデータ</entry>

の形式になっており

<entry>

<updated>最終更新日時</updated>

<category>カテゴリー</category>

</entry>

などのように並んでいます。

今回コード内で登場するのは、

<title>タグの「タイトル」情報
<link>タグの属性「href」のリンク情報
<category>タグのカテゴリー情報
<updated>タグの更新日時情報

の４つです。Google Chat はテキストにリンクを付与できませんので、実際に投稿するデータは

投稿日時: タイトル / リンク

としています。カテゴリー情報もコードでは取得していますが、今回は使ってません。

2021年5月13日現在、WordCamp Japan 2021 の最新データのうち、利用する部分のデータは下記の通りです。

<entry>

</entry>

つまり「3日前のデータ」だということを覚えておきましょう。

STEP 3. 投稿先の Google Chat にて Webhook を設定する

チャットのタイトル部分の▼をクリックし、「Webhookを管理」を選択。

下記のようにタイトルをつけましょう。このタイトルが Google Chat に投稿されるスレッドの「タイトル」になります。

設定が終わったら、下記のように投稿用URLができます。こちらをコピーして、テキストエディタなどにペーストして一時的にメモ（保存）しておいてください。

STEP 4. 取得したRSS情報のうち、最新データを指定した Google Chat へ投稿（Bot）する、Google Apps Scriptコードを新規作成する

Google Apps Script は、

https://script.google.com/home/projects/create

から作成してください。

そして、下記にアクセスして表示されるコードをコピー＆ペーストします。

https://raw.githubusercontent.com/kimipooh/get_wcjpn21_announcement/main/get_wcjpn21_announcement.gs

そして次について変更します。

変更１：投稿先、情報源（RSS）を設定

// Google Chat の WebHookを指定（指定した名前のスレッドで投稿される）

var chat_webhook_url = '保存していた WebHook URLを入れる';

赤文字の部分を変更してください。

もし WordCamp Japan 2021 の RSS以外の RSSを取得したい場合には下記を変更してください。

var rss_url = 'https://japan.wordcamp.org/2021/feed/atom';

変更２：取得するデータの日時指定

var LIMIT_TIME = 24*60*60 * 3;//１日を秒に変換（一番最新のRSSが何日前かで 3の数字を変える）

STEP 2 で確認した最新記事が、「今現在」から何日前なのかを指定します。

本記事を書いている 2020年5月13日では、3日前なので 3と入力しています。

以上が変更点です。

Google Apps Script を保存する

Google Apps Script の名前（プロジェクト名）を変更するために「無題のプロジェクト」をクリックします。

ここでは下記のような名前にしています。何をする目的であるのかわかる名前にしておくと便利でしょう。

そして、いまはもう知らない人も多いかもしれないフロッピーアイコン（▷ 実行の左側）をクリックして保存します。

保存できたら、「▷ 実行」がクリックできるになるので、このボタンを押して onMessage 関数を実行します。

初めて実行する場合、下記のように作成した Google Apps Script のプロジェクトをGoogleアカウントに対して許可する処理が必要です。無料版 Googleアカウントの場合には、信頼できないプロジェクトなどのメッセージがでますが、Google Workspace に関してはそうした物がでず、下記のような３つの処理のみになります。

うまくいけば、下図のように実行ログに実行開始、投稿された記事内容、実行終了が表示されます。

この時点で Google Chat には、下記の新規スレッドが投稿されているはずです。

わぷーは、WordPress.org の日本公式キャラクターです。海外の WordCamp も含めて、いろいろなところのマスコットキャラクターとして登場してますね。WordCamp Japan 2021では、四季折々のイメージになっており、塗り絵バージョンも含めて公開されています。

STEP 4. 成功したら、投稿した「スレッド」情報を取得し、次回から同一スレッドへ投稿するよう改変

再度、実行ログを確認してみましょう。

そこにある、

"thread" : の "name" : の値「spaces/◯◯◯/threads/△△△」部分をコピーします。

Google Apps Script のコード内にある

// "name": "一度実行し、ログを参考に threadのnameを入れる。ここをコメントアウトすると新規スレッドになる"

の赤文字部分を、spaces/◯◯◯/threads/△△△ に置き換えます。

そして先頭の // を削除します。

"name": "spaces/◯◯◯/threads/△△△"

できたら、プロジェクトを保存します。

そして再度「▷ 実行」をクリックして実行してみてください。

うまくいけば、先程のスレッドに追加される形で、同じ記事が追加されているはずです。

STEP 5. 毎日自動実行するようにトリガーを設定する

さて、STEP 4. までで RSS情報を投稿するスレッドが手動でうまく投稿できたのであれば、あとはそれを自動実行するようタイマーをしかけることにあります。

まず最初にコードの

var LIMIT_TIME = 24*60*60 * 3;//１日を秒に変換（一番最新のRSSが何日前かで 3の数字を変える）

の部分を

var LIMIT_TIME = 24*60*60;//１日を秒に変換

として１日以内に更新された記事のみを対象にするなど、更新範囲のルールを決めてください。ここでは毎日早朝の実行されるようにするので、1日以内とします。

もし3日のままでれば、毎日3日内の記事が投稿され続けることになります。

スクリプトの左サイドメニューにあるトリガーアイコン（目覚まし時計）をクリックし、「トリガーを追加」ボタンをクリックします。

下図のように、実行する関数は onMessage とし、早朝に実行されるように設定します。午前と午後をうっかり見間違うこともあるので注意が必要です。

うまく設定できたら、あとは実際にその時間に実行されることを確認します。

場合によっては、2分後などに一時的に設定し直して試すと良いでしょう。

2021年5月13日 @kimipooh

2021年4月28日水曜日

WordCamp Japan 2021 の詳細情報（タイムテーブル、チケット登録）が公開されました！#wcjpn21

これまでいくつかの地域をベースに開催されていた WordCamp について、今年の日本では、WordCamp Japan として完全オンラインとして開催されます。

新型コロナウィルスの影響によって急速にオンラインツール、リモートワークが拡大する中、WordCamp もオンラインでの開催となりました。筆者は本イベントの実行委員として関わっています。

オンライン開催の場合、イベントごとに利用するオンラインツールや、そのやり方が結構違います。WordCamp のように大規模開催（対面だったころは500人とか1000人規模）というのはなかなか経験できないことなので、どうなるか楽しみです！

かなり早めにタイムテーブルが公開！

2021年6月20（日）ー26日（土）と１週間の長いイベント開催期間！どういったことをやるのか気になるところです。

これまで参加した WordCamp では、登録が始まってもタイムテーブルがなかなか公開されず、内容がわからないので参加登録を見合わせるなどといったことがあったと思います。今回は、オンライン記者会見 (YouTube Live) をした日に、下記の様々なコンテンツが公開されました！

上記詳細は

【ニュースリリース】「WordCamp Japan 2021」参加者の募集を4/28より開始

にて詳しく説明されています。メディアキットも公開されたので、SNSの背景に使ったりできますよ！

コントリビューターデイズもあるよ！

6月21日（月）〜25日（金）の5日間で開催され、それぞれ内容によって時間帯が異なるようです。こちらはイベント参加登録に加えて、個別に登録が必要であることに注意！

当日ボランティアスタッフの募集が開始！

当日ボランティアスタッフを募集!

にある通り、オンラインツールとして、 UDトーク、oVice を扱うということ。そうしたツールは普段なかなか触れることがない場合もあるので、良い経験になるかもしれません！

2021年4月28日 @kimipooh

2021年3月18日木曜日

Contact Form 7 version 5.4 以降動かなくなった Contact Form 7 add confirm プラグイン（Contact Form 7 に確認を追加する）を動作させるには

筆者自身は、「上記内容で間違いありません」のチェックボックスを設けるぐらいで回避したり、Googleフォームも確認がないので利用はしていませんでした。

でもこの「Contact Form 7 add confirm」プラグインについては、WordPress勉強会か WordCampのコントリビューターディか忘れましたが、そうした場所で「開発したー」というのを聞いた記憶が朧気ながらあるのです。まぁそれを証明するものがないので漠然とした記憶だけです。

まぁともあれ、Contact Form 7 のバージョン5.4 から動作しなくなったという情報が、ちらほら目につくようになりました。

これについて、サポートフォーラムで修正方法が掲載されたので備忘録をこめてメモしておきます。

対処方法

Contact Form 7アップデートでContact Form 7 add confirmが効かない（WordPress.org 日本語版サポートフォーラム）

にあるように、

plugins\contact-form-7-add-confirm\includes\js\scripts.js

223行目と 226行目の、event.detail.id → event.detail.unitTag に変更すれば動くというものです。

変更前

変更後

ということですね。

実際に手持ちの WordPress 5.7 + PHP 8.0.0 でも動作することを確認しました。

2021年3月18日 @kimipooh

2021年3月5日金曜日

MAMP 上の WordPress で PHPキャッシュ「APCu」モジュールを有効にしてみよう！

MAMP 6.3 から PHP 8.0 をサポートするようになりました。

ローカル環境として、いくつかのツールを併用しており、MAMPはその一つです。

MAMP上の WordPress は最近とても動作が遅くなってきました。そのため、パフォーマンスを改善するための PHPキャッシュをつかいたいと思うようになったので、設定したメモを備忘録として残しておきます。

準備と条件

次のことを前提としています。

macOS であること（検証したOSは macOS 10.15.7）
MAMP 6.3がインストールされていること
MAMP上にWordPressをインストールして動く状態（管理ダッシュボードにログインえきる）

MAMP無料版では、PHPバージョンの選択は２つまでです。

したがって、

/Applications/MAMP/bin/php

にある PHPフォルダのうち、２つ以外は別フォルダへ移動しておいてください。そうすることで、選択したい PHPバージョンにできます。たとえば、php8.0.0と php5.6.40 だけのフォルダを残せば、下図のようにその２つのバージョンを選択できるようになります。

STEP 1. PHPキャッシュ APCu モジュールを有効化する

MAMPのデフォルトでは、 APCu モジュールは有効になっていません。

これを有効化するには、 php.ini の変更が必要です。MAMP上では、php.ini はバージョンごとに別フォルダで用意されています。MAMPの php 8.0.0 の場合、

/Applications/MAMP/bin/php/php8.0.0/conf/php.ini

になります。

このファイルにある

;extension=apcu.so

の先頭のコメントを外してください。

extension=apcu.so

そして、MAMPのサービスを終了して、再度起動しなおします。

ターミナルアプリより

/Applications/MAMP/bin/php/php8.0.0/bin/php -m

を入力してEnterすることで、PHPで利用できるモジュール一覧が出てきます。

その中に apcu が存在すれば、APCu モジュールが有効になっているということになります。

STEP 2. WordPress で有効化

＊注意：下記で紹介する WP-FFPC プラグイン 1.11.2 （2021年3月5日時点）は、そのままでは PHP 8.0.0 では動作しません。

WP-FFPC プラグイン 1.11.2 （2021年3月5日時点）を利用する場合には、

WordPress プラグイン「WP-FFPC」を PHP 8.0で動かす！

を参考に、プラグインソースの変更が必要です。変更しなければ PHP 8.0ではサイトがエラーでアクセスできなくなります。したがって事前にFTP接続などサイトのWordPressファイルを直接いじることができるようにしておくのがよいです。

MAMPのようなローカル環境ならサイトエラーが出てから、上記リンク先を参考にプラグインのソース・ファイルを後から修正することで対応は可能です。

しかし本番環境では、

https://wordpress.org/plugins/wp-ffpc/

より WP-FFPCプラグインをダウンロードし、FTP経由でプラグインをインストールし、問題の箇所を修正するのがよいでしょう。

また一時的な措置としては構いませんが、プラグインが更新されたときに変更した部分が上書きされて、サイトがエラーでとまってしまうリスクがあります。したがって、PHP 8.0で利用する場合には、本番用では対応するまで使わないほうがよいでしょう。

プラグインを有効化できたら、設定 > WP-FFPCより、APCu を選択して保存すれば有効になります。

ローカル環境だとそれでいいですが、本番環境だとキャッシュの期限を調整するとよいと思います。

参考：https://gato.intaa.net/archives/6491

2021年3月5日 @kimipooh

WordPress プラグイン「WP-FFPC」を PHP 8.0で動かす！

WordPress で PHPキャッシュ（APCu等）を有効化するプラグイン「WP-FFPC」ですが、PHP 8.0 ではエラーがでてサイトが止まってしまいます。PHP 7.4 では動きます。PHP の APCu モジュールは、さくらインターネットのレンタルサーバー等、APCu モジュールが使える PHPで有効化するとサイトのパフォーマンスがかなり上がる無くてはならないものです。それが PHP 8.0になるとサイトが止まってしまうのは大問題です。

そこで WP-FFPC 1.11.2 （2021年3月5日時点）を修正して問題を解決してみました！その備忘録をまとめておきます。

PHP 8.0.0 上で、WP-FFPCをインストールすると・・・

有効化するまえに、下記のエラーでサイトが止まります。

これらを参考にソースコードをチェックした結果、下記の赤文字の部分の問題があることがわかりました。どのような問題かは後述します。

wp-ffpc-class.php
1016-1018行目

public function plugin_options_migrate( &$options ) {

if ( version_compare ( $options['version'], $this->plugin_version, '<' ) ) {

問題を解決する方法

この 1017行目に

if($options === false) $options = array('version' => '0.0');

を追加することで本問題を回避できます。

実際には、下記の青のコードを追加するということです。

	public function plugin_options_migrate( &$options ) {
		if($options === false) $options = array('version' => '0.0');
		if ( version_compare ( $options['version'], $this->plugin_version, '<' )  ) {

原因の説明

これはプログラムのバグです。

wp-ffpc-abstract.php
514行目から

public static function _get_option ( $optionID, $network = false ) {

if ( $network ) {

static::debug ( sprintf( __( '- getting network option %s', 'PluginUtils' ), $optionID ) );

$options = get_site_option( $optionID );

}

else {

static::debug( sprintf( __( ' – getting option %s', 'PluginUtils' ), $optionID ));

$options = get_option( $optionID );

}

return $options;

}

において、戻り値の $options は、false (bool値）, 配列等いくつかのパターンがあり、最初にインストールするときに、WP-FFPCの設定が WordPressで利用するデータベースに存在しないことから、$options の値が false (bool値）となります。

そうすると、下記の $options['version'] が存在しないことになり (falseとなる）、version_compare の第１引数が false になります。しかし、version_compare は引数に string を期待しているため、型の不一致が起こります。PHP 8.0からはそうした場合にはエラーになるということです。

wp-ffpc-class.php
1016-1018行目

public function plugin_options_migrate( &$options ) {

if ( version_compare ( $options['version'], $this->plugin_version, '<' ) ) {

このバージョンチェックは、WP-FFPCプラグインのバージョンが、インストール前のバージョンよりも新しければというチェックをしています。つまりプラグインが更新したときの処理でしょう。そのため、初期値を 0.0 にすることで、最初にインストールしたときには、必ずこのチェックが真になるように、下記のように比較前にコードを追加してあげればよいです。

if($options === false) $options = array('version' => '0.0');

これでエラー無く動くので、あとは一度でも WP-FFPCの設定を保存すれば、以後は $options が false になることはないはずです。

開発者の GitHUBに ISSUEとしてあげておきました。

- https://github.com/petermolnar/wp-ffpc/issues/70

さらに WordPress.org のプラグインサポートのほうにも投稿

- https://wordpress.org/support/topic/error-on-php-8-0

修正されることを祈っておきます！

付録A) APCu キャッシュを有効にできる他のプラグイン等について

なかなか思うようなプラグインには出会えず。

Power Cacheプラグイン: https://ja.wordpress.org/plugins/powered-cache/

ドロップインに追加されるが、エラーがでてしまっている。wp-content/object-cache.php → wp-content/plugins/object-cache.php へシンボリックリンクを張れば動く。

APC Object Cache Backendプラグイン：https://wordpress.org/plugins/apc/

PHP 8.0では重大なエラーがでて有効化できず

付録B) Deprecated: contextual_help の使用はバージョン 3.3.0 から非推奨になっています ! への対応

作成：2021年3月8日

Deprecated: contextual_help の使用はバージョン 3.3.0 から非推奨になっています ! 代わりに get_current_screen()->add_help_tab(), get_current_screen()->remove_help_tab() を使ってください。 in /****/wp-includes/functions.php on line 5234

これは、wp-admin/ 以下の管理画面の上部にヘルプタブに追加する機能のようです。

https://developer.wordpress.org/reference/classes/wp_screen/add_help_tab/

が使い方が書かれていますが、結構修正は大変のように見えます。

これなくても機能としては問題ないため

wp-ffpc-class.php

add_filter('contextual_help', array( &$this, 'plugin_admin_nginx_help' ), 10, 2);

を

// add_filter('contextual_help', array( &$this, 'plugin_admin_nginx_help' ), 10, 2);

wp-ffpc-abstract.php

add_filter('contextual_help', array( &$this, 'plugin_admin_help' ), 10, 2);

を

// add_filter('contextual_help', array( &$this, 'plugin_admin_help' ), 10, 2);

とコメントして無効化しておけば、とりあえず問題なさそうですね。

2021年3月5日 @kimipooh
2021年3月8日付録2) を追記

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 は未検証です。

PHPUnitと PHPの対応表（PHPUnit）

付録（後述）で、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> -->）

の三点です。

詳細は

https://github.com/kimipooh/view-shortcodes

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

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

matrix キーは、jobs キーへ変更（matrixはjobsへのエイリアス）したので、今後は jobs キーを使うこと
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.

とでます。

WordPress and PHP 8.0

をみる 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（シェル）
プラグインテストの準備

WordPressでテスト駆動開発(PHPUnit)〜インストール編を参考に、wp scaffold plugin-tests でPHPUnitテスト環境を構築しておきます。

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

2020年11月22日日曜日

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

プログラム

https://www.meetup.com/Kansai-WordPress-Meetup/events/270719043/

プログラムは、 #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分ぐらい掛かった経験がある。
ページ数に比類してビルド時間がかかる
ビルドのデバッグが少し大変

関連情報

Reactベース静的サイトジェネレータGatsbyの真の力をお見せします (Qiita)
ブログをShifterに移行した話コスト編 #JP_Getshifter
新サービス”Shifter Headless”をリリース（デジタルキューブ）

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 は始めて聞いた言葉。

Jamstackって何なの？何がいいの？（Quiita）

をみると、JAM = JavaScript/APIs/Markup とのこと。

コンテンツ担当者にとっては、WordPress の画面なのでとっつきやすい
マルチ管理しなくてよい

１つ書いたら、複数サイトに同時更新できる

本番前には Staging でチェック

マスターと Staging の２つのサイトが動いていて、Staging のほうでチェックしてから、マスターを更新するようにしている

エラー時はログで判断する必要あり

Headless CMS ==> Static Site Generator ==> CDN / Hosting という構成になると、どこの工程でどうなっているかはログをチェックし、それらのサーバーやシステムを管理するエンジニアとコンタクトする必要あり