ページ

2024年7月3日水曜日

【備忘録】WordPress.org で2段階認証を有効にする方法

突然、WordPress.org へのログインができなくなって ??? と思ったのですが、WordPres.org Plugin Directory からのメールをみて納得しました(6月29日に届いていた)。

件名:[WordPress.org] Password Reset Required for Plugin Authors

内容としては、一部のプラグイン作者がパスワードの使いまわしをしていて、そのパスワードが WordPress.org とは異なるサイトで漏洩してしまい、これを悪用されたかで WordPress.org のプラグインディレクトリのいくつかのプラグインに悪意あるコードを追加されてしまった模様という感じですね。

Password Reset Required for Plugin Authors – Make WordPress Plugins

一時的に全プラグインのコミットはチームによる承認制なって対策していたということです。現在は解除されているとのこと。

で、プラグイン作成者とセキュリティ研究者によって漏洩したとおもわれるパスワードを使っていたユーザーについて、WordPress.org へのログインパスワードを無効化(強制リセット)したということです。

プラグイン作成者は、パスワードのリセットが必要になったわけですが、同時に2段階認証を有効にするように推奨しています。というわけで私のパスワードも無効化されていたのでした。

WordPress.org は、2023年5月から2段階認証を導入していた


下記のようにプラグインコミッターは、少なくてもパスワードに20文字以上で、大文字小文字記号を含め、他のサービスで使いまわししないようにとあります。私自身はランダム生成のパスワードをつかっているので、使い回しはありませんが、パスワードは12文字だったので今回20文字以上にしました。

Keeping Your Plugin Committer Accounts Secure – Make WordPress Plugins

プラグインコミッターでなくても、アカウントへの不正アクセスを防ぐためにも2段階認証は有効にしたほうがよいですね! 私もしていたつもりがしていなかったので今回してみました。

STEP 1. Two-Factor App と Two-Factor Backup Codes を有効にしてみる




下記にアクセスします。


Two-Factor Apps


あらかじめ、 スマートフォンに Google Authenticator や Microsoft Authenticator など2段階認証用のアプリをインストールしておきます。そして、Two-Factor App をクリックして、表示されたQRコードを、そのアプリで読み込みます。すると6桁の数字が一定時間ごとに変更されたものが表示されるので、その数字を入力して設定を完了します。

Tw-Factor Backup Codes


ここをクリックすると10個の緊急時用の1度のみ使えるバックアップコードが発行できます。もし2段階認証として使っていた端末やアプリが使えなくなったときにログインできるコードになります。どこかにメモっておきます。

STEP 2. Two-Factor Security Key を有効にする


最近流行りのパスキーです。

パスキーの詳しい話は、Googleの公式ヘルプあたりをチェックするとよいかなと思います。

パスワードの代わりにパスキーでログインする - Google アカウント ヘルプ

こちらは端末ごとに設定しておくことになります。パスキーに対応している端末をお持ちの場合には設定しておくと便利ではあります。

下記の「Register new key」をクリックして、名前をつけて設定します。
macOS をお使いなら、iCloud キーチェーンのほうに保存しておくのがよいでしょう。


設定するとパスキーがメインの認証方法になります。


STEP 3. 実際にログインを試してみる



各ブラウザについてプライベートモード(Cookieとキャッシュを無効化したログインしていない状態)にして、WordPress.org にログインしてみます。

アカウントとパスワードを入力すると、下記のようにパスキーを聞いてきます。
macOSと iPhoneをセットで持っているなら、iCloud キーチェーンで同期しているため、iPhoneのカメラで下記のQRコードを読み取ってアクセス。iPhoneのほうで認証します。iPhoneで顔認証を有効にしていれば、顔認証をすることで認証できることになります。

それができない(オンラインでない)場合には、「キャンセル」ボタンをクリックして、下記のようにエラーがでてきたら「User your authenticator app」を選択して、スマートフォンに設定したはずの認証アプリに表示されている WordPress.org 用の6桁の数字を入力すればよいです。この認証アプリについてはオフラインでの利用が可能です。


2段階認証を有効にしておけば、パスワードが漏洩したとしてもログインされることはなくなります。特にパスワードの使い回しをすると、他の脆弱なサイトで漏洩する危険性があるので、そうしないように気をつけないといけませんね

なおパスワードを考えつかない!という場合には、パスワード生成してくれるサイトは検索すればいろいろでてきます。そうしたものを活用してパスワードをランダム生成して、それをブラウザのパスワードマネージャーに保存する、メモするなどをしておくとよいかと思います。

2024年7月3日 @kimipooh

2024年6月21日金曜日

【備忘録】APCu の object caching が原因で WP-CLI の wp plugin list でプラグインの更新状況が確認できない場合の対処

PHP を利用したページ表示を高速化する APCu キャッシュを WordPress で有効化すると、かなりサイトの表示速度を向上することができます。利用するためには、PHP で APCu が有効になっている必要があります。たとえば、さくらインターネットやエックスサーバーなどのレンタルサーバーでは、標準で有効となっています。

WordPress でも手動の場合には、下記の方法もありますが、

何らかのプラグインを使っていることも多いはず。

以前は、WP-FFPCプラグインを使っていて、長期メンテナンスされておらず PHP8.0に非対応だったので対応させたりしてましたが、手動でやるのは限界があります。したがって、最近は APCu Manager プラグインを使っています。

 

WP-CLI の wp plugin list で更新が出てこない問題


下記のように、backwpup プラグインは 4.1.1 が最新であり、WordPress の管理画面にログインするとプラグイン更新画面には出てくるのに、WP-CLIでの update_version には出て来ない場合があります。 このことはずっと原因がわからなくて、ようやく「wp plugin list stopped working [with W3 Total Cache object caching] #1047」の情報にたどり着いたのでした。2014年からこの問題はあったのですねぇ。なおこの問題が起こった場合、WordPress 管理画面から設定するプラグイン自動アップデートも機能しませんでした。あくまで更新ボタンを押して手動で更新しなければ、更新できない問題があったということです。


% wp plugin list
+------------------+----------+--------+----------+-------------------+-------------+
| name             | status   | update | version  | update_version    | auto_update |
+------------------+----------+--------+----------+-------------------+-------------+
| apcu-manager     | active   | none   | 4.0.0    |                   | off         |
...
| backwpup         | active   | none   | 4.1.0    |                   | off         |
...
| object-cache.php | dropin   | none   |          |                   | off         |
+------------------+----------+--------+----------+-------------------+-------------+

このケースにおいては、APCu のキャッシュ機能を有効にしていた場合には無効にして試してみてください。下記のように更新がでてくれば、このキャッシュ機能と WP-CLI問題だということになります。

% wp plugin list
+------------------+----------+--------+----------+-------------------+-------------+
| name             | status   | update | version  | update_version    | auto_update |
+------------------+----------+--------+----------+-------------------+-------------+
| apcu-manager     | active   | none   | 4.0.0    |                   | off         |
...
| backwpup         | active   | none   | 4.1.0    |     4.1.1              | off         |
...
| object-cache.php | dropin   | none   |          |                   | off         |
+------------------+----------+--------+----------+-------------------+-------------+

対応方法


そもそも、WP-CLIをつかうのは、プラグイン更新を自動化したい目的もあるはず( wp plugin update --all など)。となると、下記の一連の操作をしたいと思うはず!
  1. APCu の object caching を一時的に無効にして
  2. WP-CLI によるプラグインを更新して
  3. APCu の object caching を有効化
APCu Manager プラグイン は WP-CLI による制御が可能ため、このプラグインをつかうことで、うまくいきました。
  1. wp apcu settings disable object-caching --yes
  2. wp plugin update --all
  3. wp apcu settings enable object-caching

APCu Manager プラグイン の状況は、
wp apcu status 
コマンドでわかります。

2024年6月21日 @kimipooh

2024年4月26日金曜日

Studio by WordPress.com - オープンソースの WordPress ローカル開発環境を試してみた!(なかなかよさそう)

Xのようで情報が流れてきたので試してみました。ローカル環境系はいろいろありますが、ネット上でサイトを一時的にシャアできる機能が無料で使えるのは重宝しそうです。ただし、Apacheなどは使われていないということ、シャアしたサイトは静的HTML化されているのか、あるいは制限されているようにみえるので、.htaccess によるパスワードロックも使えませんでした(test.php などをアップして、PHPコードを含むサイトを表示させようとしても表示できなかった)。また、HTTP Auth プラグインについても設定を保存できないなど使えませんでした。そのため、秘匿性の高いサイトでのシャアは現時点では使えないかもしれません(まだ私がやり方をしらないだけの可能性もあり)。

下記が公式アナウンスになります。

Studio by WordPress.com: 無料でオープンソースの WordPress ローカル開発環境 – WordPress.com 日本語ブログ
https://wordpress.com/ja/blog/2024/04/26/studio/

さて実際にインストールしてみましょう。


STEP 1. ダウンロードとインストール


ダウンロードサイト:https://developer.wordpress.com/studio/

2024年4月26日時点では Mac( macOS )のみの対応です。

ダウンロードしたファイルを開いて出てきた Studio アプリを、アプリケーションフォルダに移動してください。


シャア機能をつかうには、 WordPress.com のアカウント(無料でOK)が必要です。せっかくなのでもっていなければ下記を参考に作成しておくことをオススメします。

WordPress.org アカウントの作成とログイン – サポートフォーラム
https://ja.wordpress.org/support/article/wordpress-org-account/


STEP 2. サイトを作成する


Studio アプリを開くと、最初のサイト作成画面になります。
このアプリが保存する WordPress は、$HOME/Studio(Macintosh HD > ユーザー > ユーザー名 > Studio)フォルダに保存されます。下記では wordpress フォルダに保存されます。

すると下記の画面になり、こちらからサイトや管理画面、その他テーマのカスタマイズへ直接アクセスすることができます。「実行中」をクリックすると「開始」ボタンに変更されて、システムが停止します。「開始」ボタンを押すと「実行中」になります。アプリを終了すると、自動的にシステムは停止するようで、次回アプリを起動すると「開始」ボタンがでてくるので開始をクリックしてサイトにアクセスできるようにしてください。

下記にあるように、設定から具体的なローカルサイトへのアクセスURLなどがわかります。localhost:8881 のようですね。


STEP 3. サイトを共有(シェア)してみよう!


シェアより、WordPress.com にログインします。アカウントを作っていないなら作ってからログインしましょう。


最初の1度のみ、下記のようにアプリが WordPress.com にアクセスするための許可を求めてきますので、Approve ボタンをクリックして許可します。



すると下記のようにサイトの作成が始まります。
うまく作成できれば、下記のようにデモサイトのURLが表示されます。ドメイン wp.build のサブドメインが付与(ランダム生成にみえる)されます。7日間保持されるようですね。なお「デモサイトを削除」すると、実際に消えるまで5分ぐらいかかる(即時消えるわけではない)ようです。

またサイト更新は、「デモサイトを更新」から更新します。こちらも即時更新ではなく、しばらくまったら更新されているという感じでした。





付録. Studio アプリが利用している PHP やデータベースの種類は?


2024年4月26日時点では、PHP のバージョンは 8.0.30-dev でした。


データベースについては、 SQLite を使っていました。下記の右上に「Database: SQLite」と書かれています。




私自身は試したことがないのですが、下記などをみると SQLite を WordPress のデータベースとして使うように構築できるようですね!

WordPressをSQLiteで動かす方法|さくらサーバーライトでWordPressを動かす | 【2024年】おすすめアフィリエイトASP選び方!ブログ初心者おすすめ

2024年4月26日 @kimipooh

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