2024年4月21日日曜日

【救出】7年前から更新されていない contact-form-7-to-database-extension プラグインを WordPress 6.5.2 with PHP 8.3.6 で警告なく動作させる

基本的に開発者によってサポートされなくなった(長期間更新されていない)プラグインは、使うのは非推奨、他の代替プラグインへの乗り換えを考えるというのが素直な流れです。しかしながら、サーバー移転や PHPバージョンアップグレード、WordPress のアップグレードなどによって動作しなくなったプラグインについて、とりあえず延命したい、データを取得するためにも一時的にも動作させたいという要望はあると思います。

そこで、自身がそうした対応をしたプラグインについてどうしたのかを備忘録として残していきます。

今回は、下記のプラグインが対象です。

7年前から更新が止まっており、WordPress 4.8.28 がテストされた最後のバージョンです。
Contact Form 7 の投稿データをデータベースに保存してわかりやすく WordPress 内でチェックできる大変重宝したプラグインでした。代替プラグインとしては、Contact Form CFDB7
などがあります。新規利用なら、こちらを利用するのがよいでしょう。

WordPress 6.5.2 with PHP 8.3.6 での状況


このプラグインは、公式リポジトリでは 2.10.29 になっていますが、 GitHub のほうには、2.10.37 があります。ここでは、2.10.37 を元に説明します。

下記の2つの問題がありました。いずれも警告ではありますが、DEBUG を true にしていると2つ目の警告によって、データがうまく表示できない問題がありました。
  1. PHP 8.1 からの型不一致問題による警告
    Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated - CFDBViewWhatsInDB.php on line 71
  2. PHP 8.1 からの浮動小数点型(float)から 整数型(int)への暗黙の変換が非推奨になったという警告
    Deprecated: Implicit conversion from float-string "1692501560.5118" to int loses precision - CF7DBPlugin.php on line 1227
    参考:https://www.rectus.co.jp/archives/20218

これらの対処は下記の通りです。

1. PHP 8.1 からの型不一致問題による警告への対処


CFDBViewWhatsInDB.php on line 71 において、
下記のコードが 71行の前に下記のコードを追加する。

if($currSelection === NULL) $currSelection = "";

これは、下記の htmlspecialchars の第1引数については string 型(文字列型)を求めているのに、$currSelection に NULL データが入る可能性があるということで、それが PHP 8.1 からは非推奨になるということです。
$currSelectionEscaped = htmlspecialchars($currSelection, ENT_QUOTES, 'UTF-8');

2. PHP 8.1 からの浮動小数点型(float)から 整数型(int)への暗黙の変換が非推奨になったという警告への対処


CF7DBPlugin.php on line 1227 において、コードを下記のように書き換えます。
実際には $time 変数について整数型 int をキャストして、date 関数に引き渡す前に整数にしてしまうということです。
 
return date(CF7DBPlugin::$customDateFormat, (int)$time);

date 関数は 第2引数として整数型を求めており、$time については float 型 であるため、従来だと暗黙の型変換が起こって int 型として処理されたのですが、 PHP8.1 では float 型から int 型への型変換は明示的にせよということになったため。

上記修正を施したバージョンへ置き換えるには?


修正を施したバージョンは、下記に Fork して保存しています。


こちらの Code の▼ より Zip 形式でダウンロードして、WordPress にインストールしてみてください。フォルダとしては contact-form-7-to-database-extension-master と公式プラグインの contact-form-7-to-database-extension と異なるため、上書きではなく新規で同じプラグインが追加されます。バージョンとしては 2.10.37k としているので、公式プラグインのほうを無効化して、新しいものを有効化すればよいです。

バージョンにアルファベットをいれたのは、あくまで新しい WordPress や PHP でのエラーや警告を消しただけであり、機能追加していないこと、また Fork もとのほうが新しいバージョンをだしてきたときにややこしくなるので、区別するためにそうしています。

2024年4月21日 @kimipooh

2024年4月13日土曜日

「Okayama WordPress Meetup #9 | プラグインアップデートを学ぼう」に参加して #wordpress #okayamawpmeetup

私にとって WordPress Meetup への参加について、東京の次に遠い場所となる岡山県にやってきました。岡山県といえば、2019年に別のイベントで訪れて以降、2度目になります。

今回は懇親会も参加する日帰りということもあり、観光できる時間は岡山駅に到着する11時半から、Meetup が始まる13時半までの最長2時間。あちらこちらいくには少し時間が心もとないため、昼食に「デミカツ丼」を食べることを主軸に考えました。観光については一番最後に紹介します。


プログラム



自己紹介



オーガナイザーのお一人から Meetup に関する説明。
その後、参加メンバーの自己紹介タイムとなった。20名弱参加と部屋がいっぱいになるぐらい参加していました。台湾から参加された方もいたのに驚きました。久しぶりにあった方もいて楽しかったです。

以下、筆者が発表者からきいた内容の備忘録です。したがって必ずしも筆者の意図した通りの内容になっているかどうかの保証はありません。
筆者のコメントは、 先頭に # をつけています。

プラグインアップデートの仕組み(假谷さん)



発表資料(Googleスライド)

プラグインについて自動更新が無効状態なのに、更新されているという現象が発生。なぜか、そのことを調べてみたことを発表してみたい。
過去にも Ninja Forms Contact Form(2022年6月) や Loginizer(2020年10月) で強制アップデートはあったらしい。

アップデートの概要(コア、テーア、プラグイン、翻訳がある)

バージョンチェックと処理の流れを知るには、 wp_cron について知る必要あり。

WP Control というプラグインをインストールすると、ツール > Cronイベントから WordPress の Cron がどのように動いたのかをチェックしたり、設定できる。

# 以下、筆者のローカル環境でインストールしてみたときのスクリーンショット




取得したデータは、transient と呼ばれる内部キャッシュに保存される。
wp_optionsの _site_transient_update_plugins に保存される。
更新頻度は12時間ごと。

開発元が公式リポジトリに反映させても、WordPress側ではまだ見えていない可能性がある(12時間に1度の更新頻度からか)

即時反映させるための対処方法としては、ダッシュボードの更新にある「確認してください」をクリックすると更新されるようだ。


#上記は筆者のローカル環境。そういえば最近更新していないので WordPress のバージョンがちょい古ですね (^^;

wp_maybe_auto_update 関数などを使えば、強制アップデートをかけることができるのでは?

AUTOMATIC_UPDATER_DISABLED 定数で全自動更新を無効化できる。
wp_config.php に
define('AUTOMATIC_UPDATER_DISABLED', true);
として追加する。

あるいはフックで追加することも可能

UpdateURI の仕組みが WordPress 5.8 で導入された。これは、プラグイン側の情報に、ダウンロードする場所を指定するための機能があるということ。たとえば GitHUBからプラグインをダウンロードなどできるようだ。

公式リポジトリに公開しないようなプラグインや、公式プラグインをやめてしまって他の人が同名のプラグインで作成しても勝手に置き換わるようなことがなくなるメリットもあるようだ。
もちろんデメリットとしては更新の仕組みは自前で用意する必要がある。

# Introducing “Update URI” plugin header in WordPress 5.8 – Make WordPress Core

WordPress 6.5 より、Requires Plugins を定義することで、プラグインの依存関係の設定ができるようになった。
# Contact Form 7 がある前提で、そのプラグインを拡張するプラグインをつくるときに必要なのでありがたいですね!

# 参考:Introducing Plugin Dependencies in WordPress 6.5 – Make WordPress Core

こちらを設定していると、依存関係のあるプラグインが無効化できなくなる模様。
#つまりは、
プラグインA
 ┗ 依存プラグイン B
の場合、依存プラグインのほうで Requires Plugins として プラグインAを設定していた場合、依存プラグイン Bを無効化してからでなければ、プラグインAが無効化できないということか。
また、依存プラグイン Bは、プラグインAをインストールしていないと、インストールできないというメッセージがでてくるのではないかと推測(未検証ということ)。

質疑応答


質問)過去にも Ninja Forms Contact Form(2022年6月)Loginizer(2020年10月) で強制アップデートはあったらしいと話されていたのが、結局それはどういうことでそうなったのか。

回答)API 経由で強制されたのかもしれない、そうした記事を読んだような気もするが不確か。
#後日、発表者の方より Managing Your Plugin's Security (developer.wordpress.org)の情報をもらいました。これによれば、プラグインの脆弱性が WordPress セキュリティ チーム によって発見されると、プラグイン作成者に連絡して修正を促されたり、修正や更新される可能性があるということ。また「Automatic Plugin Security Updates」にあるように、WordPress 3.7 以降は、深刻な脆弱性をもつプラグインについて自動更新させる仕組み(メールでの連絡と審議プロセスが上記リンク先に書かれてます)を用意しているということですね。

プラグインアップデートで気をつけていることトラブル事例紹介(井元さん)



発表資料(Googleスライド)

コアのバージョンアップは、メジャーバージョンアップと、マイナーバージョンアップがある。

バージョンは3つの数字で構成されている(6.4.3 など)。

6.4.3 というバージョンの場合、6.4 までがメジャーバージョン、6.4.3 の 3 がマイナーバージョンと呼ばれている。

マイナーアップデートは、おもにバグ修正、パフォーマンス向上、セキュリティパッチなどが多く、アップデートによるサイトへの影響はほどんどない。それに加えてメジャーアップデートは、大きな変更がされる場合もあり、サイトへの影響もそれなりにある可能性がある。
# プラグインやテーマ、テーマ内のカスタマイズ部分などが非対応でサイトが動かなくなるとか
プラグインは、wo-content > plugins フォルダに保存されている。

プラグインアップデートで気をつけること

1. WordPress のバージョンと互換性があるか

#公式プラグインの情報は下記より確認できる
互換性がない場合、有効化できない、動作しないなどの警告がでたりする。

2. PHPのバージョンと互換性があるか

こちらについては、サーバーの PHP が古すぎて最新 WordPress が動作しない、あるいはWordPress が古すぎて 最新 PHP では動作できない場合があるので注意

3. メンテナンスがされていないプラグインかどうか

最終更新日がある程度あたらしいかどうか。
それだけでは判断せず、メンテナンスがされているか銅かを調べる。
あまり更新頻度が不要なプラグインがあって、メンテナンス頻度が低い場合(メンテナンスはされている)もあるので注意。


# 筆者の公式プラグイン(WP ADD MIME TYPES)などの場合、仕組みが単純(管理画面に力をいれているが)のため、それほど大きなメンテナンスが不要。そのため、思い起こしたときに検証済み情報を更新しているので最終更新日がある程度期間があいてしまっているが、実際には、いくつかの常に最新している WordPress の本番環境で動作させているので、そういう意味では常にメンテナンスはしている状態ではある。またプラグインサポートに書いてもらうと、毎日チェックしているので対応したりしている(いまのところ、ほぼ海外からのリクエストばかりですけど)。

4. functions.php に気をつけよう

自作フックなどを作っていた場合、その仕様が変更になったりなどして動かなくなる可能性があるので注意。

なぜアップデートが必要なのか


1. 脆弱性に対する対応

脆弱性をついてデータの盗聴(情報漏洩)、改ざん(加害者になってしまうおそれあり)、破壊(金銭的な被害を受ける)等いろいろな影響をうける可能性がある

2. 最新バージョンとの乖離

たまにしかアップデートしないと機能が大きく変化してしまっているので、問題がでやすく修正も難しくなってしまうおそれがある。

#あといくつか説明されていた。

アップデートの手順


1. バックアップ

プラグインアップデートによってサイトに影響(サイトが動かない、データがおかしくなる等)がでる可能性がある。したがってまず最初にするのはバックアップすることが大事である
もとにもどせるように練習しておくことも大事

2. プラグインの互換性の確認

バージョンアップによってどのような影響がでるのか事前に調べておく
利用している WordPress や PHP バージョンとの互換性

3. テスト環境でプラグインをアップデートする

できるだけ本番サイトと同じ状況を作るのが大事
# たとえば同一サーバーで別サブドメインなど( example.com なら demo.example.com にクローンして BASIC認証でロック(HTTP Authプラグイン等)しておくとよいかと。クローンサイトが Googleクローラーに検知されると SEO的にまずいため)
# あるいはパソコンにローカル環境( Local のようなツールをつかう ) とか

たとえばサイトをテスト環境にクローンして、全部最新にアップデートして問題が生じたところをどうなおすのか確認したりすることもある。

プラグインをアップデートしたことでおかしくなった事例


事例1)class、id の相違による見た目の崩れ

プラグイン側が出力する HTML(本体のほうでも)の class、 id、あるいはそもそも構造がかわってしまう場合もある。

こうした場合には、出力された HTML をみるとプラグイン側が CSS を追記していたので、それにあわせて CSSを調整するのが簡単。

プラグイン側も readme (プラグインのアップデート履歴として表示される)で class 変更した、CSS追加したなどを書いておくのがよいと想う。

事例2)サイトが見れなくなり、 WordPress の管理画面に入れなくなる

深呼吸して、サーバーのエラーログをチェックしてみる。
今回の事例では、下記が気になるところ。
PHP Parse error: syntac error
プラグイン/includes/mail.php on line 555

PHP上で深刻なエラーがでている。
該当ファイルの 555 行が問題となっている。

ということがわかる。もちろん PHP をよく知っている人なら見ていったらよいが、とりあえずはサイトの状況をみるのがよい。事例ではプラグインが要求しているのが WordPress 6.3 以降、PHPは 7.4以上。しかし サイトは、WordPress 6.2.4、 PHP 5.6.x だった。つまりは PHPが古すぎるなど乖離しすぎているのが問題。

# PHP 5.6系と 7.4.系はもう相当変化があるので、動かないことは自明といってもよい。
# WordPress の話ではないが、経験したことだと pukiwiki plusという wiki系ツールが、 5.4 以降に関数が廃止されてしまって動かなくなったなど割と致命的なこともあった。

デバッグモードを有効にするとより詳細がわかる場合もある。

wp-config.php に
define ( 'WP_DEBUG', true );
をいれる。

ただ本当に大量に警告がでたりするので、テストしおわったら無効化しておくこと
/* define ( 'WP_DEBUG', true ); */
のように /* と */ でくくった間は無効化できる。

質疑応答


質問)テスト環境の公開設定をどうしているか

回答)レンタルサーバーでは、大抵は初期ドメインと独自ドメインの2つはあるはずなので、初期ドメインにクローンして、そちらにはBASIC認証をかけているケースもある。

質問)アップデートをかけるときに、1つずつサイトにログインしてアップデートしているのか集中管理をしているのか

回答)1つずつログインして確認してからアップデートしている

#WP-CLIなどのツールを使う場合もある
#筆者は、過去に何度かそうしたやり方について WordCamp や Meetup などで発表したことある

アップデートについて話し合う会



グループに分けて話し合い
4人ぐらい

それぞれどのようなアップデートの方法をしているのか、熱く話し合いつつ、その後岡山での食事についてで盛り上がった。
「鉄板ポテトサラダ」なるものは岡山県民も知らないとか。たしかに検索しても出てこない。訪れた方から、暖簾に「鉄板ポテトサラダ」がある写真を提示されていたが、ちょっと気になりますね。岡山駅の南側の商店街にあったとか。

アップデートについては、内部的なサイトなら強制的にバックアップして自動更新して、問題あったらいってくれという感じでいけるかもしれない(WP-CLIなどを使って)。あるいは自身がすべて管理しているサイトでも可能かもしれない。しかしながら、テーマのみ管理や、WordPress のシステムメンテナンスだけしている顧客ということになるとそうした放任的なやり取りはなかなか厳しい。そうなると1つずつ影響がないかどうか調べた上で、個別アップデートが必要になってくるかも。サーバー1つに1サイトだと話は簡単だが、実際にはなかなかそうしたことは難しい。

懇親会



懇親会では、WordPress の話だけでなく岡山在住の方々と、岡山の観光地は?みたいな話で盛り上がりました。「醍醐桜」などは、車をチャーターしていく必要があるようですが、Meetup をそこでやってバスをチャーターしてみては!なんて話も面白かったですね。

で、かなり最終に近い新幹線+京都の在来線に気分良く載っていたのですが、同じ座席の切符をもつ乗客が出現。??と思っていたら、ちょうど降りないといけない京都をすぎて、名古屋に向かっていたのでした。

えっ、帰れるの!?とおもって、車掌さんに相談。


余裕であると言われましたが、なんと静岡駅で不審者が線路に立ち寄ったということで30分ぐらいの遅延が!? 京都駅まで戻れたとして、そこから在来線がないのでは?!とか、Google Mapで調べると、米原で一泊する情報しかないとかでドキドキしていましたが、なんとかギリギリ、こだまにのればギリギリなんとかなることがわかり、安心。 Google Map も後から情報が更新されて、こだまの次の「のぞみ」にのれば帰ることができそうでした。最終的には名古屋駅についた段階で、30分ぐらい遅延が生じていて、「のぞみ」「ひかり」では帰れないことに。ギリギリ「こだま」が遅延していなかったので、こちらで京都に変えることができ、地下鉄の最終電車(23:47)に乗ることができました。

いずれにせよ、今後は岡山から京都は1時間程度でつくので、絶対にねないようにしないといけないと思ったのでした。またもう30分ぐらい早い便(20時ぐらい)には新幹線にのるとなお安全ということと、飲み過ぎは厳禁ということも心に刻んだ一日となりました。

観光



岡山駅にきたら、とりあえず桃太郎銅像のところにフラフラといって写真を撮る。これはまぁ鉄板的な定番でしょう。


昼前に岡山駅に到着。早速路面電車にのって城下下車。PITAPAが使えたのが助かりました。先頭のところの運賃箱の下側にあるタッチして入る感じになります。


城下から降りて街並みをみると、かなり直線的に長い道路だなと思いました。


雅芳(がほう)(Google Map)で「デミかつ丼セット」を食べるんだ!と強い気持ちで訪れました。カツ丼 野村とまよったのですが混んでそうだったので、こちらを選択しました(次回機会があれば野村のほうにもいってみたい)。岡電にのりたかったので岡山駅から城下で下車しましたが、歩いて17分でもいけます。12時前についたときには満席でしたが、少しまっていると後からきた人と相席でもよいならということで、座敷に案内していただきました。デミかつ丼については、期待していた通りデミグラスソースがたっぷりとのったとんかつとご飯は、なかなか相性がよかったです。


西川緑道公園を目指してあるいていくと、商店街を通過。そのあたりの街並みも楽しいですし、脇道的なところでも直線的な長い道路になってますね。なかなか壮観。


大通りを歩道橋からみた感じが、左上の写真。右側は、西川緑道公園のところにある下石井公園。


ここから岡山駅までブラブラと散策したのでした。桜があるかなーとおもったら、それほどでもなかったですね。


暑い!暑いので、イオンモール横にある岡山駅の地下道を通って岡山駅へ。


地下で初めてストリートピアノのライブを見かけました。子どもも含めて何名な並んでました。


妻からのリクエストは、廣榮堂のきびだんご、古見屋羊羹の高瀬舟羊羹。これらのミッションは岡山駅2Fのお土産屋でクリアしました。高瀬舟羊羹については、おみやげ街道のところの大手まんぢゅう付近にありました。

2024年4月13日 @kimipooh

2024年2月24日土曜日

WordCamp Kansai 2024 セッションデイ(2日目)に参加して #wckansai #WordCamp

WordCamp Kansai 2024の2日目は、セッションデイです。昨日のコントリビューターデイについては下記のブログを参考にしてみてください。


Photo by WordCamp Kansai 2024: https://twitter.com/WCKansai/status/1762443015900270719


本日、午前中は海を見たい!という気持ちになって、三ノ宮の商店街、三宮神社、メリケンパークへと散策しました。その時のことは、本ブログの一番最後に紹介します。

そういえば、WordPress 関連で神戸に訪れたのは、WordCamp Kansai 2014のキックオフミーティング & WordBench神戸(現在の WordPress Meetup の前身となる勉強会)のときだったのですねぇ。

以下、セッションに関しては筆者が理解した内容の備忘録です。
そのため実際の発表者と意図しない内容になっている可能性があることをご留意ください。
# は筆者の感想的な内容になります。

セッションの動画配信


下記にて公開されています。

Japan WordPress Community (YouTube) - 部屋ごと

WordCamp TV - 個別

発見した参加者のブログ


公式サイト(2024-02-27追加)
あとから X の #wckansai をチェックしていて見つけた参加ブログで気付いたものをリストアップしておきます(2024-02-25ぐらいまで)。

スポンサーブース



昼過ぎに訪れました。昼からのセッションの少し前でしたが、それなりに賑わっていました。

LINE公式アカウント&WordPressで更新頻度が上がった話




椅子に座りきれないほどの人数が参加していました(50名以上)

LINE の Messaging API よりデータをとってきて、カスタムフィールドのデータを更新している。WordPress にログインして更新するということは、なかなか一般の人はやってくれない。しかし LINE での更新はかなりの確率でやってくれる。

お茶会スペース 純喫茶わぷ~(情報交換スペース)




昨日のコントリビューターデイに引き続きお茶会で提供される紅茶などは L'ATERIER DISCIPLE DU BONHEUR からわざわざ来られて紅茶など飲み物を準備されていました。

あとは運営からの提供されたお菓子を食べながら、初めてお会いする方々と楽しく歓談しました。

ブロックエディタでWebサイトの制作がどうかわったのか?実装事例から見る現在のWordPressの設計と構築



ブロックエディターが出てから 5年がでて、当時で始めた WordCamp Osaka 2019 のときにも、ブロックエディターをつかって制作しているかという質問をするとほとんど手が上がらなかった。今回はちらほらとでている。とはいえ、会場の状況をみるとまだまだ浸透まではしていなさそう。
クラシックエディタのほうは制作フローの過程が多くあった。
  1. 静的HTMLを先に制作
  2. 先に制作したHTMLをもとにテーマを作成
変更・追加が管理画面からできないこと、管理画面と全然見た目が異なる、リニューアル時にも同じ構成が必要。

顧客側は入力を限定(カスタムフィールドなどで)させることでデザインに影響がないようにしたのはよかったが、その結果、制作にかかる負担が増加していた。

いまの ブロックエディター構成前提の場合、
  1. 事前に HTMLコーディングはしない
  2. どの構成を使うかの検討
  3. 構成単位で制作
  4. 入力
サイト全体を管理画面から変更できる

構成の分解が必要
「ブロックスタイル」「ブロックパターン」「ブロック開発」「プラグイン利用」「テンプレート」など

#再利用ブロックは、いつのまにか「同期ブロック」と名称変更になってた。

いまは設計が大事。サイト全体でどのようなパターンがあるのか、どのようなブロックが必要。それは運用するスキルも踏まえて考える必要あり。どういう入力がありえるのかなど。

実装工数がかかることはある
レスポンシブ周り(PCとスマートフォンなどの余白とか)

ブロックエディターになってくると、ページ数での費用ではなくブロック数での費用に変えていく必要がありそう。

質疑応答
  • 質問:作り始まる前に、顧客から触りたいという要望があるのか、それとも触るように構成しておくのか
    • 回答:後から触りたいという要望が出てくることを想定している(顧客の「絶対に触りません」は参考にしない。

WordPressサイトに関わるキャッシュを理解する



キャッシュはウェブサイトを早くすると思っていた。ただし大規模サイトを手掛けていると、そうした理解はうまくいかない(キャッシュが効きすぎるなど)場合がでてくる。

キャッシュとは、サイトの閲覧をする場合、表示に必要なデータを毎回計算して表示する場合があり(#WordPress などHTMLを動的生成するもの含む)、そうした場合、再利用したほうが速くならないかというために作られた仕組み。

キャッシュはレスポンスに対する応答が速くなるが、しかし根本解決にはならない。たとえはサイトそのものを表示するプロセスが速くなるわけでないため。たとえば動的にサイトを構成するのに3分かかる場合、キャッシュによって事前に表示データを用意することで速くする仕組みのため。そしてキャッシュについては、その管理する仕組みも必要になり、それが設計をややこしくもなる。
#補足:たとえば事前用意したデータ(キャッシュデータ)と、最新データが異なる場合には、事前に用意したデータを一旦破棄して新しく作り直す必要がある。そこは時間がかかってしまうということ、またそのチェックが必要になる。

キャッシュはいろいろある。CDNキャッシュ、サーバー側キャッシュ(ページキャッシュ等)、PHPキャッシュ、WordPress コアキャッシュ、ブラウザキャッシュなど。これらを把握しないと適切にキャッシュを使えない可能性がある。

また相当処理が重いことをするのにキャッシュを使う場合、事前にそれをすることになるのでサーバー負荷が大きくなってしまいサーバーがダウンしてしまう可能性もある。

下記などをキーワードに考えていく必要あり
  1. オリジンサーバーの内か外か(外はネットワーク上)
  2. キャッシングされるデータの粒度は大きいか、小さいか
  3. インフラ側のキャッシュか、WordPress 上のキャッシュか、あるいは独自のものか
  4. プラグイン等のキャッシュ機能があるものは、何のキャッシュなのか
また、キャッシュについて少し深堀りすると
  1. HTTP キャッシュ(ネットワーク)- CDN、ブラウザ、プロキシサーバーなど
     あれ?更新したのに、ブラウザ上で更新されていないという感じ
     何秒経ったかで古い、新しいを判定している(HTTPレスポンスのCache-Controlフィールドで指示。正確には指示要請するレベルで、実際にはどこかで上書きされる可能性あり)。ウェブシステム(apacheやnginx)に対する設定(PHP側ですることもあり)となる。プラグインで実装されている場合には apache の .htaccess に書き込んでいるだけということになる。
  2. ページキャッシュ
     WordPress は毎回動的にHTMLページを作成している。これをあらかじめ作っておこうというもの。粒度が大きいので効果が大きい。CDNはインフラ部分でしていることになる。CDNとのやり取りをするために専用プラグインをインストールするケースもある。プラグインだけで実装しているなら、プラグインで制御するので高速化できるのは一部にすぎない。
     キャッシュするとNGのケースがある。ログインしているページ(会員サイトや管理画面)がキャッシュされると、ログインせずに誰でもアクセスされてしまう。
    #誰かログインできる人がアクセスすると、そのページが生成されるため
    大抵は管理画面にアクセスするURLをキャッシュの対象外にしている。しかしログインURLが変更するようなケースだと事故が起こる可能性があるので注意が必要。
     独自実装しているケースの場合、特定キャッシュだけするようできるものがよく、どれをつかうか考える必要がある。
  3. WPオブジェクトキャッシュ&永続化
     WordPressコアに実装されている。これはメモリに保存される。メモリは利用し終わると破棄される仕組み。そこで永続化が必要になる。これはデータベースへの問い合わせ(クエリ)について WordPress はサイトへのアクセスがあると毎回しているが、ここをメモリに保存させて永続化させることで、同じ問い合わせについては、すでに問い合わせてメモリにいれたデータを再利用する仕組み。
     WP_Object_Cache 関数をつかうことで使うことができる。使えると効果は大きいが難しい。またインフラ側が対応している必要あり。APCu、Memcached、Redis等。
    #インフラ側にそうした機能があるなら、これらを使うことができるプラグインもある。
以上のようにキャッシュは深堀りすると沼にハマっていく。しかしながら、キャッシュの大筋についての少しずつ実践の中で学んでいくと助けになっていくだろう。

ユーザー行動の分析から、サイトの改善ポイントを探ろう




#最後あたりで参加。そのため、細かな内容はわからず。キーワードだけ拾ったので、また後で調べてみることにする。

Microsoft Clarity を使ってみよう!
====
#翌日インストールしてみました。WordPress でのインストール方法については、下記が参考になりました。
無料ヒートマップ Microsoft Clarity を WordPress で使おう | サーバー総研


Clarity の Clarity tour にある See live demo をみると Users overview がでてきました。実際にどのように活用するかは、このセッションの動画や資料が後日公開された後に、じっくり見ることにします。
===

ChatGPT との議論。定量分析も合わせてしておくのがよい。

ただし、個人情報の保護の観点からは、Google Analytics 4や Microsoft Clarity を使わない選択肢もある。

質疑応答は、発表者の意向により、まずは隣の人となにか1つ聞いてみたいことについて話し合うというユニークな形式になった。私自身は隣がいないことと、最後あたりの参加のために状況がよくわからなかったので傍観のみ。

質疑応答

質問:どの程度のタイムスパンで検証したらよいのか
回答:目的によってしまう。ECサイト等の場合にはデータが変わっていくため、毎日みたほうがいいでしょう。3日や1週間で上がり始めたなと思ったら見なくなるとか。落ちたらアラートが来たりするのでそのときにみるとかもある。しかし基本的には最初は毎日みて、普段がどのような推移になっているのか、そもそもデータが取れているのか(取れていない場合もある)をチェックしたほうがいい。あとは定点観測でいいのではないかと思う。

質問:異常値はどのように捉えたらいいか
回答:自分の中での異常値を考えておく必要あり。大体異常値はスパムと思っていいでしょう。Microsoft Clarityの場合、異常値が Botかどうか分かる。そしてこのツールの場合には、 Botを除去できない課題はある。異常値の場合には一日ずっとあがる。

質問:個人情報を取得しないようにするには(確認画面とか)
回答:スライドに対処方法のリンクを書いている
#「Microsoft Clarity(クラリティ)のデメリット(リスク)と対処法」かな

閉会式




長いようであっという間だった WordCamp Kansai 2024 も閉会式となりました。
WordPress Meetup がたくさんあるので、そうしたものに参加してみて!というお話があった

アフターパーティ



会場設営のためスポンサーブースで待機。その間、スポンサーブースでプチ飲み会が始まりました!ドリンクサーバーの方がいて、どのような飲みものがほしいのか尋ねると、おすすめのものをいってくれます。筆者は少し甘めのビールはないかと訪ねたところ、Hazy IPAを進められました。フルーティで非常に飲みやすかったです!


次に飲んだのが、高価なビールはなにか?ときいて指定されたビール
THE ALCHEMIST Focal Bangerですね。1缶で2000円超えのビールです。


こちらも苦みが薄くて飲みやすいビールでした!また歓談する中で、奈良からこられた親子で来ている方とお話する機会があり、お子様は大学1年生工学部とか。初めて訪れた海外がギリシャだったとか。「若いうちから海外を経験するのはいいことだよ〜」など楽しく歓談できました。また知人にも出会ったので、少し仕事上での課題について話し合ったりしました。


そうこうしている内にパーティの準備ができたので会場へ。実行委員長の短い挨拶を聞きながら、ローストビーフやその他いろいろな準備された豪華な料理を楽しみつつ、歓談できたのでした。やはりイベントは対面はいいですね!


散策(海をみたい!)


さて、せっかく神戸にきたのだから海を見に行こうと思いました。そこで実行委員長には大変心苦しいのですが、開会式の間に少し三ノ宮周辺を散策してました。そのときの体験を紹介します。

神戸三宮センター街




神戸三宮センター街は、10時台はまだ店舗も空いていないところが多く、閑散としていました。昼近くになると上の写真のようにかなり混雑していました。


ぶらぶらと散策しつつ、生田神社一の鳥居を南に通り抜けて三宮神社へ。

三宮神社




裏門からはいって参拝。表門から抜けてメリケンパークまで歩きました。

メリケンパーク




メリケンパークにいく途上に歩道橋があります。久しぶりの歩道橋、その上からみた道路もまっすぐに伸びていて見ごたえがありました。メリケンパーク前に、「メリケン地蔵尊」が鎮座していました。海でなくなった方々のための慰霊のために昭和50年頃に安置されたとか(産経新聞


さてメリケンパークについたわけですが、この近くにあるホテルオークラ神戸は、かなり前に家族と泊まったことがありました。私にとっては、ついて「観光に行くぞ!」とおもって、ホテルをでた直後に、つまずいてひっくり返って足を捻挫して歩けなくなって、一人だけホテルで休んで痛みに耐えていたという痛い出来事がありました。となると、リベンジしないとですね!ということで、あまり時間はありませんが、少し海を堪能することにしました。


50 MPモード(上記は 37.5 MP)で撮影した写真。太陽光が海に反射して輝いているのは非常に心が和みました。 

昼食



いくつか行きたい店があったのですが、混んでいたり、ランチをしていなかったりして機会に恵まれませんでした。時間もなくなってきたので、再び神戸三ノ宮センター街に戻って、サンプラザの地下にて、牛カツを食べました。


やはり神戸に来たなら、神戸牛を食べないとですね! 小さくきってあるレアの牛カツは、かみごたえはあるものの、柔らかくて美味しかったです!

2024年2月24日 @kimipooh