Amazonで商品を見る セール会場へ

WordPress│PHPバージョン更新時に注意すべきエラーとエラーログの確認方法

PHPを切り替える前にファイルとDBをバックアップし、現在のPHPバージョンと戻し方を記録します。デバッグはまずコピー環境で行います。本番で必要な場合は短時間に限定し、ログを外部へ公開しない保存先・アクセス制限を先に確認してください。

WordPressのダッシュボードにPHP更新の通知が出たときは、現在のバージョンと、切り替え候補のバージョンをサーバー管理画面で確認します。

WordPressのダッシュボードに表示されたPHPの更新を推奨する通知。

切り替え先でテーマやプラグインが動くかは、実際の構成をコピーして確かめます。

PHPのサポート期間と、利用中の製品が対応するバージョンは別の確認項目です。

サーバーの「推奨」という表示だけで互換性を判断せず、PHP公式のサポート期間と、テーマ・プラグインの対応情報を照合してください。

PHPのバージョン選択画面で推奨と記載された項目を選ぶ様子。

画面に出ない警告もあるため、切り替え前後に同じ操作を行い、同じ時間帯のログを比較します。

この記事では更新前後の確認順と、ログを出す設定を説明します。

目次

著者

WEB制作をしているデジタルノマド
WordPressのカスタマイズが好きで、色々と自作しています。

WordPressのカスタマイズに困ったらご相談ください!

PHP切り替え前後の確認順

ファイルとDBのコピー環境に、テーマ・プラグインのバージョン、PHP拡張、関連設定を揃えます。

まず現在のPHPで同じ操作の結果とログを保存し、そのコピーを候補のPHPへ切り替えて比較します。

エラーがあれば直前の変更を戻し、修正後に同じ操作を再確認します。

本番へ反映する前に元のPHPへ戻す手順を確認します。

画面が開くだけで更新完了とはせず、必要な操作と新しく増えたログを確認してください。

エラーログの出力方法

FTPなど管理用の接続でWordPressのファイルへアクセスします。

対象のWordPressが入っているディレクトリのwp-config.phpを確認します。

public_html直下とは限らず、複数サイトがある場合は編集対象を間違えないようにします。

FTPでアクセスしたフォルダ内にある設定ファイルを確認する様子。

こちらのwp-config.phpファイルをテキストエディタ等で開きます。

既存のWP_DEBUGがfalseならその行を編集し、WP_DEBUG_DISPLAYとWP_DEBUG_LOGも既存の定義を確認して置き換えます。

define( 'WP_DEBUG', true );             /* デバッグモード有効化 */
define( 'WP_DEBUG_DISPLAY', false );    /* ブラウザに表示しない */
define( 'WP_DEBUG_LOG', true );         /* wp-content/debug.log に記録 */
デバッグログを出力するために書き換えた設定ファイルの記述内容。

切り替え前後に、記事表示、ログイン、編集・保存、使用中のフォームやREST APIなど、サイトで必要な操作を同じ条件で確認します。

標準の保存先は通常wp-content/debug.logです。

ファイルが存在するだけでは今回の不具合とは判断できません。

再現操作の時刻以降に追加された行と、HTTPステータス・画面の症状を照合します。

種類確認する内容優先度
Parse error / Fatal error構文・例外・未定義の処理など。発生時刻と停止箇所を調べる処理停止や500エラーを先に復旧する
Warning / Notice原因はメッセージごとに異なる。ログの種類だけで原因を決めない対象操作への影響を再現して判断する
Deprecated使用中の非推奨機能と切り替え先の互換性置き換え計画とログ増大を確認する

Fatal errorやParse errorで処理が止まる場合を先に調べます。

WarningやDeprecatedはメッセージと発生箇所を読み、現在の症状との関係を確認します。

ログの保存先や非公開化の詳しい手順は、画面へ表示せずにデバッグログを記録する方法を参照してください。

ログが出ない場合と調査後の戻し方

wp-config.phpの既存の同名定数を編集し、重複してdefineしないでください。設定はwp-settings.phpを読み込む行より前に置きます。WP_DEBUG_LOG=trueは通常wp-content/debug.logへ保存するため、公開URLから取得できないようサーバー側で制限します。必要ならホストが指定する公開領域外の絶対パスをWP_DEBUG_LOGへ指定します。ブラウザ非表示だけではログファイルの公開は防げません。

ログがないだけでは正常と断定できません。再現操作の時刻、書き込み権限、保存先、サーバーのPHPエラーログを確認します。Fatal errorやParse errorで処理が止まる場合を優先し、Notice・Warning・Deprecatedも内容と発生箇所で判断します。ログを共有する前に個人情報・パス・トークンを伏せてください。

調査後はWP_DEBUGとWP_DEBUG_LOGをfalseへ戻し、WP_DEBUG_DISPLAYはfalseのままにします。取得済みログもアクセス制限した場所へ保管します。PHP更新後に障害が起きた場合はホストの手順で元のPHPへ戻し、必要に応じて変更前バックアップから復旧します。

WordPress公式のデバッグ手順で各定数の役割を確認できます。

今回確認したログ出力の範囲

2026年10月3日、隔離したPHP 8.2.29で、掲載の定数とWordPress 7.1.2のログ初期化処理を実行しました。

警告は画面に出ずログへ記録されました。

ログ設定の読み込み前に構文エラーで停止した場合は、HTTP 500とサーバー側のPHPログで確認できました。

非公開の保存先のログは公開URLから取得できませんでした。

これはログ設定の動作確認です。

PHPの別バージョンへの更新、テーマ・プラグインの互換性、実際の編集画面やフォーム操作の検証は含みません。

  • URLをコピーしました!

設定に不安があるなら

WordPressのセキュリティ対策・保守

セキュリティ設定¥20,000〜、定期自動バックアップの設定¥15,000〜、保守・メンテナンスは月額 ¥15,000〜(税込)。ファイアウォールやSSLの導入もまとめて対応します。

WAZAの有料記事のサブスクリプションも開始しました。

目次