WordPressの設定というと、多くの人はまず管理画面の「設定」メニューを思い浮かべる。だが、サイトそのものの起動条件に関わる一部の設定は、管理画面のどこにもなく、wp-config.php というPHPファイルに直接 define() で書く形になっている。この違いには理由がある。管理画面の設定はデータベース（wp_options テーブル）に保存され、WordPress自体が起動し終わってから読み込まれる。一方 wp-config.php はデータベース接続情報を含め、WordPressが起動するより前に読み込まれる。だからこそ、DB接続先やデバッグ出力の可否、ファイル編集の可否といった「起動前提そのもの」を左右する項目は、ここに定数として書くしかない。
補足:
define('定数名', 値)は、PHPでプログラム全体を通して変更されない値を登録する構文。一度定義すると、以後どのファイルからでも同じ値を参照できる。wp-config.phpに書かれた定数は、WordPressのコアコード側がdefined('定数名')で存在確認しながら随所で参照する仕組みになっている。
WP_DEBUG / WP_DEBUG_LOG / WP_DEBUG_DISPLAY — 3つは別物
デバッグ関連の定数は3つあり、名前が似ているせいで混同されやすい。
WP_DEBUG— PHPの警告・通知・非推奨関数の使用などを検出対象にするかどうかの大元のスイッチ。trueにすると、以降の2つの定数が意味を持つようになるWP_DEBUG_DISPLAY— 検出したエラーを画面に表示するか。本番サイトでtrueのままだと、訪問者の目の前にPHPの警告文がそのまま出てしまうWP_DEBUG_LOG— 検出したエラーをwp-content/debug.logに書き込むか。画面には出さず、ログファイルにだけ記録したい場合はこれをtrueにし、WP_DEBUG_DISPLAYはfalseにする
実務でよくある組み合わせは次の形で、「訪問者には何も見せず、開発者だけが後から確認できる」状態を作る。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
ここで注意したいのは、WP_DEBUG_LOG を true にしていない環境では、そもそも wp-content/debug.log というファイル自体が生成されないという点である。「エラーが起きているはずなのにログファイルが見当たらない」と困ったときは、まず WP_DEBUG_LOG の設定を確認するのが定石になる。
実例として、このアプリの障害復旧ロジック（core/ssh_utils.py::fetch_recovery_logs()）は、更新後のHTTPステータスが500系だった場合にSSH経由で wp-content/debug.log を末尾から読みに行き、どのプラグインでFatalエラーが起きたかをログの中の wp-content/plugins/<プラグイン名>/ というパスパターンから特定して、該当プラグインだけを自動停止する仕組みになっている。この復旧ロジックが正しく機能するには、対象サイト側で WP_DEBUG_LOG が有効になっている（＝debug.logが実際に書き出されている）ことが前提になる。ログファイル自体が存在しない環境では、この経路は空振りし、サーバー側の汎用 error_log を読みに行くフォールバックに切り替わる。「ログを出す設定になっているかどうか」が、障害発生時に原因を特定できるかどうかを直接左右するという一例である。
WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT — 2段構えのメモリ上限
PHPには元々サーバー全体の memory_limit 設定があるが、WordPressはその内側にもう一段、独自の上限をかけられるようになっている。
WP_MEMORY_LIMIT— 通常のフロント表示・一般的な処理で使えるメモリの上限WP_MAX_MEMORY_LIMIT— 管理画面での処理（プラグイン一括更新・大きな画像のアップロード処理など、一時的にメモリを多く使う場面）に許可する上限。通常はWP_MEMORY_LIMITより大きい値を設定する
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
この上限を超えると、PHPは処理を強制終了し、「Allowed memory size of X bytes exhausted」という定型のFatalエラーを出す。これは構文エラーやロジックのバグではなく、単に割り当てられたメモリを使い切っただけのエラーであり、原因はプラグインの実装よりも「そのプラグインが要求するメモリ量に対して上限が低すぎた」ことにあるケースが少なくない。特にコア本体やプラグインの一括更新は瞬間的にメモリ消費が跳ね上がりやすい処理であり、このアプリのようにステップごとに更新してはHTTPステータスを確認する運用ツールにとって、メモリ上限超過によるFatalエラーは「更新後にサイトが500を返す」典型パターンの一つとして扱う必要がある対象になる。原因がメモリ不足であれば、対処はプラグインの入れ直しではなく WP_MEMORY_LIMIT の引き上げ（あるいはサーバー側 memory_limit の引き上げ）になる。
DISALLOW_FILE_EDIT / DISALLOW_FILE_MODS — 管理画面からのファイル操作を止める
WordPressの管理画面には、標準で「テーマファイルエディター」「プラグインファイルエディター」という、ブラウザ上から直接PHPファイルを書き換えられる画面がある。開発初期には便利だが、運用が安定したサイトでは攻撃対象領域を広げるだけの機能になりやすい。
DISALLOW_FILE_EDIT— 上記2つのエディター画面自体を管理画面のメニューから消すDISALLOW_FILE_MODS— エディター画面に加えて、管理画面からのプラグイン・テーマの新規インストール・更新・削除も一括で禁止する（より強い制限）
define( 'DISALLOW_FILE_EDIT', true );
ここで押さえておきたいのは、この定数が制限しているのはあくまで「管理画面（wp-admin）を経由したファイル操作」だという点である。SSH接続やWP-CLIのようにサーバーのファイルシステムへ直接アクセスする経路は、この定数の制限を受けない。実際、このアプリを含むSSH/WP-CLIベースの保守運用では、プラグイン・テーマ・コア本体の更新はすべてサーバー側でWP-CLIコマンドとして実行しており、管理画面のファイルエディター機能を最初から使わない。そのため DISALLOW_FILE_EDIT を有効にしても運用上の支障はなく、むしろ「管理画面経由の意図しないファイル書き換え」という経路を一つ塞いでおける、実利のある設定という位置付けになる。
まとめ
| 定数 | 何をするか |
|---|---|
WP_DEBUG |
PHPの警告・通知の検出を有効にする大元のスイッチ |
WP_DEBUG_LOG |
検出したエラーを wp-content/debug.log に書き込む。これが false だとログファイル自体が存在しない |
WP_DEBUG_DISPLAY |
検出したエラーを画面に表示する。本番では false が基本 |
WP_MEMORY_LIMIT |
通常処理で使えるメモリの上限。超えると「Allowed memory size exhausted」のFatalエラー |
WP_MAX_MEMORY_LIMIT |
管理画面のメモリ集中処理（一括更新等）向けの、より高い上限 |
DISALLOW_FILE_EDIT |
管理画面のテーマ/プラグインファイルエディター画面を消す。SSH/WP-CLI経由の更新には影響しない |
DISALLOW_FILE_MODS |
エディターに加え、管理画面からのプラグイン/テーマの新規追加・更新・削除も禁止する |
wp-config.php の定数は、どれも地味で目立たない存在だが、「エラーが起きたときにログが残るか」「メモリ不足で更新が落ちるか」「管理画面からファイルを直接いじれるか」という、保守作業の現場で実際に効いてくる前提条件を決めている。トラブルシューティングに入る前に、まずこのファイルの中身を一通り確認しておくと、原因の切り分けが早くなる場面は多い。