🛠️ WordPressメディアライブラリが真っ白に!?
WordPressの管理画面で、突如メディアライブラリが真っ白に――。
画面上部には、「Warning: Attempt to read property "before_loop" on null in /home/xs564660/keisouya-no-chie.com/public_html/wp-includes/media.php on line 6122」エラーの表示が！！
エラーメッセージを確認すると「before_loop」がらみのWarning表示。
本記事では、この不可解なトラブルの発生から、復旧に至るまでの検証記録をシェアします。
「before_loop」エラーの原因と完全復旧までの記録
🔍 発生した現象
- メディアライブラリが真っ白で画像が表示されない
- 画面上に以下のPHP警告が表示：
Warning: Attempt to read property "before_loop" on null in /wp-includes/media.php on line 6122
🧩 原因の推定
このエラーは、WordPressが内部的に「存在しないオブジェクト（null）」に対して .before_loop プロパティへアクセスしようとした際に発生します。
つまり：
- 本来オブジェクトであるべき変数が
null - それに対して
$instance->before_loopを呼び出してしまった - 結果、PHPが「そんなプロパティないよ！」と警告
🧪 試した対処法と検証の流れ
✅ プラグインの無効化・更新
- 最近追加したプラグインを無効化 → 効果なし
- ブラウザキャッシュの強制クリア → 効果なし
✅ テーマファイルの確認
sidebar.php や functions.php など、AFFINGERテーマおよび子テーマ内の各ファイルを丁寧に確認。
しかし「before_loop」や $instance->before_loop に該当する記述は見当たらず。
💡 初心者にとってテーマファイルの編集は勇気が必要。でも、バックアップを取りつつ慎重に進めたことで、大きな一歩に。
「これ、触って本当に大丈夫なんだろうか…？」という不安と隣り合わせ。
下手にいじって画面が真っ白になったらどうしよう…と、手が止まりかけた場面も正直ありました。
ですが、「原因を突き止めたい」という一心で、子テーマを活用しつつバックアップを取ったうえで慎重に確認を進めました。
今振り返れば、この一歩が復旧への大きな前進だったと感じています。
✅ JavaScriptエラーの確認
ブラウザの開発者ツール（F12）でConsoleを確認
念のため、ブラウザで WordPress 管理画面の「メディア → ライブラリ」を開いた状態でF12キーを押し、「Console（コンソール）」タブでJavaScriptエラーを確認してみました。
…とはいえ、この“開発者ツール”を開く行為そのものが、初心者にはなかなかの勇気が必要です。
「こんな画面出して大丈夫かな…」「何か触ったら壊れるんじゃ？」と、不安で手が止まりそうになりました。
しかし、落ち着いて確認してみたところ——
エラーの表示は特にありませんでした。
ここで「JavaScriptの影響ではない」と一旦判断し、次の調査ステップへと進みました。
✅ サムネイルの再生成
メディアライブラリに画像は存在しているものの、サムネイルが表示されない問題。
「もしかしてサムネイルが壊れているのでは…？」という推測から、
「Regenerate Thumbnails」という専用プラグインを使ってサムネイルの再生成を試しました。
このプラグイン、実は今回のトラブルで初めて知ったもので、
「こんな便利なツールがあったのか！」という新たな発見でもありました。
WordPressの奥深さを改めて実感。
しかし、残念ながら再生成しても表示状況に変化はなく、
サムネイルの問題ではなかったことがはっきりしました。
✅ テーマの切り替えによる検証
最後の手段として、現在使用中のAFFINGERテーマを一時的に停止し、
WordPress公式テーマ「Twenty Twenty-Four」に切り替えて、症状に変化があるかを検証しました。
正直、この決断にはかなり迷いがありました。
というのも、これまで時間をかけて積み上げてきたウィジェットやレイアウトのカスタマイズが、
テーマの切り替えによってリセットされたり、崩れてしまうのではないかという強い不安があったからです。
「ここまでの積み上げが消えてしまうのでは…」
そんな葛藤が頭をよぎりましたが、
「それでも原因を突き止めたい」という強い気持ちが勝り、思い切って切り替えを実行。
その結果、Twenty Twenty-Fourでも症状は改善されず、
メディアライブラリは引き続き画像が表示されない状態であることを確認。
このことから、テーマ自体が原因ではないと確定できました。
なお、検証後には再びAFFINGERテーマに戻したのですが、
これまで設定していたカスタマイズやウィジェットは無事に復元され、安心しました。
🧨 最終手段：全プラグイン停止 → 復旧！
すべてのプラグインを停止した瞬間、メディアライブラリが見事に復旧！
画像のサムネイルもズラリと並び、画面は一気に正常な状態に戻りました。
このとき、正直喜びと同時に「もっと早く試せばよかった…」というちょっとした後悔も。
というのも、それまでには
- テーマファイルエディターを開いてコードを確認
- ブラウザの開発者ツール（F12）でJavaScriptエラーをチェック
- テーマの切り替えによる検証
……と、初心者には少しハードルの高い操作にたくさんチャレンジしてきました。
そんな中で、「すべてのプラグインを一度停止する」というシンプルな対応こそが、一番の近道だったという気づき。
むしろ今振り返れば、この方法が“もっとも手軽でリスクの少ない検証手段”だったかもしれないと感じています。
とはいえ、ここまでの検証があったからこそ、
「テーマやJavaScriptには問題がない」「サムネイルも再生成済み」という安心材料を得られたのも事実。
一見遠回りに見えるステップが、確実な原因特定と復旧に繋がったと、今は思えています。
そこから1つずつプラグインを有効化して原因を特定。
🕵️♂️ 原因は「CloudSecure WP Security」だった！
プラグインを1つずつ有効化していく中で、ついに「CloudSecure WP Security」を有効化した瞬間——
またあのエラーが画面に現れました。
Warning: Attempt to read property "before_loop" on null in /wp-includes/media.php on line 6122
「これだ…！」
思わず声が出るほど、原因を突き止めた達成感と安堵感が押し寄せてきました。
すぐにCloudSecureを無効化してみると、あのしつこい警告がぴたりと消失。
その瞬間、ようやくすべてのピースがつながったようなスッキリした気持ちに。
さらに検証を進める中で、同時に使っていたXO Securityとの競合が関係している可能性も高いことが判明。
WordPressコアファイル（media.php）の処理に干渉していたと考えられます。
🔄 XO Securityとの併用が原因？
今回の原因は、CloudSecureとXO Securityが一部の機能で重複しており、WordPressのコアファイル（media.php）の処理と競合した可能性が高いと考えられます。
✅ 現在の環境と結論
| 項目 | 状態 |
|---|---|
| メディアライブラリ | 正常表示 |
| サムネイル | 再生成済み |
| テーマ | AFFINGER6（親＋子） |
| CloudSecure | 無効化中 |
| XO Security | 有効化中（問題なし） |
結果：トラブル前よりもクリーンで最適化された構成に！
✍️ まとめと学び：初心者がまずやるべきことは？
今回のトラブルを通じて、次のような重要な学びが得られました。
プラグインの競合は予期せぬエラーを引き起こす
セキュリティ系プラグインは非常に便利ですが、複数を併用すると内部処理が重複し、WordPressのコア機能と干渉するリスクがあります。
特にCloudSecure WP Securityのように多機能なプラグインは、他のセキュリティ系プラグイン（今回で言えばXO Security）と競合しやすいため、併用時は機能の重複に注意が必要です。
なぜ“後から”エラーが起きたのか？
原因は明確には特定できませんが、考えられる要因としては以下の通りです：
- WordPress本体や他のプラグインのアップデートにより、CloudSecureやXO Securityの内部処理と干渉するようになった可能性
- 特に
media.phpのようなWordPressコアファイルの仕様変更があった場合、以前は問題なかったコードが突然エラーを出すことがあります - また、CloudSecureの設定を後から変更したことで、XO Securityと機能が重複し、あるタイミングで条件が揃ってエラーが表面化したとも考えられます
🧭 結局、初心者は何から始めればいいのか？
WordPress初心者が同じようなトラブルに遭遇したとき、まずは以下のステップをおすすめします：
✅ 1. バックアップを取る
何よりも先に、サイト全体のバックアップを取得しましょう（BackWPupなどのプラグインが便利）
バックアップデータは、同じサーバー内だけでなく、外部のハードディスクやクラウドストレージ（例：Google Drive、Dropbox）にも保存しておくと安心です。
サーバーに障害が起きた場合や、誤ってファイルを削除してしまった場合でも、外部に保存しておけば復元が可能です。
「何かあっても戻せる」という安心感があるだけで、作業のストレスも大きく減ります。
✅ 2. プラグインを1つずつ無効化して確認
すべて無効化 → 正常に戻るか確認 → 1つずつ有効化して原因を特定
✅ 3. テーマを一時的に切り替えてみる
「Twenty Twenty-Four」などの公式テーマに切り替えて、テーマが原因かどうかを切り分ける
✅ 4. ブラウザの開発者ツール（F12）でエラーを確認
ConsoleタブでJavaScriptエラーが出ていないかチェック
✅ 5. 焦らず、1つずつ検証する
一気にすべてを変えず、「ひとつ変更したら確認する」というステップを繰り返すことが、もっとも確実で安全な検証方法です。
今回は結果的に、すべてのプラグインを一度に無効化するという手段を取りましたが、これはあくまで「最終手段」として行ったものです。
本来であれば、1つずつ無効化して確認することで、よりスムーズに原因を特定できたかもしれません。
とはいえ、今回のように「一気に無効化 → 復旧 → 1つずつ有効化して原因を特定」という流れも、確実性の高いアプローチであることは間違いありません。
💡 最後に
今回の経験を通じて、「怖がらずに試してみること」「遠回りに見える検証が、実は一番の近道だったこと」を実感しました。
WordPressは奥が深いですが、一歩ずつ着実に進めば、初心者でも必ず原因にたどり着けます。
この記事が、同じようなトラブルに悩む方の助けになれば幸いです。