本業の案件で、客先サーバーのWordPress本体を5系から7系にアップデートすることになったときの話です。
単純に管理画面から本体を上げるだけの作業だと思っていたら、想像よりずっと長い連鎖トラブルになりました。
まずはWordPress本体を更新、そしたら真っ白
管理画面から「今すぐ更新」をクリックして、WordPress本体を最新版に更新しました。
作業自体は数分で完了。
ところが、フロント画面を開いてみると何も表示されません。
いわゆる「真っ白な画面」、致命的エラーの状態です。
管理画面にログインし直そうとしても、そちらも同じく真っ白でした。
白い画面。
血の気が引きました。
エラーログを確認すると、サーバー側のPHPバージョンが古すぎて、新しいWordPressが要求するバージョンを満たしていないことが原因でした。
サーバーのコントロールパネルにログインしてPHPのバージョン設定を確認したところ、案の定、何年も前のバージョンのまま放置されていました。
💡 Tips: 白い画面(致命的エラー)とは
PHPの実行中に回復不能なエラーが起きると、WordPressは画面に何も表示できず、真っ白なページだけが残ることがあります。原因はさまざまですが、プラグインやテーマが要求するPHPバージョンと、実際のサーバーのPHPバージョンが噛み合っていないケースがよくあります。
PHPを上げたら、今度はプラグインが古かった
サーバー管理画面からPHPのバージョンを上げて、ひとまずWordPress本体は動くようになりました。
直った、と思ったのも束の間。
今度は別のところで真っ白な画面が復活しました。
今度は管理画面の一部のメニューだけが表示されないという、少し違う症状です。
調べてみると、一部のプラグインが古いPHPバージョン向けに作られたままで、新しいPHPとの互換性が無かったことが原因でした。
また真っ白。
プラグイン一覧を1つずつ確認し、更新が止まっているものや、対応PHPバージョンの記載が古いものを洗い出していきました。
特に業務系の複雑な機能を持つプラグインほど、更新が止まっている確率が高い印象でした。
プラグインもまとめてアップデート
該当のプラグインを最新版に更新したところ、ようやく管理画面もサイトの表示も正常に戻りました。
やっと出た。
振り返ってみると、「本体を上げる→PHPが足りない→PHPを上げる→今度はプラグインが古い→プラグインを上げる」という具合に、1つ直すたびに次の問題が顔を出す展開でした。
作業時間そのものより、その都度クライアントに状況を報告し続ける精神的な負担の方が大きかった気がします。
なんで最初から全部まとめて確認しなかったの?
それが理想なんだけど、WordPress本体・PHP・プラグイン、それぞれの動作要件を全部事前に洗い出すのって、実際やってみると地味に手間なんだよね。
だから1個ずつ動かしながら直していくことになったんだ。
結果的にはそうなった。次からはアップデート前にバックアップを取った上で、要件を一通り確認してから進めるようにしてる。
ステージング環境がなかった
今回一番きつかったのは、検証用のステージング環境が用意されていなかったことです。
つまり、更新作業はすべて本番サーバー、実際にお客様が見ているサイトの上で行うしかありませんでした。
「まず検証環境で試してから本番に反映する」という手順が取れないと、1回1回の作業の緊張感がまるで違います。
PHPのバージョンを上げる瞬間も、プラグインを更新する瞬間も、「これで本当に大丈夫か」と手が止まりました。
それでも、直った。
結果的には無事に直せましたが、検証環境がない状態での更新作業は、想像以上に神経を使うものだと痛感しました。
連鎖トラブルは珍しくない
WordPress・PHP・プラグインは、それぞれ別々の開発元が別々のタイミングで更新していくものです。
だから、どれか1つだけを新しくすると、他との組み合わせで新しい不整合が生まれることがあります。
今回のように「直したら次の層で問題が出る」という連鎖は、更新作業では割とよくあるパターンだと感じています。
怖いのは、これ。
連鎖は、続く。
1つのエラーを直して満足せず、「まだ他に噛み合っていない箇所がないか」を意識しておくと、次のトラブルにも慌てずに対応できると思います。
まとめ
結局、3段階。
WordPress本体のメジャーアップデートは、本体だけでなくPHPバージョン・プラグインの互換性まで含めた「3点セット」で考える必要がある、というのが今回の教訓でした。
特に客先の本番サーバーは自分の管理下に無いことも多く、PHPバージョンの現状把握を事前にしておく重要性を実感した出来事でした。
バックアップも取らずに本体だけ上げてしまっていたら、と考えると今でも少し肝が冷えます。
今後は本体を更新する前に、まずバックアップを取り、PHP・プラグインの動作要件を確認する手順を先に踏むようにしています。
地味な手順ですが、この一手間を惜しまないことが、結局は一番の近道だと思います。
特にステージング環境が用意されていない案件では、この「事前確認」の重みが普段以上に増すということも、今回身をもって学びました。
それ以来、新しい案件に入るときは、検証環境の有無を最初に確認する項目として習慣づけるようになりました。
この記事が参考になったら、応援クリックをお願いします
