WordPressのデバッグモードが表示されない原因と直し方｜ログも出ない時の確認手順

wordpressのデバッグモードを有効にしたはずなのに、エラーが画面に表示されないことがあります。

さらに、wp-contentフォルダを開いてもdebug.logが見つからず、「設定が反映されていないのでは」と困ることもあるでしょう。

ただし、画面へのエラー表示とdebug.logへの保存は、WordPressでは別々の設定によって制御されています。

設定自体が間違っているケースだけでなく、エラーがまだ発生していない、キャッシュされたページを見ている、WordPressが画面表示を意図的に止めているといったケースもあります。

ここでは、設定の基本から、debug.logが作成されない原因、設定が本当に動いているか確認する方法、サーバー側のログを確認すべきケースまで順番に解説します。

wordpress デバッグモードが表示されない時の確認手順

wordpress デバッグモードが表示されない場合は、最初に「画面に出ない」のか「debug.logにも記録されない」のかを切り分けてください。

画面に表示されなくても、debug.logに記録されていればデバッグ機能は正常に動いています。

反対に、画面にもdebug.logにも何も出ない場合は、設定位置や記述内容、書き込み権限、キャッシュ、編集したファイルが正しいかを確認する必要があります。

迷った場合は、次の順番で確認すると原因を絞り込みやすくなります。

1. wp-config.phpに正しいコードが入っているか確認します。
2. コードが「編集が必要なのはここまでです」より前にあるか確認します。
3. WP_DEBUGなどが別の場所でも定義されていないか検索します。
4. キャッシュを削除し、管理画面やログイン画面などキャッシュされにくいページを開きます。
5. wp-content/debug.logが作成されているか確認します。
6. ログ出力テストを行い、WordPressからファイルへ書き込めるか確認します。
7. 出力されなければ、サーバー側のPHPエラーログを確認します。

wp-config.phpを正しく設定する

通常のトラブル調査では、エラーを訪問者の画面へ表示せず、debug.logにだけ保存する設定が安全です。

wp-config.phpに、次のコードを記載します。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

それぞれの設定には、次の役割があります。

この設定ではWP_DEBUG_DISPLAYをfalseにしているため、画面にエラーが表示されないのは正常な動作です。

エラーの内容は、FTPソフトやサーバーのファイルマネージャーを使ってwp-content/debug.logから確認します。

画面にエラーを表示したい場合の設定

ステージング環境やローカル環境で画面表示を確認したい場合は、WP_DEBUG_DISPLAYをtrueにします。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );

WordPressの致命的エラー処理によって詳細が隠されている場合は、検証環境に限り、次の設定を追加すると画面に詳細が出ることがあります。

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

コードを入れる位置が間違っていないか確認する

デバッグ用のコードは、wp-config.php内の次のコメントよりも前に記載します。

/* That's all, stop editing! Happy publishing. */

日本語版では、次のようなコメントになっている場合もあります。

/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */

このコメントより後ろに記載すると、配置やサーバー環境によっては設定が期待どおりに反映されないことがあります。

trueとfalseを引用符で囲まない

trueとfalseは、文字列ではなく真偽値として指定します。

次のように引用符で囲まないでください。

define( 'WP_DEBUG', 'false' );

PHPでは空ではない文字列が真として扱われるため、文字列の’false’が意図に反して有効と判定されることがあります。

正しくは次の記述です。

define( 'WP_DEBUG', false );

同じ定数が重複していないか確認する

wp-config.php内を検索し、WP_DEBUG、WP_DEBUG_LOG、WP_DEBUG_DISPLAYが複数回書かれていないか確認してください。

例えば、上部でWP_DEBUGをtrueにしていても、別の設定ファイルやサーバー固有の追加コードで異なる値が定義されていることがあります。

PHPの定数は一度定義すると通常は後から変更できないため、重複があると警告が発生したり、想定していない方の設定が使われたりします。

debug.logが作成されない原因と対処法

WP_DEBUG_LOGをtrueにしただけでは、必ずその瞬間にdebug.logが作成されるとは限りません。

ログへ記録されるエラーや、error_log関数による出力が発生して初めて、ファイルが作成されることがあります。

サイトが正常に動いており、記録対象となるエラーが発生していなければ、debug.logが見つからなくても設定ミスとは限りません。

実際にエラーが発生するページを開いていない

デバッグ設定を有効にした後は、不具合が発生した操作をもう一度実行してください。

プラグインの設定画面でエラーが起きる場合はその画面を開き、記事保存時に問題が起きる場合は保存操作を再実行します。

過去に発生したエラーが、設定を有効にしただけで遡ってdebug.logへ記録されるわけではありません。

編集したwp-config.phpが別のサイトのもの

同じサーバーにWordPressを複数インストールしている場合、別のサイトのwp-config.phpを編集している可能性があります。

サブディレクトリやテスト環境がある場合は、対象サイトのindex.phpから読み込まれているWordPress本体の場所を確認してください。

wp-config.php内のデータベース名や$table_prefixと、対象サイトの情報が一致するかも判断材料になります。

wp-contentの場所が変更されている

WP_DEBUG_LOGをtrueにすると、通常はWP_CONTENT_DIRで指定された場所にdebug.logが保存されます。

wp-contentフォルダを標準の場所から移動しているサイトでは、一般的な「WordPress本体直下のwp-content」を探しても見つからないことがあります。

wp-config.php内にWP_CONTENT_DIRの設定がある場合は、そのパスを確認してください。

define( 'WP_CONTENT_DIR', '/サーバー内の任意のパス/wp-content' );

WP_DEBUG_LOGに別の保存先が指定されている

WP_DEBUG_LOGにはtrueだけでなく、ログファイルの保存先を直接指定できます。

define( 'WP_DEBUG_LOG', '/home/example/logs/wp-errors.log' );

このような記述がある場合、ログはwp-content/debug.logではなく、指定された場所に保存されます。

サーバーごとに使用できるパスは異なるため、存在しないパスを指定すると正常に保存されません。

ファイルやフォルダへ書き込めない

PHPを実行しているユーザーにwp-contentへの書き込み権限がないと、debug.logを新しく作成できません。

すでにdebug.logが存在している場合でも、ファイルへの書き込み権限がなければ内容は追加されません。

パーミッションだけでなく、ファイルやフォルダの所有者がサーバーの実行ユーザーと合っているかも関係します。

ページキャッシュが残っている

ページキャッシュによって生成済みのHTMLが配信されると、WordPressやPHPが実行されないことがあります。

この状態では、不具合を再現したつもりでも新しいログが記録されません。

キャッシュプラグイン、サーバーキャッシュ、CDNのキャッシュを削除し、管理画面やwp-login.phpなどキャッシュされにくいページでも確認してください。

ブラウザキャッシュを避けるために、シークレットウィンドウを使う方法もあります。

ログ出力機能が動いているか強制的にテストする

エラーが発生していないのか、ログ機能自体が動いていないのか判断できない場合は、一時的なテストファイルを使って確認できます。

wp-content内にmu-pluginsフォルダがなければ作成し、その中にdebug-log-test.phpというファイルを作成します。

<?php
/**
 * Plugin Name: Debug Log Test
 */

add_action(
	'plugins_loaded',
	static function () {
		if (
			isset( $_GET['debug_log_test'] )
			&& '1' === $_GET['debug_log_test']
		) {
			error_log( 'WP debug log test was executed.' );
		}
	}
);

ファイルを設置したら、次のように対象サイトのログインページへアクセスします。

https://example.com/wp-login.php?debug_log_test=1

その後、debug.logに「WP debug log test was executed.」と記録されているか確認してください。

記録されていれば、ログ機能は正常であり、元の問題ではPHPエラーが発生していない可能性があります。

記録されていなければ、設定の未反映、保存先の違い、書き込み権限、サーバー側の制限などを疑います。

画面にエラーが表示されないのはWordPressの仕様の場合もある

WP_DEBUGとWP_DEBUG_DISPLAYをtrueにしても、すべての処理でエラーがブラウザに表示されるわけではありません。

WordPressは、通信形式やエラーの種類によって画面表示を止める仕組みを持っています。

REST APIやAjaxでは画面に表示されない

WordPressのwp_debug_mode関数では、REST API、Ajax、XML-RPC、JSON形式の通信などについて、エラーの画面表示を無効にする処理が行われています。

投稿の自動保存、ブロックエディター、プラグインの非同期通信などはAjaxやREST APIを利用することがあります。

そのため、管理画面上にエラーが見えなくても、debug.logには記録されている可能性があります。

ブラウザの開発者ツールを開き、「Network」タブで失敗した通信のレスポンスを確認する方法も有効です。

致命的エラーが復旧モードに置き換えられる

WordPress 5.2以降には、プラグインやテーマで致命的エラーが発生した際にサイトを保護する機能があります。

この機能が働くと、PHPの詳細なエラーではなく、「このサイトで重大なエラーが発生しました」などの案内が表示されることがあります。

詳細は管理者メールやdebug.logへ送られるため、画面にPHPエラーが出ないことだけでは、デバッグモードが無効とは判断できません。

検証環境ではWP_DISABLE_FATAL_ERROR_HANDLERをtrueにすると詳細を確認できる場合がありますが、本番環境で常時有効にする設定ではありません。

JavaScriptのエラーはdebug.logに出ないことがある

WordPressのデバッグログが主に扱うのは、サーバー側で発生したPHPエラーや警告です。

ボタンを押しても反応しない、ブロックエディターが読み込まれない、管理画面の一部だけが崩れるといった症状は、JavaScriptのエラーである可能性があります。

JavaScriptのエラーは、ブラウザの開発者ツールにある「Console」タブで確認してください。

この場合、debug.logに何も記録されないのは不自然ではありません。

WordPressが起動する前のエラーは記録できないことがある

wp-config.php自体の構文エラー、PHPの起動エラー、Webサーバーの設定エラーなどは、WordPressのデバッグ処理が始まる前に発生します。

そのため、WP_DEBUG_LOGを有効にしていてもwp-content/debug.logへ記録されない場合があります。

wp-config.phpを編集した直後に500エラーが発生した場合は、まず編集前のファイルへ戻してください。

原因の詳細は、レンタルサーバーが提供するPHPエラーログやWebサーバーのエラーログから確認します。

設定しても出ない場合はサーバー側のログを確認する

WordPress側で原因を確認できない場合は、レンタルサーバーの管理画面にあるPHPエラーログを確認します。

サーバーによっては、「エラーログ」「PHPログ」「アクセスログ」「Webサーバーログ」など、名称が異なります。

確認する際は、不具合を再現した時刻と同じ時間帯の記録を探してください。

サーバー側のログでは、次のような問題が見つかることがあります。

• PHPの構文エラー
• 使用できるメモリの上限超過
• 実行時間の上限超過
• 存在しないファイルの読み込み
• ファイルやフォルダの権限エラー
• ディスク容量の不足
• PHP拡張機能の不足
• プラグインやテーマの互換性エラー
• WebサーバーやWAFによる処理の拒否

サーバー側のログには記録されているのにdebug.logには何もない場合、WordPressが起動する前に処理が停止している可能性が高くなります。

反対に、サーバー側にもdebug.logにも記録がない場合は、PHPエラーではなく、JavaScript、通信、キャッシュ、DNS、CDNなど別の問題も検討してください。

調査が終わったらデバッグモードを無効にする

原因を確認できたら、デバッグモードを有効にしたまま放置しないでください。

公開中のサイトでは、wp-config.phpを次の状態へ戻します。

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

debug.logが作成されている場合は、必要な内容を保存したうえでサーバーから削除します。

ログにはサーバー内のファイルパス、使用中のプラグイン、テーマ、処理内容などが含まれることがあります。

サイトのURLからdebug.logへ直接アクセスできない状態になっているかも確認してください。

継続的にログを保存する必要がある場合は、公開ディレクトリの外へ保存する方法を検討します。

ただし、利用できる保存先はサーバー環境ごとに異なるため、レンタルサーバーの仕様に合った絶対パスを指定する必要があります。

まとめ［Q&A］

さらに詳しく知りたい方へ