WordPress 6.2が無事リリースされ、手持ちのサイトを順番にアップデート中。公開しているプラグインは今回はバージョンアップせず、readme.txtに動作検証結果を反映させる予定だ。
実のところ、「Login rebuilder」についてはネタ切れ中で、まれに見かけるログインページにHTTP認証を実装するところまではできているのだけど、いまひとつ気がのらない。
今回実装したのは、BASIC認証ではなく、ダイジェスト認証であり、機能的には問題ないレベルになっている。WordPressでは$_SERVERもスラッシュでクォートされているため検証がちょっと面倒だったり、設定ページでパスワード生成や強度表示を実装してみたりと勉強になることもあったが、使い勝手がしっくりこない感じだ。
というわけで、ゴールデンウイークくらいまでは自サイトで使ってみて最終的に公開するか決定しようと思う。
投稿記事の表現を強化しようと思い画像ブロックに4つの効果を付与した。効果は画像ブロックの実態となるdiv要素かfigure要素のclass属性に追加される。
画像の外側に空きを作って昔の写真（紙焼き）っぽい見た目にする。
画像の背後に薄い影を付ける。
画像の輪郭を背景色でぼかす。
画像にモノクロームフィルターを適用する。セピアフィルターをあるがとりあえずはこちらのみ。
それぞれの効果は組み合わせ可能で、バリエーションはそれなりの数になる。今後もよさそうな効果があったら追加していきたい。
さて、スタイルは効果に応じてdiv要素（またはfigure要素）と内包するimg要素に指定した。テーマによって背景色などのカスタムプロパティ名が異なるので、汎用的なプラグインにするにはちょっと工夫が必要だ。
そんなに使うわけではないのだが、ルビの入力を何とかしたかった。そんなわけで次のような2つのボタンを追加してルビ入力支援を実装した。
リンクボタンのすぐ左がrtタグ用ボタン、さらにその左がrubyタグ用ボタンとなる。ボタンのイメージはdashiconsではなく、「Tabler Icons」のSVGを使ってみた。
このボタンを実際に使ったのが、挨拶。「挨拶あいさつ」とタイプした後でそれらを選択し、rubyタグ用ボタンをクリック。続いて「あいさつ」を選択してrtタグ用ボタンをクリックする。rtタグ用ボタンについていくつか制御を検討したのだが、読みの部分を入力するタイミングはユーザー任せでいいかなと思い、rubyタグ内のみ有効にするといった制限については今回見送った。
理想的には、rtタグで囲むタイミングでrpタグを自動的に挿入したかったのだが、うまく対応する方法がわからなかった。かといってrpタグ用ボタンを追加するのも野暮ったいので、とりあえずはこんな感じに。
RichTextToolbarButtonのiconプロパティにdashiconsではなくSVGを指定するわけだが、JavaScript（ES5）の場合はcreateElement関数を使う必要があるのでちょっとだけ面倒かも！？（svgタグをそのまま記述できるJSXの方が楽だよね）
Autocompleteで日付・時刻の入力を作っていた時、住所入力もいけそうだなと思い試行錯誤した。住所は、JavaScript（ブラウザ）のnavigator.geolocation.getCurrentPosition関数で取得した現在の緯度・経度を使ってGoogleのジオコーディングAPI（の逆引き住所検索）を使った。
ジオコーディングAPIの逆引き住所検索はPHP側（file_get_contents関数）で行い、AJAXで取得した住所リストを取得。住所検索で取得した住所は郵便番号、国名を含んており、今回はそれらを取り除いた。Autocompleteフィルターのoptionsは定数ではなく、メソッドにしてAJAXで取得した住所リストを利用するようにした。
作業中、地味にハマったのは、ジオコーディングAPIのAPIキー。はじめは静的マップで使用しているものを使用したのだが、このAPIキーではうまく取得することができなかった。理由はAPIキーの制限で、静的マップで使用したAPIキーは「ウェブサイトの制限」を制限していたためだった。このためPHP側は新しくAPIキーを取得し、別の制限を設定した（「Geocoding API で API キーを使用する」参照）。うまく両立する制限設定はあるのだろうか。
ブロックエディターの拡張ポイントの1つにAutocompleteがある。任意のブロックに対して「何か」をタイプしたら「選択リスト」が表示され、続けて文字をタイプすると絞り込みできる仕組みのだ。使い方は wp.hooks.addFilter で ‘editor.Autocomplete.completers’ 向けの関数を登録する感じなので、いくつか実装してみた。
🙂 とタイプしたら一覧が表示され、そのリストから選択する感じに。例えば、😀や🚃といった絵文字の入力が楽になる。難点を挙げるなら絵文字の種類が多すぎること。ツールバーにボタンを追加して候補がパパッと表示される方がいいかもしれない。
nowとタイプしたら日付や時刻の例が一覧で表示され、そのリストから選択する。例えば、2023年1月23日や10:07:34といった感じ。こちらについては曜日と12時間制（今は24時間制のみ）の対応は残っている。
追加の文字タイプによるインクリメンタルサーチについて、nowの後に/や:をタイプしても反応するのだが、これらは候補リストの内容も検索対象になっている表れだと思う。このあたりのくわしい仕様を知りたい。また候補リストの最大表示件数が10になっているが、この変更方法だったり、2列や3列に表示する方法があれば知りたいところだ。
そういえば「Create Block Theme」というテーマ開発用のプラグインがあることを最近知った。すごく気になる。。。
ようやくまとまった時間ができたので、本サーバーのOSをCentOS 7からCentOS Stream 9へアップデート。PHPは8.0系になりました。
OSをインストールする前に、「mysqldump」でデータベースのバックアップを取り、子テーマ、プラグイン、アップロードファイルなどの関連ファイル一式をまとめてダウンロード。続いて「certbot revoke」でSSL証明書を削除。VPSサーバーのコンパネからOSをインストールした。
Webサーバーは「Apache 2.4」をインストールし、「certbot」でSSL証明書を取得しなおす。はじめはこのままでいいかと思ったのですが、OSを変えたことだし、「NGINX」をインストールして運用することにしました。
今回の作業で少し戸惑ったのが、「MySQL」のユーザーパスワード。「mysql_secure_installation」でrootアカウントのパスワードを設定する際、次のようなメッセージが表示され、先に進めません。
Your password does not satisfy the current policy requirements
Estimated strength of the password: 50
Do you wish to continue with the password provided?パスワードの強度不足なのは理解できるのですが、指定したパスワードには英小文字、数字、記号を含んでいたのでちょっと戸惑いました。最終的には、パスワードに英大文字を含めることで強度が「100」になり、先に進めました。なお、このパスワードの強度は、「create user」コマンドなどのパスワード指定にも関わってくるようです。
今日はとりあえずここまで。
Googleアナリティクスのデータをプログラムで取得して〇〇したいと思うことはまあまあある。現在Googleアナリティクスのデータは、Googleアナリティクス4 （GA4）プロパティと従来のユニバーサルアナリティクス（UA）プロパティに属しており、それによりAPIも変わる。なおUAは、2023年7月1日にサポート終了になり、データ処理が終わることがアナウンスされている。
UAプロパティにアクセスし、デイリーの各種データを取得できる。
UAプロパティにアクセスし、リアルタイム（過去30分間）の各種データを取得する。利用はデベロッパーに限定され、別途申請が必要。
GA4プロパティにアクセスし、デイリーとリアルタイム（過去30分間）の各種データを取得する。リアルタイムのデータ取得はReal Time API V4よりも限定的（eventCategoryやeventLabel毎のデータは取得できない）。
これらはそれぞれPHPのライブラリが提供されており、例えばWordPressのプラグインとして組み込める。また上記では便宜上「デイリー」としているが、Reporting API V4とDATA API V1（ベータ版）で取得できるデータは1日数回は更新される（参考：データの更新頻度（エンハンスト）、[GA4]データの更新頻度）。当日データの取得は、数時間遅れということになる（更新された日時を知る方法はあるのかな？）。
各ライブラリを使用する場合、認証用のキーファイルが必要になり、そのアカウントのメールアドレスを閲覧者として登録しておく。Reporting API V4とReal Time API V3はクライアントオブジェクトを生成し、そのsetAuthConfigメソッドでキーファイルのパス名を指定するのに対し、DATA API V1（ベータ版）では環境変数にパス名を指定してからクライアントオブジェクトを生成するといった違いがある。
Real Time API V3のPHPサンプルは、リンク先のgithubではWebアプリになっている。そこでReporting API V4を参考に適宜クラス名を変更ながら試すことに。イベントデータを取得するところは、次のような感じになった。
$optParams = array(
'dimensions' => 'rt:eventAction,rt:eventCategory,rt:eventLabel'
);
$results = $analytics->data_realtime->get(
'ga:XXXXXXXXXX',
'rt:totalEvents',
$optParams );DATA API V1は、UAのサポート終了までに正式版がリリースされると思うが、リアルタイムのイベントデータ取得が今のままだとUAからの移行が大変そう。現在の仕様に合わせて対応していくべきなんだろうか。
オリジナルブロックを作ってみたくなり、汎用性が高そうなGoogleのMaps Embed APIを使ったものから始めることにした。
手本にしたのは「カスタムHTML」ブロック。サイドバーに設定項目を追加し、iframe要素のsrc属性などを変更できるようにした。プレビュー時に設定される属性についてはもう少しやりようがある気がするのだが、一通りの機能は実装できた感じ。
開発時に最初に戸惑ったのは「npm start」コマンド。このコマンドが実行中、ソースコードの変更を監視し、変更時にすぐビルドするものだった。開発中はそれなりに便利なんだけど、それなら中断・終了方法くらいはきちんとそう書いてほしかった。
またオプションデータを取得・更新できるのが管理者のみということも意外だった。REST API（settings）がそういう設定だっただけなんだけど、ブロックを作る前に知っていれば違ったアプローチをとった気がする。
今回の6.0へのアップデートは、4.9から5.0へのアップデートと異なり、比較的小規模な感じで、ブロックエディターまわりが中心。まあテーマ開発者はそれなりに大変だったようです。個人的には目に見えるUI、見えない部分も含め、そろそろ落ち着いてほしい。
さて私の方は、リリース日の前日夜（実質当日）に業務が入っていたので、「Login rebuilder」はRC3で動作確認し、リリース日の数日前に2.7.3をリリース。あわせて動作確認したいくつかのプラグインはreadme.txtのみ更新しました。公開中のプラグインですが、おおむねネタ切れです。。。
WordPress 6.0ですが、いくつか気になるところがあったので、リリース後にtracへポストしました。1つは編集画像の適用範囲が国際化対応していない問題なので、早ければ次バージョンには対応されそうです。もう1つはシングルサイトで使用可能になったget_user_count関数で正しいユーザー数を取得できない問題。ネーミングで勘違いしてポストした後、ログ出力して確認することでユーザー数を更新する仕組みはほぼ理解できたのですが、肝心のユーザー数を更新する処理がないような気がします。
そういえば、先週末「WordCamp Europe 2022」がポルトガル開催されたようです。オフラインのWordCampはかなり久しぶり。今年の「WordCamp Japan」について、そろそろアナウンスがあったりするのかな。
昨日、WordPress 5.9が予定通り公開されました。メージャーバージョン時の貢献者リストに名前が載るのはうれしいものです。
5.9ではフルサイト編集機能が提供され、標準のブロックも機能強化されているようです。各ブロックの「タイポグラフィ」パネルはこれまでと違った感じで少し戸惑うかもしれませんが、面白いUIになったと思います。これって「高度な設定」パネルの直前ではなく、「色」パネルの前か後に変更できないんだっけ。。。
5.9の小ネタとしては、input要素などのreadonly属性を設定するreadonly関数が非推奨となり、代替としてwp_readonly関数が定義されたこと。PHP 8.1絡みらしいので、使っている方は忘れずに対応を。
さて昨年の年末にかけて標準のブロックをカスタマイズを試みていたのですが、こちらのサイトにも適用しました。「段落」ブロックに「字下げ」と「マーカー」を追加。「字下げ」は問題なさげですが、「マーカー」がエディター側だけ意図した表示にならない。こちらあとで対応しないとね！