Autocomplete、いいかもしれない

ブロックエディターの拡張ポイントの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をアップデート

ようやくまとまった時間ができたので、本サーバーの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アナリティクスのデータは、Googleアナリティクス4 (GA4)プロパティと従来のユニバーサルアナリティクス(UA)プロパティに属しており、それによりAPIも変わる。なおUAは、2023年7月1日にサポート終了になり、データ処理が終わることがアナウンスされている。

Reporting API V4

UAプロパティにアクセスし、デイリーの各種データを取得できる。

Real Time API V3

UAプロパティにアクセスし、リアルタイム(過去30分間)の各種データを取得する。利用はデベロッパーに限定され、別途申請が必要。

DATA API V1(ベータ版)

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)がそういう設定だっただけなんだけど、ブロックを作る前に知っていれば違ったアプローチをとった気がする。

WordPress 6.0リリース後

今回の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リリース

昨日、WordPress 5.9が予定通り公開されました。メージャーバージョン時の貢献者リストに名前が載るのはうれしいものです。

5.9ではフルサイト編集機能が提供され、標準のブロックも機能強化されているようです。各ブロックの「タイポグラフィ」パネルはこれまでと違った感じで少し戸惑うかもしれませんが、面白いUIになったと思います。これって「高度な設定」パネルの直前ではなく、「色」パネルの前か後に変更できないんだっけ。。。

5.9の小ネタとしては、input要素などのreadonly属性を設定するreadonly関数が非推奨となり、代替としてwp_readonly関数が定義されたこと。PHP 8.1絡みらしいので、使っている方は忘れずに対応を。

さて昨年の年末にかけて標準のブロックをカスタマイズを試みていたのですが、こちらのサイトにも適用しました。「段落」ブロックに「字下げ」と「マーカー」を追加。「字下げ」は問題なさげですが、「マーカー」がエディター側だけ意図した表示にならない。こちらあとで対応しないとね!

テーマカスタマイザー対応した

ちょっと前に公開した「Twenty Seventeenのフォントサイズを変更してみた」で作ったプラグインにもう少し手を加えてテーマカスタマイザーに対応。使用するGoogleフォントや(ブロックエディターの)フォントサイズを変更できるようにした。

具体的には、標準のテーマカスタマイザーにトップレベルに「フォント」を、その中に「フォント名」と「フォントサイズ」を追加。それぞれ表示される内容は次の通りである。

テーマカスタマイザーでフォント名とフォントサイズを指定できるように!

フォントサイズまわりについてはCSSカスタムプロパティ(変数)を使い、ブロックエディターのフォントサイズとタイトルや本文のフォントサイズの変更を連動するようにした。 テーマカスタマイザーでフォントサイズを変更した際、プレビューでは対象のCSSカスタムプロパティの値を変更するだけでさまざまな要素に反映できる。プレビュー用のJavaScriptソースコードはとてもシンプルだ。

いまさら感はあるが、テーマカスタマイザーをいじるとちょっと楽しくなる。次に何かするとしたらカラーパレットあたりかな。

iPhone 13 miniに機種変更

iPhone 8をバッテリーしながら使い続けてきましたが、今回iPhone 13 miniに機種変更しました。

このiPhoen8はSoftBankで使い始め、1年ほどでバッテリー膨張により本体交換し、今年の正月にまたバッテリー膨張してバッテリー交換。その後にSIMロック解除してdocomoに変更し、さらにahamoに変更したものです。

しばらくこのままで行こうと思っていましたが、先月iPhone 13シリーズが発表され、個人的にサイズ感がピッタリだったiPhone 13 miniの購入を決意。はじめてApple Storeで購入しました。待つこと10日、本日手元に届きました。

iPhone 8(左)からSIMを抜いてiPhone 13 mini(右)に挿した

iPhone 13 miniを開封して、すぐに保護フィルムを張る。続いてiPhone 8から抜いたSIMをiPhone 13 miniに挿し込んでから、クリアケースに入れて電源オン。セットアップを進めました。SIMは問題なく認識してくれたようで、とりあえずは4Gで使っていこうと思います。

2台を見比べると、iPhone 13 miniのほうがわずかに小さく・軽くなっています。なかなかいい感じですね。

MacBook Air買っちゃいました!

この週末、TLに流れてくるメリット・デメリットを自分に置き換えながら考えてしまい、iPad miniを購入するタイミングを完全に逃してしまう。そんなわけで、13インチ MacBook Air(M1チップ、256GBストレージ)を買っちゃいました。

注文した翌日に届いたMacBook Air

最初は新品の約15%オフとなっている整備品でいいかなとも思ったのですが、最終的にはAmazonで購入。昨日の昼ごろに注文して今朝9時過ぎに届くというスピード感がすばらしい(ポイントも美味しい)。

ストレージはちょっと迷ったけど、256GBを選択。iOSアプリ製作にチャレンジしたいのが一番の目的だったので、これでしばらくは足りると信じたいものです。

今日のところは開封せず、ネットで情報収集してからじっくりセットアップに取りかかろうと思います。

WordPress 5.8 “Tatum”公開!

予定通りWordPress 5.8がリリース。貢献者リストに名前が記載されるのは、ちょっと嬉しいですね。

5.8ではブロックエディターまわりが大幅に機能強化され、IE11がサポート対象外になったり、WebPフォーマットがサポートされたりと、テーマ開発には大きなインパクトがありそうです。

このリリースにあわせて公開しているプラグインの3つについては、RC3で動作確認し、昨日readme.txtを更新しました。何か新しい機能を追加したかったけですが、時間的に余裕がなかったので今回はこんな対応になっています。