デバッグモードは特別なプラグインなどを使わずとも、サイトの不具合によるエラー、カスタマイズなどの問題特定に利用できます。とくに中級以上のユーザーなら技術的なステップアップを目指して、使いこなしたい機能です。
WordPressのデバッグ機能
基本的なデバッグ機能設定は WordPress ルートディレクトリにあるwp-config.phpで行います。 つぎのように基本的には、デフォルトでは無効になっています。 必要に応じて設定を追記、値を調整します。
/**
* 開発者へ: WordPress デバッグモード
*
* この値を true にすると、開発中に注意 (notice) を表示します。
* テーマおよびプラグインの開発者には、その開発環境においてこの WP_DEBUG を使用することを強く推奨します。
*
* その他のデバッグに利用できる定数についてはドキュメンテーションをご覧ください。
*
* @link https://ja.wordpress.org/support/article/debugging-in-wordpress/
*/
define( 'WP_DEBUG', false );
/* 編集が必要なのはここまでです ! WordPress でのパブリッシングをお楽しみください。 */
/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';
WP_DEBUG
デバッグモードの有効化
設定値
define('WP_DEBUG_LOG', true); // 有効
define('WP_DEBUG_LOG', false); // 無効
WP_DEBUG_LOG
デバッグ情報を wp-content/debug.log に記録
設定値
define('WP_DEBUG_LOG', true); // 有効
define('WP_DEBUG_LOG', false); // 無効
※デバッグログファイルの所有者がサーバーユーザー（Apacheなど）である必要があります。 ファイルのパーミッションは通常 644 です。
WP_DEBUG_DISPLAY
WordPress のデバッグエラーを画面上に表示
設定値
define('WP_DEBUG_DISPLAY', true); // 有効
define('WP_DEBUG_DISPLAY', false); // 無効
display_errors
WordPress デバッグ外の PHP エラーの表示
設定値
@ini_set('display_errors', 1); // 有効
@ini_set('display_errors', 0); // 無効
※display_errorsを明示しない場合のデフォルトはサーバーの PHP設定（php.ini）の値が適用される。通常、そのデフォルト値は Off（非表示）です。
error_reporting
エラーの種類を指定して制御します
設定値
error_reporting(E_ALL); // すべてのエラーを表示
error_reporting(E_ERROR); // 致命的なエラーのみ表示
error_reporting(0); // すべてのエラーを非表示
※未設定の場合、php.ini のerror_reportingの値が適用されます。
Deprecated エラーを無視
@ini_set('error_reporting', E_ALL & ~E_DEPRECATED);
非推奨（E_DEPRECATED）エラーは将来的に削除される可能性がある機能に関する通知です。本番環境では通知を無視することが一般的ですが、開発環境では適宜確認することを推奨します。
Warning レベルのエラーを出力しない
@ini_set('error_reporting', E_ALL & ~E_WARNING);
E_ALL：PHPのすべてのエラーと警告を報告します。
~E_WARNING：Warningを除外するという意味です。~ はビット演算子で、特定のエラーレベルを無効にします。
E_ALLですべてのエラーを報告するが、Warning レベルは除外。結果として、Notice や Fatal error などの他のエラーは報告されますが、Warning は出力されません。
Notice も無視する場合はこうなります。
@ini_set('error_reporting', E_ALL & ~E_WARNING & ~E_NOTICE);SCRIPT_DEBUG
WordPress コアの CSS および JavaScript ファイルの未圧縮版を読み込む
設定値
define('SCRIPT_DEBUG', true); // 未圧縮版を読み込む
define('SCRIPT_DEBUG', false); // 圧縮版を読み込む
※基本的に開発環境で WordPress コアのバグや問題を調査する際に使用します。テーマやプラグインで読み込まれるカスタムスクリプトには影響しません。
設定箇所
これらの設定はrequire_once(ABSPATH . 'wp-settings.php'); より前に記述する必要があります。これは、wp-settings.php 内でデバッグに関する設定が定義されることから、その後に書かれたカスタム設定は期待通りに動作しない可能性があるためです。
基本的なデバッグ設定
define('WP_DEBUG', true); // デバッグモードを有効化
define('WP_DEBUG_LOG', true); // デバッグ情報をログファイルに記録
define('WP_DEBUG_DISPLAY', false);// デバッグ情報を画面に表示しない
@ini_set('display_errors', 0); // PHPエラーの画面表示を無効化
WordPress PHP ともにエラーを検出するが、画面には出力せず、wp-content/debug.log に出力します。
ただし、本番環境でのデバッグは以下のセキュリティ対処を徹底してください。
デバッグ情報の取り扱い
デバッグ情報には、プラグインやテーマの脆弱性、サーバーの構成情報、エラーメッセージなどが含まれており、これらが外部に漏洩すると重大なセキュリティリスクを引き起こします。
そのため、本番環境ではデバッグ情報を出力しないことが推奨されます。
ただし、以下のような理由で本番環境でのデバッグ情報が必要になる場合があるでしょう。
- 本番環境でしか再現しない問題の調査が必要な場合
- サイト運用中に発生するエラーの原因を特定するため
ログファイルへのアクセスを禁止する
標準仕様のとおり、公開ディレクトリにログを保存する場合は、Webサーバーの設定でアクセスを制限します。
wp-content ディレクトリ内に .htaccess ファイルを作成します。
ファイルパス：wp-content/.htaccess
<Files "debug.log">
Require all denied
</Files>
あるいは、ルートの .htaccess ファイルで配下すべての*.logに対するアクセスを制限してもよいでしょう。
これなら、サブディレクトリに複数の WordPress が存在していてもすべて対象になります。
<FilesMatch "\.log$">
Require all denied
</FilesMatch>
※ただし、管理画面などで*.logを読み込んで表示するプラグインなどがあると、不具合が生じる可能性があるので、注意してください。
nginxの場合は下記のような *.conf の server ブロック内 に記述します。
/etc/nginx/nginx.conf（グローバル設定）
/etc/nginx/sites-available/example.conf（サイトごとの設定）
server {
# 他の設定
location ~* /wp-content/debug.log {
deny all;
}
}
公開ディレクトリへのデバッグログ出力を避ける
デフォルトでデバッグログはwp-content/debug.logに保存されますが、wp-content は公開ディレクトリであり、Webから直接アクセス可能です。
この状態を放置すると、攻撃者がデバッグ情報を取得する危険性があります。
デバッグログの保存場所やファイル名を変更するには、WP_DEBUG_LOG にカスタムパスを指定します。
define('WP_DEBUG_LOG', '/var/log/wordpress/error-debug.log');
相対パスも可能ですが、絶対パスでの指定が推奨されます。
保存先ディレクトリおよびファイルには、書き込み権限が必要です。
- ファイル：644
- ディレクトリ：755
ここで問題なのが、どこにログを保存するか？です。
推奨される保存先は公開ディレクトリ外のサーバーのログ専用ディレクトリなどです。
例：/var/log/wordpress/error-debug.log
レンタルサーバなどの共有ホスティング環境では /var/log/ などにアクセス権限がない場合があります。その場合は公開ディレクトリの外に保存します。
例：/home/example/error-debug.log
これらが難しい場合は上記のアクセス制限を徹底しましょう。
ログファイルの管理
ログファイルを長期間放置したり、定期的なエラーが頻発している場合、デバッグログがサイトの表示に影響を与えるレベルに肥大化する可能性があります。
そのため、デバッグ終了後はログファイルを削除する、あるいは定期的にローテーションする仕組みを導入することを推奨します。
