WordPressで画面が真っ白になったり、プラグインやテーマが不具合を起こしたとき、原因を調べるために必要になるのがwp-configを使ったデバッグ表示の設定です。正しい設定をしていないとエラーが表示されず障害の原因がつかめませんので、wp-config デバッグ 表示 方法に関する最新かつ正確な手順と注意点を、初心者の方にもわかりやすくまとめました。トラブル解決に役立ちます。
目次
wp-config デバッグ 表示 方法の基本設定とは
まずは「wp-config デバッグ 表示 方法」を理解するための基本です。wp-config.phpという設定ファイルに定義する定数を通じて、デバッグを有効にするかどうか、エラーを画面に表示するかどうか、あるいはログファイルに残すか、などを制御します。これらの設定を正しく配置しないと期待通りに動かず、エラーが出ない、または隠されてしまうことがあります。wp-config.php の編集にはアクセス権が必要であり、開発中か本番環境かを意識して設定を変更することが重要です。wp-config デバッグ 表示 方法の“why(なぜ必要か)”と“what(何を設定するか)”を理解することで、問題解決までの時間を短縮できます。
WP_DEBUGの役割
WP_DEBUG 定数は WordPress のデバッグモードを根本的に ON/OFF するためのフラグです。false に設定されていれば通常のエラー報告レベルで動作し、警告や通知、非推奨の関数の使用なども含め、すべてを報告するようにするには true に変更する必要があります。wp-config.php 内でこの定数を最初に設定することが基本です。なお、本番環境では true にするとセキュリティリスクやユーザー体験の低下につながることがあるため、使用時期を限定するのが望ましいです。
WP_DEBUG_DISPLAY と画面表示の制御
WP_DEBUG が true のとき、WP_DEBUG_DISPLAY を使ってエラーの表示を画面に出すかどうかを制御できます。true にすればウェブページ上に出力され、false にすると画面には表示されず、ログファイルへの出力だけになります。画面に表示するかどうかは、開発環境・ステージング環境・本番環境の用途に応じて切り替えるべきです。特に本番環境では表示をオフにすべきで、ログで記録を取ることが推奨されます。
WP_DEBUG_LOG とログファイルの出力先
WP_DEBUG_LOG を true にすることで、WordPress はエラーをログファイルに保存するようになります。デフォルトでは /wp-content/debug.log に出力されますが、環境によっては書き込み権限やファイル位置の調整が必要です。ファイルのパーミッションやサーバーの設定により、ログが生成されない場合もありますので、アクセス権の確認やファイルが存在するか確認することが重要です。
wp-config デバッグ 表示 方法の具体的な手順
ここでは実際に wp-config デバッグ 表示 方法を使って画面にエラーを表示するための具体的な手順を詳しく解説します。ファイルの場所、編集タイミング、定数の追加位置などを含めて、間違いが起きにくいようにまとめました。これに従えば「定義を入れたのに画面に出ない」という問題を回避できます。
wp-config.php を開く場所とバックアップ方法
まず FTP、SSH、あるいはホスティング管理画面のファイルマネージャーを使って WordPress のルートディレクトリにある wp-config.php ファイルを探します。通常 wp-admin や wp-includes フォルダと同じ階層です。編集前には必ずファイルのバックアップを取ること。ファイルを間違えて壊すとサイトが表示されなくなる恐れがあるからです。また文字コードを保つこと、BOMなしの UTF-8 などが望ましい設定です。
基本コードの挿入場所
wp-config.php 内には「/** That’s all, stop editing! Happy publishing. **/」というコメント行があります。これはこのファイルを編集する際の目安です。デバッグ設定の定義はこのコメントの直前に入れるのが安全です。もし誤ってこの行より後に定義すると、WordPress の起動プロセスで読み込まれない可能性があります。必ずこの行より前に define 文を追加してください。
コード例:画面にエラーを表示させる設定
以下は実際に画面にエラーを表示させたい場合のコード例です。
この例ではすべてのエラー・警告・通知を画面に出すことを目的としています。
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_DISPLAY’, true );
define( ‘WP_DEBUG_LOG’, false );
この設定で、ログファイルには残さず画面に直接表示できるようになります。開発時の確認には便利ですが、本番環境ではより安全な設定を使うべきです。
コード例:画面表示を隠してログだけ記録させる設定
本番環境またはユーザーにエラーを見せたくない状況では、画面表示をオフにしてログだけを残す設定が適切です。以下はその例です。
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
define( ‘WP_DEBUG_LOG’, true );
この設定だと、画面は正常表示されつつ内部で何が起こっているかを debug.log で確認できます。エラー内容がユーザーに見えないため安全性が高まります。
追加のデバッグ定数と特殊ケースへの対応
基本設定以外にも便利な定数や、REST/AJAX やフェイタルエラー処理など特殊なケースの設定が存在します。ここを押さえておくと、画面に出ないエラーを見逃さずに済みます。wp-config デバッグ 表示 方法の奥深い部分です。
SCRIPT_DEBUG と SAVEQUERIES の活用
SCRIPT_DEBUG 定数は、圧縮された JavaScript や CSS ではなく、非圧縮・開発版のファイルを読み込ませる設定です。テーマやプラグインでスクリプトの不具合を追うときに重宝します。
SAVEQUERIES を true にすると、データベースクエリの内容や実行時間が配列に記録され、どのクエリが重いかが把握できます。どちらもパフォーマンスに影響するため、開発環境でのみ使うのが望ましいです。
REST/AJAX/XML-RPC でのエラー表示制御
REST リクエストや AJAX、XML-RPC 経由のリクエストでは、WP_DEBUG_DISPLAY の設定にかかわらず画面表示が抑制されることがあります。これらのリクエストでは WordPress が自動的に display_errors をオフにするためです。
これに対応するには、ログにしっかり記録されるよう WP_DEBUG_LOG を有効にするか、特殊なフック/カスタムコードで制御する必要があります。
フェイタルエラー処理の無効化(WP_DISABLE_FATAL_ERROR_HANDLER)
WordPress 5.2 以降にはフェイタルエラーが発生した際の特別なハンドラが導入されています。これを無効にするためには WP_DISABLE_FATAL_ERROR_HANDLER を true に設定します。
これによって致命的なエラーが発生した場合、WordPress の安全機能により画面にエラーのページが自動的生成されないようになりますので、デバッグ時により詳細な情報を得ることができます。
デバッグ表示が期待通りにならないときのトラブルシューティング
wp-config デバッグ 表示 方法を設定しても画面にエラーが出ない、ログも生成されない、といったケースがあります。そのようなときに確認すべき項目を順を追って挙げます。原因を特定しやすくするためのチェックリスト形式で理解してください。
ファイルの書き込み権限の確認
デバッグログファイル(debug.log)を生成するためには、wp-content フォルダに書き込み権限が必要です。パーミッション設定が厳しいとログが作成されません。所有者・グループ・アクセス権が正しいかサーバー側で確認してください。また、ログのパスをカスタム指定している場合はそのディレクトリも同様に書き込み可能であることを確認する必要があります。
キャッシュやプラグインによる出力抑制
キャッシュ系プラグイン、セキュリティ系プラグイン、テーマの functions.php の中に error_reporting または ini_set(‘display_errors’,0) のようなコードが入っていると、デバッグ表示が抑えられてしまいます。これらを一時的に無効化して確認すること、またはコード中で WP_DEBUG 定数に依存するようになっているかどうかを調べることが重要です。
PHP の設定(php.ini やサーバー設定)の確認
WP_DEBUG 定数が true でも、サーバー側の php.ini で display_errors=Off や error_reporting のレベルが限定されていると、期待どおりの情報が出ないことがあります。PHP の設定値が WordPress の定数により上書きできないケースもあるので、サーバー管理者かホスティング会社に問い合わせるべきです。
Syntax エラーや文字列定義の間違い
define 文でのシンタックスミス(シングルクオートやセミコロンの忘れなど)、変数定義の位置誤り、定数の重複定義などによって wp-config が正常に読み込まれない場合があります。特に “false” と文字列 ‘false’ の違い、全角・半角の修正など細かいミスが原因となるので注意深く設定してください。
wp-config デバッグ 表示 方法を適切に使う環境設定の選び方
デバッグ表示をいつ・どこで有効にするかは重要で、環境によって設定を使い分けると安全かつ効率的です。wp-config デバッグ 表示 方法を習得すると、開発・ステージング・本番それぞれ最適な設定が選べます。以下では環境ごとの推奨設定を比較しながら説明します。
開発環境での設定パターン
開発環境では、すべてのエラーを画面に表示し、ログもしっかり取りたいところです。通常以下のように設定します:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_DISPLAY’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘SCRIPT_DEBUG’, true );
define( ‘SAVEQUERIES’, true );
この設定によって、コードのどの部分で問題が起きているか、どのクエリが遅いかなどの詳細情報が得られます。しかし表示量が多いため整理して確認することが必要です。
ステージング環境での設定例
ステージング環境では、ユーザーに見せないようにしつつデバッグ情報を確実に取得したいケースが多いため、画面表示をオフにしログだけ記録することが基本です。画面表示も見たい時だけ一時的にオンにする運用が有効です。環境ごとに define 文を条件分岐で制御する方法もあります。
本番環境での安全運用の方法
本番環境では、ユーザー体験とセキュリティを優先しますので、多くの場合 WP_DEBUG を false にするか、画面表示を非表示にしログのみ記録する設定が最適です。またフェイタルエラー処理ハンドラーや REST/AJAX 出力の制御なども利用し、不意の情報漏洩を防ぎます。
まとめ
wp-config デバッグ 表示 方法とは、wp-config.php 内で複数の定数を定義することによって WordPress にエラーの表示方法やログ記録を指示する仕組みです。WP_DEBUG がすべての基本であり、画面表示は WP_DEBUG_DISPLAY、ログ記録は WP_DEBUG_LOG が中心になります。
画面にエラーを出すか隠すか、本番環境か開発環境かで設定を使い分けることが重要です。また書き込み権限の不備や PHP 設定、プラグインによる出力抑制などが、期待どおり動かない原因になりますので、そうした点も必ず確認してください。
適切な設定でデバッグ表示を行えば、問題の箇所を特定しやすくなり、不具合修正やサイトの安定化に役立ちます。設定を行う際は、バックアップを忘れずに、安全な運用を心がけてください。
コメント