サイト全体が 500 エラーで開かなくなったら、直す前に、どのアドレスが開いて、どれが 500 になるかを外から確かめます。製造業のお客様のサイトでは、置いてあるだけのファイルは開き、WordPress を通るページはすべて 500 でした。原因は、サーバーの PHP が 8.4 で動いているのに、WordPress の本体が何年も前の版のままだったことです。
このサイトは、当社が普段から保守しているサイトではありません。至急の対応として、その日のうちに原因を絞り込み、直す順番を文書にしました。以下は、その日に確かめた順です。
置いてあるだけのファイルは開き、WordPress を通るページはすべて 500 でした
最初に、いくつかのアドレスを外から開いて、返ってくる番号（HTTP ステータスコード）を見ました。
| 開いたアドレス | 返ってきたもの |
|---|---|
| トップページ | 500。中身は空 |
| 会社案内やお問い合わせなどのページ | 500 |
| index.html | 500 |
| サイトマップ（sitemap.xml） | 500 |
| robots.txt | 200。正しく開いた |
robots.txt が開いたので、サーバーそのものは動いていると分かりました。500 は、サーバーの中で処理が失敗したことを表す番号です。中身が空で、エラーの案内のページも出ません。ページを組み立てるプログラム（PHP と WordPress）のところで止まっている、と見当を付けました。
疑ったのは 5 つで、どれかは記録を見ないと決まりませんでした
| 疑ったこと | どうすれば決まるか |
|---|---|
| PHP のプログラムが途中で止まっている（本体・プラグイン・テーマ、PHP の版を変えたあとの食い違いなど） | エラーの記録（ログ）を見る |
| データベースにつながらない | データベースが動いているか、設定が変わっていないかを見る |
| .htaccess の書き間違い | 最近書き換えていないかを聞く |
| 保存の容量やメモリの上限に達した | 使っている量を、サーバーの管理画面で見る |
| サーバーの側の守りの仕組みが、普通の通信まで止めている | サーバーを管理する会社に聞く |
どれなのかは、エラーの記録を見れば決まります。ところが、このサイトのサーバーは別の会社が管理していて、当社からは記録を見られませんでした。そこで、記録にたどり着く手段を挙げました。
- サーバーを管理する会社に、エラーの記録を見てもらう
- お客様の側にサーバーへ入る手段があれば、それを使わせていただく
- 直前に何かを変えていないか（プラグインの更新や PHP の版の変更など）を伺う
結果として、サーバーにファイルを置くための接続（FTP）で入れるようになりました。中を見ると WordPress のサイトで、PHP は 8.4 で動いていました。
WordPress の記録を一時的に出して、止まっている 1 行を見つけました
WordPress には、PHP のエラーを画面やファイルに出す設定（WP_DEBUG）があります。設定のファイル（wp-config.php）で一時的に有効にすると、次のエラーが出ました。
__autoload() is no longer supported, use spl_autoload_register() instead
出ていた場所は、WordPress 本体の wp-includes/compat.php という、古い環境との互換のためのファイルです。PHP の公式の移行の手引きによると、PHP 8.0 から、__autoload() という関数でプログラムの読み込み方を決めるやり方は削除されています。古い版の WordPress の本体には、この名前の関数を書いた行が残っていました。PHP 8 の環境では、その行で処理が止まります。WordPress のどのページもこのファイルを読み込むので、ページを組み立てる前に止まり、500 が返っていました。
この設定は、本番のサイトで使い続けるものではありません。WordPress の公式の文書も、本番のサイトで WP_DEBUG などを使うことは勧めておらず、記録をファイル（wp-content/debug.log）に出して画面には出さない設定の例を載せています。画面に出したままにすると、エラーの文面に含まれるサーバーの中のフォルダの場所まで、訪れた人に見えてしまいます。原因が分かったら元に戻します。
直す順番は、PHP を一時的に戻し、WordPress を上げてから、PHP を上げ直す、としました
- PHP を一時的に戻すサーバーの管理画面で、古いコードが止まらない版に切り替える。ファイルには触らない
- まるごと控えるデータベースと wp-content のフォルダと wp-config.php を写す
- WordPress を上げる本体を新しい版に入れ替え、テーマとプラグインを 1 つずつ上げて表示を見る
- PHP を上げ直す8.4 に戻し、トップページ・お問い合わせ・管理画面のログインを開く
PHP を戻せないときは、8.4 のまま本体のファイルだけを入れ替える案を、次の手として決めておきました。
最初に PHP を戻すのは、管理画面で版を切り替えるだけで済み、ファイルに触らないからです。サイトを表示に戻すまでの手数が、いちばん少なくなります。
ただし、戻す先の古い PHP は、公式のサポートがすでに終わっています。PHP 7.4 なら、2022 年 11 月 28 日に終わりました。戻すのは WordPress を上げ終わるまでのあいだだけ、と決めてから切り替えます。
WordPress を上げる前には、データベース、記事や画像が入った wp-content のフォルダ、設定のファイル（wp-config.php）をまるごと控えます。本体を入れ替えるときに触るのは、wp-admin と wp-includes のフォルダと、いちばん上の階層にある本体のファイルだけです。wp-content と wp-config.php は、そのまま残します。テーマとプラグインは、1 つずつ有効にして、そのたびに表示を確かめます。エラーが出たものは、いったん止めて原因を分けます。
PHP の版と WordPress の版には、組み合わせの決まりがあります。WordPress の公式の対応表では、PHP 8.4 に対応しているのは WordPress 6.7 からです。上げ直す前に、上げた後の WordPress がこの表で 8.4 に対応しているかを見ます。
PHP を戻せないときの次の手も決めておきました。PHP 8.4 のまま、本体のファイルだけを公式の最新版に入れ替える方法です。古いテーマやプラグインで別のエラーが出ることを見込んで、出たものは止めて、新しい版か代わりのものに替えます。
作業は、サーバーを管理する会社の技術の方に、文書で頼みました
当社はこのサーバーに自分で手を入れる立場ではありません。起きていること、分かった原因、直す順番と次の手、作業の前に控えるものを 1 つの文書にまとめ、その日のうちに、サーバーを管理する会社の技術の方に向けて出しました。
文書の最後には、PHP を一時的に戻せるかどうかを先に答えてほしい、と書いています。戻せるかどうかで、そのあとの手順がまるごと変わるからです。もう 1 つ書き添えたのは、直ったあとのことです。何年も更新されていなかったサイトなので、テーマとプラグインを棚卸しして、更新を続ける運用を見直すよう勧めました。
同じ止まり方を防ぐには、PHP の版と WordPress の版を並べて控えます
サーバーの PHP が新しい版で動いていて、WordPress が古い版のままだと、ある日すべてのページが開かなくなることがあります。毎月の保守で WordPress と PHP の版を控えていれば、PHP を上げる前に、WordPress がその版に対応しているかを表で確かめられます。当社が毎月の保守で控えている本体とプラグインの版の一覧は WordPress の毎月の保守の記事 に、5 年近く止まっていたサイトの版を上げた記録は 古い WordPress を上げた記事 に書いています。
見覚えのない管理者が増えているなど、不正なアクセスが疑われるときは、残すものと順番が変わります。その場合の手順は 改ざんに気づいたら最初の 1 時間でやること にまとめ、調べて入口をふさぐ作業は WordPress の被害復旧 としてお受けしています。
