WordPress 画面が真っ白になる対応の一つ デバッグモード
2017/03/08
WordPressの画面が真っ白になる不具合は PHPのエラーです
画面が真っ白になる原因の説明
WordPressの画面が真っ白になる不具合があった場合のほとんどは、PHPのエラーが発生している場合です。
ですが、phpのエラーメッセージの表示はセキュリティ上都合が悪い情報になりますので、一般的には PHPのエラーを表示しない設定になっています。
そのため、エラーが起こって画面表示の処理が実行されていないうえに、エラーメッセージも表示されないので、画面が真っ白になるという結果になるのです。
ですので、そういう場合は、エラーメッセージを表示させることで具体的にどんな不具合が起こっているのかを表示させることで解決するのですが、今回はその設定方法について説明します。
その前に、PHPのエラー表示については「WordPress 画面が真っ白になる不具合があった場合の対応の一つ」の方も合わせてご覧ください。
また、プラグインが原因で WordPressが起動しなくなったと分かっている場合、もしくは、それが原因じゃないかと疑わしい場合、簡単な方法で復旧させることを試せる方法もあります。
それを「プラグインが原因で起動しないWordPressを復旧させる方法解説」で記事にしていますので、そのような状況の方はあわせて参考にしてみてください。
[amazonjs asin=”4774182184″ locale=”JP” title=”小さなお店&会社の WordPress超入門 ―初めてでも安心! 思いどおりのホームページを作ろう!”]
WordPressのデバッグモード・画面にエラーを表示
WordPressには、デバッグモードが用意されています。
これの設定を「True」「false」で切り替えることでデバッグモードに変更し、PHPのエラーメッセージを表示できるようになります。
具体的には、WordPressをインストールしたフォルダにある「wp-config.php」ファイルに下記のような記述があります。
※「wp-config.php」は、WordPressのフォルダのルートフォルダにあります。(WordPressのドキュメントルートフォルダにあります。)
—————————-
/**
* 開発者へ: WordPress デバッグモード
*
* この値を true にすると、開発中に注意 (notice) を表示します。
* テーマおよびプラグインの開発者には、その開発環境においてこの WP_DEBUG を使用することを強く推奨します。
*/
define('WP_DEBUG', false);
—————————-
この記述の一番下の行の「false」を「true」に変えることで、デバッグモードに変わり、画面に PHPのエラーが表示されるようになります。
上記の設定でもエラーメッセージが表示されない場合
もし、上記の設定を変えるだけでは画面にエラー表示がされない場合は、下記の行を上記の行の下あたりに追加してみてください。
そうすると表示されるようになるでしょう。(この内容については、下の方に別途説明しています。)
—————————-
※エラーメッセージを表示させる場合
ini_set('display_errors', 'On');
—————————-
WordPressのデバッグモード・ログファイルに出力
上記の設定は、エラーメッセージを処理するか、否かの設定です。
加えて、WordPressには、そのエラーメッセージを画面に表示するか、否かを設定することができます。
開発中の環境であれば問題ありませんが、すでに本番公開してるサイトでの不具合調整など、エラーメッセージを画面に表示させたくない場合も多々あります。
そんな場合は、エラーメッセージを画面には表示させずにエラーログファイルにエラーメッセージを出力させる方法が用意されています。
「wp-config.php」の「define(‘WP_DEBUG’, false);」の下に下記の行を追加することで画面には表示されなくなります。(「false」を「true」に変えることで画面にエラー表示されます。)
—————————-
define('WP_DEBUG_DISPLAY', false);
—————————-
加えて、下記の行を追加することで、ログファイルを出力されるようになります。(ここも「true」を「false」にすることでログ出力を止めることができます。)
—————————-
define('WP_DEBUG_LOG', true);
—————————-
最終的には下記のような記述になります。
—————————-
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', true);
—————————-
エラーログファイルが出力される場所は、デフォルトの設定では「/wp-content/debug.log」として出力されます。
ブラウザでエラーログを見る場合は、「http://……./wp-content/debug.log」でアクセスします。(もしくは、FTPでダウンロードするなどして確認します。)
ただ、この場所は「http://……./wp-content/debug.log」でアクセスできてしまいますので、一時的であれば問題ありませんが、数日間程度ログを出力させて確認したいというような場合などは、.htaccessでアクセス制限をしておく方がいいでしょう。
具体的には、「wp-content」フォルダの直下に下記の「.htaccess」ファイルを入れておきましょう。
/wp-content/.htaccess
—————————-
<Files debug.log> deny from all </Files>
—————————-
※この設定をするとブラウザではファイルにアクセスできなくなりますので、ログを確認する際は ftpでファイルをダウンロードしてくる必要があります。
そのため、場合によっては、Basic認証の設定を行う方がいいかもしれません。
※サーバによっては、「.htaccess」の制限がある場合がありますので、アクセス制限が効かない場合もあります。
また、エラーログ出力は、エラーがある限りエラーログファイルに出力を続けますので、ログの出力が必要なくなった時点でログ出力の設定を止めておきましょう。
そうしないとサーバを圧迫していく原因になってしまいます。
[amazonjs asin=”4797381078″ locale=”JP” title=”本格ビジネスサイトを作りながら学ぶ WordPressの教科書 Ver.4.x対応版”]
デバッグモードで実験してみたこと
WordPressデバッグモードの動きについて
お客さんの環境とローカルの PCに設定している XAMPP環境とでデバッグモードの設定と動作に違いがありましたので、それを調べてみました。
XAMPP環境
XAMPP環境
LAMP環境
WordPressデバッグモードの動きについて
具体的に「WP_DEBUG」の処理として何が行われているかも確認してみました。
/wp-includes/load.php に下記の記述があります。
—————————-
function wp_debug_mode() {
if ( WP_DEBUG ) {
error_reporting( E_ALL );
if ( WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 1 );
elseif ( null !== WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 0 );
if ( WP_DEBUG_LOG ) {
ini_set( 'log_errors', 1 );
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
}
} else {
error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
}
if ( defined( 'XMLRPC_REQUEST' ) )
ini_set( 'display_errors', 0 );
}
—————————-
バージョンによって少しずつ記述内容が違うようですが、上記は、バージョン 3.8のものです。
実際に内部でやっていることは、設定されているフラグによって、「ini_set(‘display_errors’, ‘On’);」などのエラー処理をする、しないの処理をやっているだけでした。
ただ、上記を見ても分かるように、「WP_DEBUG」が「True」になった上で「WP_DEBUG_DISPLAY」が「True」になって初めて「ini_set( ‘display_errors’, 1 );」が設定されるようです。
そのため、「define(‘WP_DEBUG’, false);」の場合は、そもそものサーバの設定が優先されます。
また、WordPressのデバッグ処理を無視するなら、最初から「ini_set( ‘display_errors’, 1 );」を直書きしてもよさそうです。
サーバを移転したりPHPのバージョンを変えたりしたときに画面が真っ白に 2015.03.02追記
- PHPのバージョンアップをした。
- サーバを移転した。
- ローカル環境から本番環境に移した。
といった感じで、PHPの設定そのものが変った可能性がある場合に画面が真っ白になるという不具合の場合は、PHPのショートタグの設定が原因の場合もあります。
ショートタグとは、PHPの宣言を「<? …… ?>」という省略形式で記述する方式のことですが、この設定を有効にするか否かのデフォルト設定が、PHPのバージョンによって違うため、動かなくなる可能性があります。
それについて「サーバ移転、PHPバージョンアップでPHPのソースコードが表示される・ショートタグのPHPが動かない」に記事を書いていますので、詳細はこちらを参照してみてください。
この記事が参考になったと思いましたらソーシャルメディアで共有していただけると嬉しいです!
関連記事
-
-
WordPress プラグインのアップデート失敗でデータが消える事態が!
プラグインのアップデート失敗でデータが消失。不具合が起こる原因はあちこちにありますので常に慎重にバックアップをしましょう。
-
-
Rich ReviewsでWordPressに口コミサイトを簡単に構築する方法
口コミサイトに必要なレビュー投稿機能を提供するプラグインです。独自のフォームをショートコードで編集する自由度が高い設計で、平均点の表示も用意されています。
-
-
WordPressのログイン画面 URLを変更する 管理画面に Basic認証を設定する
ログインURLは誰でも知っています。そのまま使うとリスクが高まりますのでログインURLを変更し Basic認証で二重チェックをする方法を解説。
-
-
WordPressのアップグレードの英語版と日本語版の公開のタイムラグは?
WordPressのアップグレードの英語版と日本語版の公開のタイムラグについて説明しています。
-
-
Theme My Loginの日本語翻訳ファイル Ver.6.4.5対応
Theme My Loginの日本語翻訳ファイルのダウンロードページ。WordPressの翻訳ファイルの設置方法、注意点、翻訳ファイルの作成方法なども解説。
-
-
WP Basic AuthなどWordPressにBasic認証を設定するプラグインのまとめ
WordPressにBasic認証を設定する方法のまとめ。プラグインを使う方法と.htaccessで設定する方法を紹介。公開側、ログインページをそれぞれ設定できます。
-
-
WordPressのPing・更新情報サービス設定方法とPingサーバ
WordPressのPing機能、更新情報サービスの設定方法の解説と Pingサーバのリストを提供しています。
-
-
WordPressのサイトマップ生成ツールPS Auto Sitemapの使い方
サイトマップを PS Auto Sitemapで自動生成する方法を説明します。このプラグインは Google用のサイトマップではなく一般ユーザが見るためのサイトマップページを作ります。
-
-
Basic認証をファイル単位・URL単位で設定する方法の解説
Basic認証はフォルダ単位だけでなくファイル単位での設定もできるためログイン画面だけにBasic認証を設定することもできます。その解説です。
-
-
FC2からWordPressに引越しの際のデータ加工方法の解説
FC2からWordPressに引越しの際にデータを加工する必要がありますが、その加工方法の詳細を解説。秀丸の正規表現による置換を使い作業時間も軽減する方法や加工のポイントも解説。



Comment
デバックモード反応しません。
W3 Total Cacheをプラグインするといきなり真っ白になりました。
W3 Total Cacheを削除してももとにもどりません、
http://omiairyoen.com/wp/wp-login.php
プラグインは全て停止にしましたがもとにもどりません。
wp-config.phpもデバックモード対応しません
原因わかれば教えてくださいませ
ご連絡の内容では不具合の原因や対応方法などは分かりかねますね。
個別のプラグインの不具合については、情報提供はなかなか難しいものがあることをご理解ください。
また、キャッシュ系のプラグインは、データベースのデータやテンプレートのデータを書き換えて処理する機能がありますので、設定ファイルの内容やデータベースの内容などを確認しながら不具合の内容を確認する必要があるようです。
そのため、場合によっては復旧させることにすごく手間がかかる場合も多々あるようです。