PHPを使っていて「なんでエラーが表示されないのか分からない」と悩んだことはありませんか。その原因は設定忘れや環境依存、WordPressのデバッグモードなど多岐にわたります。この記事では「PHP エラー表示 されない」という現象について、原因から確認するポイント、具体的な対処法を網羅的に解説します。最新情報に基づいているので、すぐに解決策として使えます。
PHP エラー表示 されない 状況とその原因
PHPでエラーが表示されない状況は様々です。サーバー設定、PHPの設定、スクリプトの書き方、WordPressのデバッグモードなどが影響します。まずは発生しやすい状況と、なぜ表示されないかを理解することがトラブル解決の第一歩です。以下で代表的なケースを整理します。
サーバー側の設定で display_errors が無効になっている
PHPの設定ファイル（php.ini）で display_errors が Off にされていたり、共有ホスティング環境でその指令が上書きされていると、エラー表示は行われません。設定を変更している php.ini が実際に読み込まれていないケースや、別の設定ファイルが優先されているケースもあります。display_errors の有効化と phpinfo を使って読み込まれている設定ファイルを確認することが重要です。
error_reporting のレベルが低いため NOTICE や WARNING が除外されている
error_reporting が E_ALL 以外や NOTICE／WARNING を除外する設定だと、小さな警告や注意メッセージが表示されません。これにより「エラーはあるはずだが何も見えない」と感じることがあります。開発環境では E_ALL の設定が望ましく、本番環境では重要エラーのみをログに残す等の工夫が必要です。
PHP の起動時エラー（startup エラー）が display_startup_errors により隠れている
PHP の起動処理で発生するエラーは、スクリプト内で ini_set を使っていたとしても捕まえることができません。display_startup_errors の設定が Off のままだと、モジュール読み込み失敗などの初期段階でのエラーが表示されません。PHP 8.0 以降、デフォルトで On になったものの、古いバージョンや独自設定がある環境では注意が必要です。
スクリプト内で ini_set や error_reporting が上書きされている
テーマやプラグイン、あるいは自作コードで ini_set(‘display_errors’,0) や error_reporting(0) が実行されていると、先に設定した表示設定が無効化されます。特に WordPress のテーマの functions.php や mu-plugin 等にこうしたコードがあるケースが多く、どこで上書きされているかを探すことが重要です。
コードに構文エラーがあり、そのファイルで設定が実行されない
ファイルに syntax error があると、そのファイル内の ini_set や error_reporting の設定行が見つかっても実行されず、エラー表示が行われません。つまりそのファイルがコンパイル段階で停止してしまうためです。構文を確認するために、php -l コマンドや IDE のエディタ機能を使うことが有効です。
WordPress のデバッグ定数が無効または誤設定である
WordPress には WP_DEBUG、WP_DEBUG_DISPLAY、WP_DEBUG_LOG といった定数があり、それらの設定によってエラー表示やログの出力が制御されます。デフォルトでは WP_DEBUG は false、WP_DEBUG_DISPLAY は true とされていますが、WP_DEBUG が false のままだと表示されません。これらが正しく設定されているかを wp-config.phpで確認する必要があります。
確認すべき設定と優先順位
エラー表示されない問題を解決するためには、どの設定をどの順番で確認すべきかを知ることも非常に重要です。ここでは確認チェックリストを挙げ、それぞれの意味と優先度を解説します。文章は設定項目ごとに具体的な手順と留意点を含めています。
php.ini の display_errors と display_startup_errors を確認する
最初に行うべきは php.ini の中にある display_errors と display_startup_errors の設定を確認することです。display_errors を On にすることで通常のエラー表示が可能になります。display_startup_errors は PHP の立ち上げ時のエラー制御を行うもので、初期モジュールの読み込み失敗等を表示したい場合に On にします。設定変更後はウェブサーバーや PHP-FPM の再起動が必要です。
error_reporting レベルを最高に設定してみる
error_reporting 設定を E_ALL（全種類のエラー、警告、注意を含む）に設定することで、通常見えない NOTICE や WARNING 等も表示されます。これは php.ini 内の設定でも、スクリプト内で error_reporting(E_ALL) を使うことでも可能です。開発中はこの設定を用い、後で不要なものを除外する手順を取るとよいでしょう。
WordPress の WP_DEBUG 系定数を追加または修正する
WordPress 環境であれば、wp-config.php ファイル内で次のような定数を設定します。まず define(‘WP_DEBUG’, true) にし、その上で WP_DEBUG_DISPLAY を true に設定します。ログを取るなら WP_DEBUG_LOG を true にするなど用途に応じて設定します。開発環境ではこれで画面上にエラーが表示されるようになります。
.htaccess や web server 設定で php_flag 指令などを確認する
Apache を使っている環境では .htaccess に php_flag display_errors Off といった設定がされていないかをチェックします。Nginx や PHP-FPM の場合は FastCGI 設定やプール設定で display_errors を制御していることがあります。サーバーのホスティングコントロールパネルで設定の override がないかどうかも確認します。
スクリプト内の設定箇所と構文エラーの有無を確認する
スクリプトファイルの先頭近くで error_reporting と ini_set を設定しているか、また構文エラーがないかを確認します。構文エラーが先に出てくると、その後の ini_set は実行されず、エラー表示がされない原因になります。IDE やコマンドラインでの文法チェックが有効です。
phpinfo() を使って実際の設定値と読み込まれているファイルを確かめる
phpinfo() 関数を使い、Loaded Configuration File がどこか、display_errors の local と master 値がどうなっているかを確認します。shared hosting や PHP-FPM プールの追加設定ファイルが読み込まれている環境では、この情報が重要です。phpinfo の表示結果から、それらが意図通りかどうかを判断できます。
具体的な対処法：表示されない場合の修正手順
原因がどこにあるかを特定できたら、具体的な対処法を順番に試していくと効率的です。ここでは代表的な修正手順を提示します。WordPress 環境でも汎用 PHP 環境でも使える方法を含めています。
php.ini を編集して display_errors を On、error_reporting を E_ALL にする
サーバー管理者又はホスティングのコントロールパネルを通じて php.ini を編集します。設定内容は以下のようになります。
display_errors = On
display_startup_errors = On
error_reporting = E_ALL
変更後は Apache や PHP-FPM を再起動する必要があります。再起動しないと設定が反映されません。
WordPress の wp-config.php にデバッグ設定を追加する
WordPress 環境であれば wp-config.php に以下のような設定を記述します。
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);
define('WP_DEBUG_LOG', true);
@ini_set('display_errors', 1);
@ini_set('display_startup_errors', 1);
この設定を /* That's all, stop editing! Happy blogging. */ より前に書くことが大事です。位置が後だと上書きされる可能性があります。
.htaccess や PHP-FPM 設定で display_errors を制御している場合の対処
Apache を使っている場合、.htaccess に php_flag display_errors On のような記述があるかどうか確認します。もし Off になっていれば On に変更します。PHP-FPM プール構成ファイルに display_errors を設定する指令があれば、それも確認します。また共有ホスティングではユーザー .user.ini ファイルやコントロールパネル上で設定可能な場合があります。
構文エラーのチェックとコードの分割
構文エラーがあると設定行が機能しません。対象ファイルを小さく分割し、疑わしい箇所で一時的にエラーを発生させて表示されるかを確認します。エディタで構文チェック、コマンドラインで php -l を使うのが便利です。また BOM や不正な文字列、文字コードの問題も構文エラーの原因になることがあります。
ログファイルを確認する
表示されないエラーを確認するために、error_log のファイルを確認します。WordPress なら wp-content/debug.log に、PHP 一般では php.ini の error_log に設定されている場所に記録されます。ログファイルが書き込み可能であるか、ディスク容量やアクセス制限に問題ないかもチェックしてください。
WordPress 特有の注意点と最新動向
WordPress を使っている場合には独自の設定や制約があります。ここでは最新の WordPress の仕様や慣習から「PHP エラー表示 されない」問題に影響する特有のポイントを解説します。WordPress の動きに詳しい専門家の知見にもとづいています。
WP_DEBUG の既定値と環境タイプ
WordPress では本番環境（production）では WP_DEBUG が false に設定されており、開発環境では true にするのが基本です。環境タイプが staging や development の場合、WP_DEBUG が自動的に true になるケースもあります。環境タイプが production になっていると、画面にエラーを表示しない設定が優先されるため、まず環境タイプを確認することが重要です。
WP_DEBUG_DISPLAY と AJAX／REST／XML-RPC リクエスト
WP_DEBUG_DISPLAY を true にしていても、AJAX や REST API、XML-RPC リクエスト時にはデフォルトで画面表示が抑制されます。エラーはログに記録されますが、ブラウザ上には表示されません。こうしたリクエストでエラーを追いたい場合は curl やブラウザのデベロッパーツールを使うか、ログを参照する必要があります。
display_startup_errors のデフォルト値と PHP 8 系での変更
PHP 8.0 以降、display_startup_errors がデフォルトで On になりました。これはモジュールの読み込み時のエラーなどがより明確に見えるようになった改善です。それ以前のバージョンでは起動時エラーが隠されることが多かったため、PHP のバージョンを確認してこの設定がどうなっているかを把握するのが大切です。
共有ホスティングでの制限と override による影響
多くの共有ホスティング環境では、php.ini の設定が上書きできないようになっていたり、display_errors を制御する指令が無効化されていたりします。さらに php.ini より優先順位の高い .htaccess や user.ini、PHP-FPM のプール設定が影響して表示が抑えられることがあります。ホスティングの仕様をよく確認し、必要ならサポートに問い合わせることも選択肢です。
まとめ
「PHP エラー表示 されない」という問題は、設定ファイル、PHP のバージョン、WordPress の定数、スクリプト内での上書き、構文エラーなど多くの原因が重なり合って発生します。まずは環境と設定の確認から始めて、小さなステップで原因を切り分けることが肝心です。display_errors や error_reporting 設定の見直し、コードの構文チェック、WordPress の WP_DEBUG 関連定数の把握などを順に試してください。エラーのログもチェックすることで、画面には出ない問題の把握につながります。
コメント