PHPバージョンを上げたらブログ別館が表示不可に。過去のChatGPTログとAIとの切り分けで復旧できた件
今回のPHP脆弱性騒動で、この際私の管理するドメインすべてのPHPバージョンを8.3.36にしようと決めました。早速作業に取り掛かったところ1分で問題発生しました。
ブログ別館のPHPのバージョンを 8.3.36 に上げたら、サイトが表示されなくなりました。対象は uma2x.com。
https://uma2x.com/まあ、8年ほど放置しているブログなのですべてが古いです。
これから更新するかどうかもわからないので、いっそ消してしまうのも手ではあったんですが、過去投稿なども残っているので忍びなくて残す方向でやってみることにしました。
で、問題なのですが、PHP 8.3.36で動かしたいのに、返ってくるのはHTTP 500です。早速 AI に相談してみることにします。
そこでAIに画面を見せながら、ひとつずつ確認していくことにしました。途中で役立ったのが、以前にもChatGPTと相談して解決していたときの会話ログ。そして今回は、それだけでは終わらなかったんですよね。
認証の問題を越えたら更新ができず、更新できたと思ったらまだ表示されない。最後にはプレビューが真っ白なのに、実際のサイトは表示できるという展開までありました。
後のための備忘録として記録しておこうと思いましたので記事化しました。
最初の手がかりは、以前のChatGPTとの会話にあった
AIは最初、古いWordPressやテーマ、プラグインと新しいPHPの組み合わせを疑い、いったんPHPを元に戻すよう提案しました。でも、こちらには覚えがありました。
以前も、PHPを上げたらWordPressがデータベースへ接続できなくなり、ChatGPTと相談して直したことがあったんです。そのとき何をしたのか、もう一度確認したい。
解決した時期を知りたくてFacebookの投稿を探すと、「旧形式の認証ハッシュ」という言葉が出てきました。それをChatGPT内で検索したところ、アーカイブ済みの会話が見つかりました。
過去ログに残っていた原因は、MySQLというデータベースに保存された「旧形式の認証ハッシュ」でした。
簡単にいうと、パスワードを確認する仕組みが古く、新しいPHPでは接続できなくなっていたんですね。そこで、以前はMySQLのパスワードを再設定し、WordPress側の設定も合わせたところ、PHP 8.3.30でも動くようになっていました。という話です。
それなら今回も、まずは同じ方法を試してみよう。ただし、同じMySQLユーザーをほかのサイトでも使っていると、そちらにも影響するため、対象を確認してから進めます。
パスワードを再設定しても、PHP 8.3ではまだ動かない
過去ログを手がかりに、今回は別館でパスワード等を再設定しました。
まずPHP 7.3.33まで表示を確認し、その後、7.4.33でも表示できた画面をAIに見せています。これは以前認証問題が出た際の PHPバージョンの動作可否の境界線が 7.3.33と7.4.33の間にあったので、それを越えたということを意味しています。
AIは認証の問題を越えたと受け取り、次は8.3.36へ進めると判断しました。ところが、実際の結果は違いました。
過去ログは役に立った。でも、以前の成功例が今回の環境でそのまま最後まで通るとは限らない。表示できる段階は進んだものの、PHP 8.3で動かすには別の問題も見ていく必要がありました。
更新しようとしたら、更新のための通信が通らない
管理画面に入ると、使っていないプラグインやテーマがいろいろ残っていました。整理して、必要なものを更新していこうとしたところ、今度は別のエラーです。
表示されていたのは cURL error 60。AIは、ダウンロード先の証明書を確認するためのファイルが古い可能性を挙げました。
WordPressのHTTP通信では、証明書検証に使うファイルとして wp-includes/certificates/ca-bundle.crt が指定されています。WordPress公式のHTTP通信リファレンスにも、この設定が載っています。
https://developer.wordpress.org/reference/classes/wp_http/re...本館のdonpy.netでは更新できるか確認すると、そちらは通りました。同じようにすべてが止まっている状況ではなかったわけです。（今日はPHP騒動もあってサーバー自体がなにか止めてる可能性もあることも考慮に入れる必要があった）
そこでAIが提案したのは、別館の既存ファイルを別名で残したうえで、正常に更新できている本館の ca-bundle.crt を使う方法でした。
差し替えて、テーマのインストールを試し直します。
これで更新を進められるようになりました。証明書の検証そのものを無効にするのではなく、検証に使うファイルを差し替えた結果です。
では、PHP 8.3もこれでいけるかというと。
直ったのはダウンロードの問題。PHPを上げたときの500エラーは残っていました。ひとつ解決したから全部解決、とはいかないですね。
PHPを上げたいのに、先にPHPを上げないと更新できない
WordPress本体の更新もして 7.1.3 にしました。
しかし、残ったプラグインには現在のPHPでは更新できないものがありました。
新しいPHPで動かすためにプラグインを更新したいのに、その更新をするには新しいPHPが必要。このままではぐるぐるです。
AIから返ってきたのは、動かすものをいったん減らす案でした。
念のためプラグインはすべて無効化
テーマを先ほど入れた標準テーマへ一時変更
PHPを8.3.36へ変更
サイトと管理画面が開くか確認
プラグインを1個ずつ有効化
最後にLuxeritasへ戻す
まず標準テーマとプラグイン停止の状態で表示できるか。そのあと、機能をひとつずつ戻して確かめるという順番です。
標準テーマで突破に成功！
プラグインをすべて停止し、標準テーマへ切り替えることにします。テーマ一覧を開くと、数が増えていました。
今回の検証に選んだのはTwenty Twenty-Five。切り替えると、サイトは表示されました。ただ、見た目がずいぶん違う。
ここではデザインを仕上げることより、PHPを上げても動く構成を見つけることが先です。この状態で、もう一度PHP 8.3.36へ変更します。
ようやく通りました！！！ほぼ丸裸の WordPress ですので通ってくれないと逆に困るわけですが、それでもちょっとホッとしました。
更新できなかったプラグインも、この状態なら更新へ進めます。
続いて、WP Multibyte Patch、Akismet、All in One SEO、Contact Form 7、WP-PostViewsをひとつずつ有効化して、その都度表示を確認。XML Sitemap Generatorは停止したままです。
今回確認した範囲では、更新後のプラグインを戻しても表示できました。そこで次は、元のテーマであるLuxeritasを調べることになります。だんだんと犯人が絞り込まれていく様はなにかの推理ドラマを見ているかのようでした。
親テーマは表示できた。でも子テーマのプレビューが真っ白
テーマ詳細を見せると、AIが読み取った親テーマのバージョンはLuxeritas 3.5.7でした。最新のバージョンと比較するとかなり古いバージョンのようでしたので、親子を一度に入れ替えず、まず親だけ更新して確認する方針としました。
親テーマの更新先は3.25.0。
Luxeritas公式の配布ページから取得する案内でした。同ページにはAll in One SEOとの併用を勧めない説明もあり、AIはテーマを戻す前にそちらを停止するよう付け加えています。その通りにして親テーマを更新して、単独で有効化しました。
今度は元のテーマでも表示できました。次に子テーマをライブプレビューしてみますと、、、
ここでまた真っ白です。
ただし、サイト本体は親テーマのまま表示できていました。
AIは子テーマ内の古いコードを疑い、functions.php の名前を一時的に変えてプレビューを確認する案を出しました。しかし、結果は変わらず「真っ白です」。ファイル名を元に戻すよう案内され、今度は子テーマのファイル一覧を見せます。
AIはその一覧を2019年の古い子テーマ一式と読み取り、古いフォルダを luxech_backup_2019 として残してから、新しい子テーマを入れる方法を提案しました。
新しい子テーマはLuxeritas Child 3.0.4。アップロードすれば今度こそ、と思うところですが、プレビューはまだ表示されません。
ふーむ。どうしたものか。
プレビューと、実際に有効化した表示は違っていた
自分では手詰まり感もあったのですが、新しい子テーマでも同じ結果だったため、AIの見立ても変わりました。子テーマの内容だけでなく、ライブプレビュー側の問題かもしれない、と。
次は直接有効化して試してよい段階です。ただし、すぐ戻せるようにXServerのファイルマネージャーを開いたままにします。
このときは、親テーマなら表示できることを確認済みでした。さらに、もし有効化後に表示できなくなったら、新しい子テーマのフォルダ名を変え、親テーマへ戻すという復帰の段取りも案内されています。
そのうえで新しい子テーマを有効化し、実際のサイトを確認しました。
出ました！ プレビューでは真っ白だったのに、実際に有効化すると表示されたんです。やってみるもんだ。
ここは、途中のAIの「子テーマ側に問題があります」という判断だけで終わらせてはいけないところでした。今回の結果からは、プレビューが白いことだけでは子テーマの故障と決められません。何のコードが500エラーを出していたか、プレビュー側で何が起きていたかまでは、結局まだ調べてませんので今後の課題ということにしたいと思います。
また、公式配布ページには既存ユーザーの子テーマ更新は不要との説明があります。今回の入れ替えは、この別館で行った切り分けの経過です。古い子テーマを消さずに残したのは、独自の設定やCSSをあとから確認できるようにするためでした。
最後は、表示されたことだけで終わらずに確認
AIから最後に確認するよう言われたのは、トップページ、個別記事、お問い合わせ、管理画面、スマホ表示でした。ひとつずつ確認して、表示されるのを見て結構な安心感がありました。
これで別館の復旧までたどり着きました。会話の最後に整理された構成は、PHP 8.3.36、WordPress 7.1.3、Luxeritas 3.25.0、Luxeritas Child 3.0.4。必要なプラグインも更新を進め、表示を確認した状態です。
途中には、認証の見直し、証明書ファイルの差し替え、WordPressとプラグインの更新、標準テーマでの検証、親子テーマの確認がありました。最後のテーマだけ直せばよかった、という一本の話ではなかったんですよね。以前に似たような不具合をやったときの復習にもなりましたので勉強になりましたね。
そして今回、最初の手がかりをくれたのは過去の自分とAIの会話でした。
「旧形式の認証ハッシュ」という言葉を残していたから、前のやり取りに戻れた。
今回も、直ったという結果だけでなく、どこでつまずいて、何を見て次へ進んだのかまで残しておきます。次に困ったときの検索語は、今はまだわからないですからね。
ChatGPT の過去のチャットログはアーカイブにしていても全文検索が効くようです。それが今回大きな解決の鍵となってくれました。今はそういう問題解決の経緯はできるだけログ化して残すようにしてます。また未来の自分の問題解決のヒントになってくれればというタイムカプセル的な仕込みって感じで。
まあとにかく、今回のPHP騒動のおかげというと言葉が悪いかもしれませんが、きっかけにはなったと思います。結局自分の管理する4ドメインについてひとつずつ PHPバージョンを 8.3.36 にあげることができました。
ここ最近セキュリティに関するさまざまな問題がどんどん出てきているので、これであとはずっと安心というわけにはいきません。ブログの保守はもう自分の趣味の一環としてネタとしてこれからも育てていきたいと思ってます。
ではまた。
ディスカッション
コメント一覧
まだ、コメントがありません