WordPressのFatal ErrorでWordfenceが停止・設定リセット!PHPバージョンで解決した手順【CPIサーバー対応】

まめすけ突然、WordPressの管理画面にFatal Errorの通知が!
どうしよう・・・
そんな経験はありませんか?
今回、クライアントのサイトでセキュリティプラグイン「Wordfence」が致命的なエラーで停止し、カスタマイズしていたはずのファイアウォール設定もリセットされてしまうというトラブルが発生しました。サイト自体は表示されていたものの、セキュリティが無防備な状態になっていたため、早急な対応が必要でした。原因はサーバー移転によるPHPのバージョン不一致、そしてCPIサーバー特有のプラグイン削除トラブルでした。
同じ状況で困っている方の参考になれば幸いです。
結論から言います
PHP 8.4 → 8.3へダウングレードするだけで解決しました。 サイト自体は表示されていましたが、Wordfenceが停止しセキュリティが無防備な状態でした。早めの対応が重要です。
焦って色々いじる前に、この記事の手順を落ち着いて読んでみてください。
メンテナンス後の続きがあるのでそちらもご確認ください。
発生したエラーの内容
WordPressから届いたエラー通知にはこう書かれていました。
Uncaught TypeError: array_sum(): Argument #1 ($array) must be of type array, null given
Fatal Error(致命的なエラー) です。サイト自体は表示されていましたが、Wordfenceが強制停止され初期状態に。さらに、これまでカスタマイズされていたはずのファイアウォール設定もリセットされてしまっていました。おそらく、エラーによってWordfenceの設定ファイルが正常に読み込めなくなったことが原因と考えられます。セキュリティが無防備な状態のため、迅速な対応が必要でした。
なぜこのエラーが起きたのか?
原因はPHPのバージョンにありました。
PHP 8.4はエラー判定が非常に厳格になっています。Wordfenceが一時的にnull(空のデータ)を読み込んだとき、以前のPHPバージョンなら「警告」で済んでいたものが、PHP 8.4では「致命的なエラー」としてWordfenceを強制停止させてしまいます。その結果、設定ファイルも正常に読み込めず、カスタマイズ済みのファイアウォール設定がリセットされてしまったと考えられます。
「最新バージョン=安全・安定」とは限らない、というのがWordPress運用の現実です。



なんでも最新にしておけば問題なし!って思ってました・・・
対処手順【CPIサーバー編】
STEP 1|リカバリーモードで管理画面に入る
WordPressはFatal Error発生時、登録メールアドレスにリカバリーモードのURLを自動送信します。そのリンクから管理画面にアクセスし、Wordfenceがエラーで停止していることを確認します。
ここで焦ってプラグインを無効化・削除する前に、次のステップを先に行います。
STEP 2|PHPバージョンを変更する(.htaccessを編集)
CPIサーバーの場合、コントロールパネルからPHPバージョンを変更できないケースがあります。その場合は.htaccessを直接編集します。
手順:
- CPIの「セキュアファイルマネージャー」にFTPアカウントでログイン
- ルートディレクトリの
.htaccessファイルを開く - ファイルの一番上の行に以下を追記して保存
AddHandler x-httpd-php83 .phpこれでPHP 8.3に切り替わります。
追記する場所は「一番上」です。既存の記述の下に書くと反映されないことがあります。
STEP 3|PHP変更を確認してからバックアップ
変更後、WordPressのサイトヘルス(管理画面 → ツール → サイトヘルス → 情報)でPHPバージョンが8.3になっていることを確認します。
確認できたら、All-in-One WP Migration などで完全バックアップを取得。この順番が重要です。
環境を安定させる → バックアップ → 更新・整理 この順番を守ることがトラブル対応の鉄則です。
STEP 4|Wordfenceを最新版にアップデート
PHP 8.3に変更し、サイトが正常表示されていることを確認してから、Wordfenceを最新バージョンにアップデートします。
STEP 5|SiteGuardの削除トラブル → 「待つ」が正解
今回はWordfenceとSiteGuardが重複してインストールされていたため、SiteGuardを削除しようとしました。しかし——
プラグインの削除に失敗しました
このエラーが出て、物理削除できない状態に。パーミッション(755や777)を変更しようとしても、CPIサーバーの制限で変更不可。
試行錯誤しましたが、結論:数十分待ったら自然に消えていました。
なぜ?
CPIサーバーは強固なWAF(Web Application Firewall)とキャッシュ機能を持っています。プラグインの削除操作は受け付けているものの、サーバー側の処理タイムラグにより「即座に反映されない」ことがあるのです。
焦って何度も削除を試みたり、ファイルを直接いじったりするのは逆効果になることも。一定時間放置が正解でした。
STEP 6|.htaccessの余分な記述を掃除して完了
SiteGuardはログインURLをカスタマイズするプラグインのため、削除後に.htaccess内に古い記述が残っていることがあります。
該当箇所を手動で削除し、標準のログインURL(/wp-login.php)で正常ログインできることを確認して、作業完了です。
今回の対応フローまとめ
SiteGuard削除(エラー→時間を置いて確認)
.htaccessの不要記述を削除・ログイン確認
まとめ|WordPressトラブル対応で大切なこと
今回の対応を通じて改めて感じたことをまとめます。
① 最新PHPが「最適」とは限らない PHP 8.4は高性能ですが、まだ対応していないプラグインも多いのが現実。世界中で安定稼働している実績があるバージョン(現時点ではPHP 8.3)を選ぶのが無難です。
② サーバー特有の仕様を理解する CPIサーバーはセキュリティが非常に強固な反面、操作の即時反映がされないことがあります。エラーが出ても「仕様によるタイムラグ」の可能性を念頭に置いておきましょう。
③ 対応の順番を守る 「環境の安定化 → バックアップ → 更新・整理」この順番を崩さないこと。焦って更新やプラグイン削除を先に行うと、さらに複雑なトラブルになるリスクがあります。
【追記】PHPダウングレードだけでは解決しなかった場合の対処法
この記事を投稿後、同サイトで再度エラーが発生したため、追加の対応を行いました。
PHPを8.3に変更しても解決しなかった方は、この追記も参考にしてみてください。
状況の再確認
PHP 8.4 → 8.3へのダウングレードで一度は安定したように見えましたが、その後も同様のエラーが継続していることが判明しました。
Wordfenceは最新バージョン(8.1.4)に更新済みでしたが、それ以上の更新は存在せず、アップデートによる解決もできない状況でした。
原因の再分析:PHPではなく「データ破損」だった
ここで立てた仮説がこちらです。
PHP 8.4でエラーが発生した際に、Wordfenceの設定データがデータベース上で破損・不整合を起こしていたのではないか
実際に、同じPHP 8.3環境で稼働している別のサイトではWordfenceは正常に動作しています。
つまり「PHP 8.3とWordfenceの相性が悪い」のではなく、「最初のエラーで壊れたデータが残ったまま」になっていたことが本当の原因と考えられました。
解決した手順
① Wordfenceを完全削除(データベースも含む)
ダッシュボードからWordfenceを停止・削除する際、「サーバー側のデータも含めてすべて削除する」オプションを必ず選択します。
これにより、データベースに残っていた破損した設定データもあわせて削除されます。
② FTPでファイルの完全削除を確認
ダッシュボードからの削除後、FTPにログインして /wp-content/plugins/wordfence/ フォルダが残っていないかを目視確認しました。
③ Wordfenceをクリーンな状態で再インストール
削除後に改めてインストールし直すことで、破損データの影響をリセット。
④ 各種設定を再構成
再インストール後に必要な設定をゼロから再設定しました。
- reCAPTCHAの再登録・設定
- ブルートフォース攻撃対策の数値調整
- メール通知の設定
⑤ 自動更新を有効化
今後、同様のバージョン不整合によるトラブルを防ぐため、Wordfenceの自動更新をオンに設定しました。
作業前に必ずメモしておくこと
Wordfenceを削除すると設定がすべてリセットされます。
作業前に以下をメモ・保管しておくと再設定がスムーズです。
- Wordfenceのライセンスキー
- reCAPTCHAのサイトキー・シークレットキー
まとめ:「PHPバージョン変更で解決しない」場合のチェックポイント
| 確認事項 | 対処 |
|---|---|
| Wordfenceが最新版かどうか | アップデートがあれば更新 |
| それでも同じエラーが出る | データ破損を疑い完全削除・再インストール |
| 削除時のオプション | 「DBデータも削除」を必ず選ぶ |
| 削除後の確認 | FTPでフォルダが消えているか目視確認 |
PHPのバージョン変更は有効な手段ですが、最初のエラーで生じたデータ破損が残ったままでは根本解決にならないケースもあります。
同じエラーが繰り返される場合は、ぜひこの手順を試してみてください。
サイトのトラブル対応もお任せください
今回のような突然のエラー・真っ白画面・ログイン不能などのWordPressトラブルは、k-suke web worksでも対応しています。
バックアップを取得した上で慎重に作業しますので、お気軽にご相談ください。









コメント