WordPressでは設定によってデバッグログをファイルに書き出してくれる機能があります。サイトが重くなったり処理が意図通りになっていない場合にこのデバッグログの内容を確認します。
デバッグログ出力設定方法
wp-config.phpファイルに定数を設定します。
運用環境と開発環境（ステージング環境）は若干処理を変更します。
▽開発環境
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );▽本番環境
define( 'WP_DEBUG', true );
if ( WP_DEBUG ) {
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
}このように書くと「wp-content」フォルダ内に「debug.log」というファイルが作成されます。
その後はログが発生した場合、このdebug.logに上書きされます。
debug.logの時間帯の注意
debug.logに書き込まれる時間はwp-settings.phpのtimezone設定に従うためデフォルトでUTC（協定世界時間）設定になるようです。
日本時間との差は9時間あるので気をつけてください。
date_default_timezone_set( 'Asia/Tokyo' );強引に上記の記述で変更可能ですがWordPressの基準の日付が日本時間になってしまいすべて9時間未来になってしまうためdebu.logの時間変更のためだけに行うにはデメリットが多すぎるのでやめておきましょう。
debug.logはほっとくと肥大化する
debug.logファイルは上書きが基本なのでエラーがあるとファイルサイズが増えていきます。
気が付くとGBまで行ってしまいファイル操作も大変になります。
テキストファイルであってもGBもあればメモ帳アプリが開くことができない場合もあり調整が困難になります。
ログファイル肥大化の防止策
生成するログファイルを日別に生成するように変更できたら肥大化を避けられます。
具体的には下記のようにコードを修正します。
function wp_debug_mode() {
/**
* Filters whether to allow the debug mode check to occur.
*
* This filter runs before it can be used by plugins. It is designed for
* non-web runtimes. Returning false causes the `WP_DEBUG` and related
* constants to not be checked and the default PHP values for errors
* will be used unless you take care to update them yourself.
*
* To use this filter you must define a `$wp_filter` global before
* WordPress loads, usually in `wp-config.php`.
*
* Example:
*
* $GLOBALS['wp_filter'] = array(
* 'enable_wp_debug_mode_checks' => array(
* 10 => array(
* array(
* 'accepted_args' => 0,
* 'function' => function() {
* return false;
* },
* ),
* ),
* ),
* );
*
* @since 4.6.0
*
* @param bool $enable_debug_mode Whether to enable debug mode checks to occur. Default true.
*/
if ( ! apply_filters( 'enable_wp_debug_mode_checks', true ) ) {
return;
}
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 ( in_array( strtolower( (string) WP_DEBUG_LOG ), array( 'true', '1' ), true ) ) {
$log_path = WP_CONTENT_DIR . '/debug.log';
} elseif ( is_string( WP_DEBUG_LOG ) ) {
$log_path = WP_DEBUG_LOG;
} else {
$log_path = false;
}
if ( $log_path ) {
ini_set( 'log_errors', 1 );
// ここで変数$log_pathに日付を追加すれば各日でログファイルを分けられる
// ※コアファイルなのでWordPressをアップデートすると効かなくなる
$log_path = WP_CONTENT_DIR . '/debug-' . date('Ymd') . 'log';
ini_set( 'error_log', $log_path );
}
} 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' ) || defined( 'REST_REQUEST' ) || defined( 'MS_FILES_REQUEST' ) ||
( defined( 'WP_INSTALLING' ) && WP_INSTALLING ) ||
wp_doing_ajax() || wp_is_json_request() ) {
ini_set( 'display_errors', 0 );
}
}どうしても自動化したい場合こちらのコードで一時的に対応できます。
もしくはサーバー管理者に相談できるのなら差し替えプログラムを書いてもらいタイマー処理を用意してもらうことも考えられます。
自動処理はアップデートに対応できないので１週間、１か月などのスパンを決めてデバッグファイルをローカルもしくはクラウドに保存、確認しておくのが結局のところ良いのかもしれません。