月初だし、本サイト（WordPress）で手動バージョンアップするプラグインの更新作業（プラグインのバージョンアップ及び手動によるCSSの変更）をやって、バックアップをしようと思った。
バージョンアップ対象のプラグインを更新し、CSSの変更を手動でFTPする前に、現在の状態を確認しようとページを表示したら･･･
なんでページが表示されない？「このサイトで重大なエラーが発生しました」ってのは何だ！？
どうやらWordPressがクラッシュし、簡単にはサイトが復旧しないようだ。普通の人ならパニックになり、対処不能だろう。
そこで、私が実施した解決方法を記事化するので、同様のエラーを解決する参考にして欲しい。
WordPressがクラッシュする原因
WordPressがクラッシュして上記画面が表示される原因は、大きく2つ考えられる。1つはサーバ側の問題で、もう1つはWordPress側の問題だ。
WordPressがクラッシュする原因を列挙すると、次のようになるだろう。
- サーバ側の問題
- 500 Internal Server Error
サーバへの接続は可能だが処理が完了しない場合に発生するエラーで、サーバ構成ファイルが破損している等の深刻な問題の場合も考えられる - HTTP 502 Bad Gateway
Webサーバ側で何らかのエラーが発生していて（サーバへのアクセスが集中している場合もある）、サーバが正しく応答していない場合が考えられる - HTTP 503 Service Unavailable
Webサーバ側が過負荷等で機能が停止していて処理が出来ない場合が考えられる
- 500 Internal Server Error
- WordPress側の問題
- ERR_CACHE_MISS
ブラウザ側でアクセスしたサイトページのキャッシュが正常に取得出来ない場合に発生するが、この場合はWordPress側のキャッシュ系プラグインに問題が発生している場合が考えられる - メモリ上限超過
WordPress側のメモリ制限エラーが発生しており、その実行プログラミング言語であるPHPのメモリ制限や、PHPプログラムのバグ等で使えるメモリが足りなくなった場合が考えられる - データベースの破損
WordPressは、記事情報その他をデータベース（RDBMS：通常はMySQLを利用）に保存しているが、そのデータベースの構成ファイルやテーブルの破損等でデータベースの接続が出来ない場合や、必要なデータが取り出せなかったり、最悪は外部からのハッキング（クラッキング）等で異常が発生している場合が考えられる
- ERR_CACHE_MISS
WordPressがクラッシュする原因をざっと書き出してみたが、もちろん上記原因以外も考えられるし、複数の原因が複合して発生している場合も当然考えられる。
ちなみに、WordPressがクラッシュして真っ白い画面だけが表示され、「WordPressのトラブルシューティングについてはこちらをご覧ください。」のリンクをクリックすると、上記画面に遷移する。
が、上記画面のFAQトラブルシューティング内容を読んでも、何も解決しないだろう。
基本的にサーバ側の問題は契約しているレンタルサーバ業者が対応するしかないが、レンタル料金を下手にケチっている場合は、CPU・メモリ・ディスク等が低スペックであるために、自身のWordPressサイトが契約サーバのスペックに耐えられない規模になっていた、なんてこともあるかも知れない。
ちゃんとしているレンタルサーバ業者ならば、営業時間内であれば電話等で親切に対応してくれるだろうから、ITに詳しくない人は、まずレンタルサーバ業者のサポート（ヘルプデスク）に連絡をしてみるのが良いと思う。
WordPress側の問題に関しては、次の原因でクラッシュするケースが大半のハズだ。
- テーマを変更または更新（バージョンアップ）した
- プラグインを更新（バージョンアップ）または新規で導入した
- その他オリジナルのPHPコードをWordPressにアップロードした
上記はいずれもPHPコードの変更が原因によるWordPressのクラッシュだが、手動でWordPressテーマを変更したり、新規でプラグインを導入したり、ましてや自分で書いたり修正したPHPコードをブチ込んでいれば、それが原因であるのは本人が一番よく分かっているハズだ。
しかし、最近の6.0系の場合は、WordPressテーマや利用プラグインが「自動更新」に設定可能だから、知らない内にWordPressがクラッシュしていた、となりかねない。
この場合は、何が原因なのかが分からないから特にそうだが、自分である程度クラッシュした原因が分かっている場合でも、WordPressのデバッグモードを有効にし、デバッグログをチェックして原因を取り除くのが一番早い解決策となる。
今回の私の場合は、明らかにプラグインの更新（バージョンアップ）が原因だ。
なお、WordPress側の問題として「外部からのハッキング（クラッキング）」を挙げたが、実は笑って済まされるほど低い可能性でもなかったりする。今でもたまーに、ググッた先のサイトが「ラッキービジター」にヤラレているのを見ることがあるからだ。
興味のある人は、ラッキービジターウイルスの駆除と予防方法を書いているので参照して欲しい。
WordPressのデバッグモードを有効にする
WordPressのデバッグモードを有効にするには、WordPressを構成するファイルを修正してFTPする必要がある。
WordPressでサイト運営をしている場合でも、FTPソフトは使うことがあると思うが、今まで特にFTPソフトを使ったことがない人は、次の記事を参考にし、FTP経由でサーバにあるWordPressサイトのファイルを一度、ローカルにダウンロードしておいた方が良いだろう。
なお、FTPソフトのFTPサーバの設定は、契約しているレンタルサーバの設定を参照して設定しておく必要がある。
WordPressのデバッグモードを有効にするには、Webサーバのドキュメントルート（例：public_html）にある「wp-config.php」ファイルを修正するので、ローカルにファイルがない場合はFTP経由でダウンロードし、さらにファイルをコピーしてバックアップを作成しておこう。
WordPressのバージョン等によって微妙に違うかも知れないが、図のように
//define(‘WP_DEBUG’, false);
デバッグフラグを指定しない設定行をコメントアウトする。
そして次のコードを追記し、保存すればOKだ。
\wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
ファイル内容を修正・追記し、保存したらサーバのドキュメントルートに上書きでFTPすれば、WordPressのデバッグモードが有効になる。
デバッグログをダウンロードして内容を確認する
WordPressのデバッグモードを有効にしたら、デバッグログを出力させるために、クラッシュしているサイトを表示する（例の白い絶望的エラー画面をリロードするのでも良い）。
すると、サーバの「wp-content」フォルダに「debug.log」のファイル名でデバッグログが出力されるので、FTP経由でローカルにダウンロードする。
図のように、デバッグログを上からザッと読んでみると、238行目以降
\wp-content\debug.log
[02-Jul-2022 09:08:13 UTC] PHP Warning: include(/home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/vendor/composer/../../includes/randomClass.php): failed to open stream: No such file or directory in /home/eware/dajya-ranger.com/public_html/wp-content/plugins/all-in-one-seo-pack/vendor/composer/ClassLoader.php on line 571
[02-Jul-2022 09:08:13 UTC] PHP Warning: include(): Failed opening '/home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/vendor/composer/../../includes/randomClass.php' for inclusion (include_path='.:/opt/php-7.4.28/data/pear') in /home/eware/dajya-ranger.com/public_html/wp-content/plugins/all-in-one-seo-pack/vendor/composer/ClassLoader.php on line 571
[02-Jul-2022 09:08:13 UTC] PHP Fatal error: Uncaught Error: Class '\CHPADB\Includes\randomClass' not found in /home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/includes/functions.php:36
Stack trace:
#0 /home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/includes/scripts.php(70): CHPADB\Includes\adbClass('randomClass')
#1 /home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/view/header_part.php(2): CHPADB\Includes\scripts->rclass('show')
#2 /home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/includes/scripts.php(84): require_once('/home/eware/daj...')
#3 /home/eware/dajya-ranger.com/public_html/wp-includes/class-wp-hook.php(307): CHPADB\Includes\scripts->css('')
#4 /home/eware/dajya-ranger.com/public_html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array)
#5 /home/eware/dajya-ranger.com/public_html/wp-includes/plugin.php(476): WP_Hook->do_action(Array)
#6 /home/eware/dajya-ranger.com/public_html/wp-includes/ge in /home/eware/dajya-ranger.com/public_html/wp-content/plugins/chp-ads-block-detector/includes/functions.php on line 36
この野郎！自動更新設定にしていた「CHP Ads Block Detector」プラグインが原因かっ！！Σ(Дﾟ；/)/
上記画面は、CHP Ads Block Detectorプラグインの更新履歴ページだが、今日（本稿執筆時点・2022年07月02日）Ver3,7.2にバージョンアップし、図赤枠にある通りWordPress 6.0の互換性とランダムクラスジェネレータを改善したようだ。
デバッグログを読むと、238行目で「randomClass.php（改善したランダムクラスジェネレータ？）」が（恐らく）ファイルストリームを開こうとして失敗し、続く240行目でプログラム例外（エラー）がキャッチ出来ずに致命的エラーが発生してWordPressがクラッシュしてやがる。
デバッグログを元に、CHP Ads Block Detectorプラグインの「randomClass.php」ファイルをデバッグすることも可能だが、私にはそんな義務はないし、多分一両日中にバグレポートが開発者に寄せられて、勝手かつ自動的にバージョンアップされることだろう。
デバッグログを最後まで目を通すと、CHP Ads Block Detectorプラグイン以外は問題がないようだから、単純にコヤツを図のように無効にしてやれば解決しそうだ。
はい、ビンゴ！
プラグインが勝手にバージョンアップして、それが元でWordPressがクラッシュしてサイトがダウンだなんて、カンベンしてくれよ！！（絶叫）
その他の解決方法
WordPressのデバッグモードを有効にし、デバッグログをFTP経由でダウンロードして読んでみても、「何が原因だがサッパリワカラン！」てな人もいるだろうと思う。
そんなITに弱い人は、次の方法を試してみると良いだろう。
すべてのプラグインを無効にする
WordPressの場合、プラグインが原因でエラーが出るというのは割と一般的で、それでも今回のように派手にWordPressがクラッシュしたのは初めてだが、ともかくすべてのプラグインを無効にしてみて、サイトが表示されるか、試してみることだ。
具体的には、上記画面でを図赤①のコンボボックスで「無効化」を選択し、図赤枠②のチェックボックスをチェックして全プラグインをチェック状態にする。そして図赤枠③「適用」ボタンをクリックすると、一発ですべてのプラグインを無効にすることが可能だ。
プラグインを無効にしてサイトが表示されたら、ひとつずつプラグインを有効にして行く。
プラグインを有効にして再度WordPressがクラッシュしたら、そのプラグインが犯人なので、そのプラグインを再び無効にし、他のプラグインを有効にすれば良い。
ただし、WordPressをクラッシュさせるプラグインは必ずしも1つだけとは限らないし、他のプラグインとの併用（関係）でクラッシュした、という場合も考えられるので、地道に検証する必要がある。
テーマをデフォルトに戻す
プラグインが犯人ではないとなると、テーマが怪しいということになる。
一旦、WordPressのデフォルトのテーマ「Twenty Twenty-One」に戻して問題が解決するか試してみた方が良い。
仮にデフォルトのテーマで問題が解決した場合、今まで使っていたテーマのバージョンアップか、テーマとプラグインの相性の問題が原因であると考えられる。
それでも解決しない場合
プラグインやテーマが原因でないとすると、次の方法を試してみよう。
- サイトのキャッシュを削除する
- PHPをバージョンアップする
- PHPのメモリ上限を引き上げる
- 最大アップロードサイズと実行時設定の上限を引き上げる
一番簡単かつ原因として意外なのは、サイトキャッシュを削除するだけで問題が解決する場合がある。サイトキャッシュの削除は、WordPressのキャッシュ系プラグインの設定から削除が出来るし、レンタルサーバ側でもサーバキャッシュ設定があるので、そこからキャッシュの削除が可能だ。
あと意外な原因としては、WordPressのバージョンとレンタルサーバ側のPHPバージョンが合っていない場合があるし、PHPのメモリ上限を引き上げたり、最大アップロードサイズと実行時設定の上限を引き上げるのも有効で、問題が解決する場合がある。
これらの設定方法は契約しているレンタルサーバによって違うが、「WordPressのデバッグモードを有効にする」の章で説明した「wp-config.php」ファイルを設定するだけで良い場合や、レンタルサーバ側のコントロールパネルから設定しなければならない場合がある。
この辺に関しては、契約しているレンタルサーバの環境とその設定を調べ、必要とあれば設定を変更してみるしかない。
それでもダメな場合や、本稿の内容がよく分からず、しかも契約しているレンタルサーバ業者の対応もイマイチな場合は、私が有料で解決のお手伝いをしよう。
その場合は、次の「提供サービス」ページを参照し、連絡をしていただければ対応する。
転ばぬ先のバックアップ
WordPressがクラッシュした原因を追及し、無事解決したなら、上記画面のようにサイトを丸ごとバックアップし、不測の事態に備えておこう。
私の場合はAll-in-One WP Migrationプラグインを愛用しており、今のところ必ず2ヶ月に1度はサイトをバックアップし、バックアップファイルを一旦ローカルにダウンロードしてから、NAS（ナス：Network Attached Storage）に放り込んで管理している。
All-in-One WP Migrationプラグインの導入や設定、またその活用について、要望があるようなら記事化するが、WordPressやPukiWiki等でウェブサイトを運営していると、画像ファイルや、サイトを構成している各種ファイルの管理とバックアップが問題になる。
メインで使っているパソコンのローカル（ディスク）に溜め込んでいる人は多いかも知れないが、パソコンのディスクが飛んだら終わってしまうため、ちゃんとしたNAS製品を購入してバックアップ体制を確固たるモノにしておいた方が安全で安心だ。
NASに関しては、次の記事が参考になると思うので、ウェブサイトを運営している人は、ぜひ参考にして欲しい。
おわりに
今回、私の場合は「CHP Ads Block Detector」という、広告ブロック検出プラグインの開発者のヘマなバージョンアップのせいで、WordPressがクラッシュしてしまった。
単に当該プラグインを無効化することで難なく解決したものの、そうすると本サイトは広告ブロックを設定しているユーザに対して無防備になってしまうので、仕方なくPukiWikiで利用しているBlockAdblockスクリプトを仕込むことにした。
BlockAdblockスクリプトは汎用なので、PukiWiki以外にもWordPressや、その他のCMSでも問題なく使えるから、興味がある人は次の記事を参照してみて欲しい。
ウェブサイトのアフィリエイト広告の掲載と、ウェブブラウザでアフィリエイト広告をブロックすることに関しては、人によりその立場からして様々な意見や考えがあるだろうとは思う。
私個人は運営しているサイトの広告をブロックする人に、自サイトのコンテンツを提供する必要性を感じないため、そういう人は私のサイトから退場（離脱）していただく方針である。
本稿を書き進めている内、ふと、SEの良心・友の会サイトもこのプラグイン入れてるじゃん！と思い出し、見てみたら案の定WordPressがクラッシュしてサイトが表示されていない状態だった。
ったくもう！ヽ(`Д´)ﾉｳﾜｧｧｧﾝ!!
･･･こんなことはあまり言いたくないし、書きたくもないが、つくづく日本人は有用な情報やノウハウについて、カネを出したがらない。ITエンジニアに対してもそうで、SEやプログラマってのは、有用な情報とノウハウを沢山持っているのだが、いつまで経っても冷遇されたままだ。
YouTubeを筆頭に、ネットのライブ配信では参加者がリアルタイムにコメントを投稿しながら配信に参加しているため、ポンポン投げ銭が飛び交うようだが、これも見栄と一種の同調圧力が働く日本ならではの光景だと思う。
本サイトでも投げ銭が出来るようにはしているし、noteでも投げ銭をしたり得たりする仕組みがあるが、まず投げ銭はない。サイト記事の場合はライブ配信ではないから、リアルタイムに投げ銭をするというよりは、寄付をするという感覚なのだろう。
つまり、そもそも日本にはチップや寄付という文化がほぼないし、どうしたってサイト記事の場合はGoogle AdSenseを筆頭にしたアフィリエイト広告に頼らざるを得ないのである。
ドメインの維持費とレンタルサーバ代はタダではないのでね。ヽ( ´ー)ﾉ ﾌｯ
Warning: strpos() expects parameter 1 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/compat.php on line 473
Warning: preg_match_all() expects parameter 2 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/shortcodes.php on line 155
Array
