WP-LOAD

LESSON / WP LOAD

WordPressのエラーをログで調べる

開発環境でWP_DEBUGとデバッグログを有効にし、画面を壊さずPHPエラーの発生箇所を調べます。

目安 45分 コース進捗 0 / 17

GOAL

このレッスンでできるようになること

  • 開発環境と本番環境のデバッグ設定を分けられる
  • debug.logからエラーの種類と発生箇所を読める
  • ブラウザとサーバーのエラーを切り分けられる

白い画面や500エラーが出たとき、見た目だけでは原因を判断できません。WordPressのデバッグログを使うと、PHPエラーの種類、ファイル名、行番号を確認できます。

デバッグ情報にはサーバー内のパスなどが含まれます。本番画面へ表示せず、まずローカル開発環境で調査します。

ローカル環境でログを有効にする

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にすると、エラーを公開画面へ直接表示せずログへ記録できます。ログは通常wp-content/debug.logへ作られます。

ログから原因を絞り込む

  • 発生した日時
  • Fatal error、Warning、Deprecatedなどの種類
  • エラーメッセージ
  • 対象ファイルのパス
  • 発生した行番号

最初に表示されたメッセージだけでなく、同じ操作をした時刻付近を確認します。別の古いエラーを今回の原因と混同しないようにしてください。

次の図では、「ログから原因を絞り込む」で行う操作の流れを示しています。

「ログから原因を絞り込む」で行う操作の流れを示す図
「ログから原因を絞り込む」で行う操作の流れ

ブラウザ側の問題と切り分ける

発生している問題に合わせて、サーバー側のログとブラウザ側の開発者ツールを使い分けます。

WordPressの不具合をPHPログ、Console、Network、Elementsへ切り分ける図
WordPressの不具合をPHPログ、Console、Network、Elementsへ切り分ける図

PHPの処理はサーバー側なのでdebug.logを確認します。JavaScriptの例外はConsole、CSSや画像の読み込み失敗はNetworkとElementsで確認します。

  • PHP構文エラー・未定義関数：debug.log
  • JavaScriptエラー：Console
  • 404・500・通信内容：Network
  • CSSの上書き・HTML構造：Elements

小さく戻して再確認する

  1. 直前に変更したファイルと行を確認する
  2. エラー箇所の前後を小さく修正する
  3. 同じ操作を行って再現するか確認する
  4. 新しいエラーが増えていないかログを確認する
  5. 管理画面と公開画面の主要ページも確認する

原因が分からないまま複数ファイルを同時に変更すると、何が効いたのか判断できなくなります。1つずつ確認します。

次の図では、「小さく戻して再確認する」の仕組みや関係を確認できます。

「小さく戻して再確認する」の仕組みや関係を示す図
「小さく戻して再確認する」の仕組みと関係

本番環境へデバッグ表示を残さない

本番では少なくとも画面表示を無効にし、ログの保存場所、閲覧権限、保管期間をサーバー設定に合わせて管理します。調査用ログへ個人情報や認証情報を出力しないでください。

次の図では、「本番環境へデバッグ表示を残さない」の仕組みや関係を確認できます。

「本番環境へデバッグ表示を残さない」の仕組みや関係を示す図
「本番環境へデバッグ表示を残さない」の仕組みと関係

ローカルで作られたdebug.logもGitへコミットしません。不要になったログは内容を確認してから削除します。

CHECK POINT

完了条件