トラブル記事を読み返して気づいたこと

このブログには、WordPressのトラブルについて書いた記事がたくさんあります。
「画面が白くなった」「403エラーが出た」「ログインできなくなった」「PHPを上げたら警告が出た」……。どれも、そのとき実際に困って、解決したあとに自分用の備忘録として書いたものです。

先日、15年分の過去記事を棚卸しする機会があり、こうしたトラブル記事をまとめて読み返しました。すると、症状はバラバラなのに、原因の探し方にはだいたい決まった順番があることに気づきました。

今日は、60代になった今の私が「WordPressが動かなくなったら、まずこの順番で見る」と考えている5つの確認ポイントを、過去の失敗談と一緒に紹介します。専門用語はなるべく噛み砕いて書きますので、WordPressを使い始めたばかりの方も参考にしてみてください。

確認①：直前に「何を変えたか」を思い出す

いちばん大事なのは、これです。
WordPressは、何も触っていないのに突然壊れる、ということは意外と少なく、たいていは直前に何かを変えています。

過去の私のトラブルを並べてみると、よく分かります。

• プラグインを入れた直後に、ログインできなくなった（reCAPTCHA、つまり不正ログイン対策のプラグインを導入したとき）
• PHPのバージョンを上げた直後に、画面に「Warning」という警告が出るようになった
• WordPress本体が5.x系に上がった頃に、投稿の新規追加画面が真っ白になった

どれも「その前に何をしたか」が分かれば、原因の候補をぐっと絞れます。
自分で作業していなくても、サーバー会社がPHPのバージョンを切り替えたり、WordPressやプラグインが自動更新されたりしていることもあります。「最後に正常だったのはいつか」「その後に何が変わったか」を、まずメモに書き出すのがおすすめです。

確認②：エラーメッセージを「ちゃんと読む」

次は、画面に出ている文字を落ち着いて読むことです。英語のメッセージが出ると、つい慌てて閉じたくなりますが、実はいちばんのヒントが書いてあります。

「Warning」が出ている場合

2020年に、PHPのバージョンを上げたら次のような警告が出たことがありました。

Warning: Use of undefined constant ture - assumed 'ture' ... in functions.php on line 103

一見むずかしそうですが、よく読むと「functions.php の103行目」と、問題の場所がはっきり書いてあります。当時は該当箇所を書き直して警告を消しましたが、今あらためて読むと、メッセージの「ture」は「true」の書き間違いだったようです。古いPHPでは見逃されていた小さなミスが、新しいPHPで表に出てきた、というわけです。メッセージを1文字ずつ読むことの大切さを、今になって教えられました。

「403 Forbidden」が出ている場合

403は「アクセスが禁止されています」という意味です。サイトが壊れたというより、どこかの設定で門が閉じられている状態です。この場合は確認④を見てください。

画面が真っ白で何も出ない場合

いちばん困るのがこれです。2019年に、新規投稿の画面が真っ白になったときは、プラグインの更新やデータベースの更新を試したあと、「Classic Editor」というプラグインを入れて解決しました。

ただ、当時の記事にも書いたとおり、本当はデバッグ表示を有効にして原因を確かめるべきでした。WordPressの設定ファイル（wp-config.php）には、エラーを表示・記録するための設定があります。

• define( 'WP_DEBUG', true ); … エラーを出すようにする
• define( 'WP_DEBUG_LOG', true ); … エラーをファイル（wp-content/debug.log）に記録する
• define( 'WP_DEBUG_DISPLAY', false ); … 訪問者の画面には表示しない

公開中のサイトでは、画面にエラーを出すと見た目もセキュリティもよくないので、ログに記録して、画面には出さない設定がおすすめです。調べ終わったら、元に戻すのを忘れないようにしましょう。

なお、最近のWordPressには、重大なエラーが起きると管理者のメールアドレスに通知を送る「リカバリーモード」という仕組みもあります。サイトの管理者メールに届いていないか、確認してみてください。

確認③：管理画面に入れるかどうかで、やり方を分ける

管理画面（ダッシュボード）に入れるなら、プラグインの無効化やテーマの切り替えは画面上でできます。
問題は、管理画面に入れないときです。

2021年、不正ログイン対策のプラグインを入れたところ不具合が起き、ログインできなくなりました。管理画面に入れないので、原因のプラグインを止めることもできません。

このときは、サーバーの管理ツール「phpMyAdmin」でデータベースを開き、wp_options というテーブルの active_plugins（有効なプラグインの一覧）を編集して、ログインできる状態に戻しました。
ただ、この方法は消す範囲を間違えるとかえって大変なことになるので、データベースに慣れていない方にはおすすめしにくい方法です。実際、このときは結果的にプラグインがすべて無効になってしまい、ログイン後に1つずつ有効化し直しました。

初心者の方なら、まずは FTPでプラグインのフォルダ名を変える方法を試すほうが安全です。たとえば wp-content/plugins/問題のプラグイン のフォルダ名を、末尾に「_off」を付けるなどして変えると、WordPressはそのプラグインを読み込めなくなり、止まります。どれが原因か分からないときは、plugins フォルダごと名前を変えて、全部まとめて止めてみる手もあります。

ちなみにFTPといえば、日本語のファイル名が付いた画像がどうしても消せない、ということもありました。そのときは、削除用の小さなPHPファイルをアップロードして消しました。サーバー上のファイルは、パソコンのファイルと同じ感覚では扱えないことがある、と覚えておくと慌てずに済みます。

確認④：自分でかけた「制限」を疑う

意外と見落としがちなのが、自分で設定した防犯対策が、自分を締め出しているケースです。

2019年に、ログインページを開くと「403 Forbidden」になったことがありました。原因は、不正ログインを防ぐために、管理画面への海外からのアクセスを制限していたことでした。この制限が、正しい利用者のログインまで止めてしまっていたのです。

このときは .htaccess（サーバーの動きを決める設定ファイル）に、ログインページへの送信を許可する設定を書き足して解決しました。ただし、制限をゆるめれば、その分だけ不正ログインのリスクは上がります。ですから、reCAPTCHAなどのログイン対策のプラグインと組み合わせて使うようにしました。

セキュリティの設定は「かけたことを忘れる」のがいちばん怖いところです。サーバーのコントロールパネルの「海外アクセス制限」や「WAF（不正アクセスを防ぐ仕組み）」も、403の原因になることがあります。いつ、何を設定したかを、どこかにメモしておくと助かります。【要確認：現在、設定変更の記録をどう残しているか】

確認⑤：触る前に「戻せる状態」を作る

最後は、確認というより心構えです。
原因が分かって直そうとするとき、ファイルやデータベースを書き換えることになります。そのとき元に戻せる状態を作っておかないと、直すつもりが、もっと壊してしまうことがあります。

• 書き換えるファイルは、先にパソコンへコピーしておく（functions.php、wp-config.php、.htaccess など）
• データベースを触るときは、先にエクスポート（書き出し）しておく
• PHPのバージョンを上げるときは、元のバージョンにすぐ戻せるか確認しておく

PHPの切り替えは、多くのレンタルサーバーでコントロールパネルから数分でできます。私も、古いECサイトを新しいサーバーへ移す際に、PHPのバージョンを合わせるために切り替えたことがありました。手軽な分、上げたあとに不具合が出たら「いったん戻して、落ち着いて原因を探す」という選択肢を持っておくと安心です。

私自身、若い頃は勢いで直しにかかることもありましたが、今は「まずコピーを取る」が習慣になりました。【要確認：現在のバックアップの方法・頻度（プラグイン利用か手動か、など）】

60代になって思う、備忘録を書く意味

読み返してみて、少しおかしかったのは、当時の私が何度も「備忘録として書いておきます」と書いていたことです。
正直、そのときは「また同じことが起きたときのために」くらいの気持ちでした。【要確認】

でも今回、まとめて読み返したことで、個々の解決方法よりも「どういう順番で考えればいいか」という、もう一段上の教訓が見えてきました。記憶力に自信がなくなってくる年齢だからこそ、書き残しておいた記録が、今の自分を助けてくれていると感じます。

トラブルに遭ったら、解決したあとに数行でいいので「何が起きて、何をしたら直ったか」をメモしておくことをおすすめします。ブログでなくても、ノートやパソコンのメモ帳で十分です。数年後のあなたが、きっと助かります。

まとめ

WordPressが動かなくなったときは、次の順番で確認すると、原因にたどり着きやすくなります。

1. 直前に何を変えたか（プラグイン、PHP、WordPress本体、自動更新）を書き出す
2. エラーメッセージを読む（ファイル名・行番号がヒント。真っ白ならデバッグログを使う）
3. 管理画面に入れるかで、やり方を分ける（入れないならFTPでプラグインのフォルダ名を変える）
4. 自分でかけた制限を疑う（403なら、アクセス制限やWAFを確認）
5. 触る前に戻せる状態を作る（ファイルのコピー、データベースの書き出し）

どれも特別な技術ではありませんが、慌てているときほど、この順番を思い出すだけで落ち着けます。
この記事が、WordPressのトラブルで困っている方の「最初の一歩」になればうれしいです。

---