タグアーカイブ デバッグ

PHP Warning Undefined array key value エラーの原因と直し方

WordPress で PHP 8.x 環境に移行した後、サーバーのエラーログに「Warning: Undefined array key」という警告が大量に記録されるようになった場合、最も確実な解決策は原因となっているプラグインを最新バージョンに更新することだ。この警告はいわゆる「Notice」より深刻度が一つ上の「Warning」だが、サイトの表面的な表示や動作が完全に停止する致命的なエラーではない。

PHP 8.x 環境で「Undefined array key」が頻発する根本的な原因とは

PHP 8.0 以降、コードの実行エンジンが大幅に厳格化された。以前の PHP 7.x 系では配列に存在しないキーを参照しても警告が出ずにスルーされたが、PHP 8.x では「Undefined array key」という警告が発生する。WordPress のプラグインを一手に引き受ける制作会社や個人開発者の視点では、これは「昔のコードの書き方が許されなくなった」状態といえる。

具体的には、配列のキーを直接参照するコードが原因だ。例えば、$field['value'] のように配列のキーを直接指定すると、そのキーが存在しない限り例外や警告が出る。今回の「lib-widget-fields.php」のように、ウィジェット側で「value」キーを出力する仕様になっていないのに、テンプレート側でそれを読み込もうとすると、PHP の厳格な構文チェックに引っかかる。

エラーログを止める最も確実な方法「プラグインのアップデート」

WordPress で「Undefined array key」が特定のプラグイン（たとえば Directorist のようなディレクトリ系テーマ・プラグイン）で発生する場合、最優先で行うべきはそのプラグインのアップデートだ。成熟したプラグインであれば、開発チームがすでにコードを修正し、PHP 8.x 向けに配列キーの存在チェックを追加した新しいバージョンをリリースしている可能性が高い。

管理画面の「ダッシュボード」→「更新」画面から手動で更新するか、利用しているプラグインの公式サイトで最新バージョンがリリースされていないか確認する。自動更新が無効になっていると、修正パッチが適用されずにいつまでもエラーログが肥大化し続ける。サイトヘルス画面やサーバーのディスク容量を圧迫する前に手を打つべきだ。

すぐに警告を非表示にする「wp-config.php」の設定変更

プラグインの更新がまだ提供されていない、または何らかの理由で更新できない事情がある場合、サーバー設定ファイル wp-config.php を調整して警告を非表示にできる。ただしこれはあくまで対症療法であり、根本的なコードの修正ではないことを理解しておきたい。本番環境では、エラーを画面に表示させず、ログだけに記録する設定が原則だ。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

上記の設定により、PHP の警告は画面に表示されなくなるが、/wp-content/debug.log には引き続き記録される。完全にログ出力自体をやめたい場合は WP_DEBUG を false にするが、別の問題が起きたときに原因究明が遅れるため、ログへの記録は有効にしたまま画面への表示を切る方法が現実的だ。

緊急時の応急処置としてコードを直接修正する

プラグインのアップデートがいつになるかわからず、かつデバッグ表示オフではカスタマイザー上での操作に支障が出るなどワークフロー上の問題がある場合、最終手段としてプラグインのソースコードを直接修正する手がある。

具体的には、配列のキーを読み込む前に、そのキーが存在するかチェックするか、PHP 7.0 から導入された Null 合体演算子（??）を使ってデフォルト値を与える。先の例でいえば、$field['value'] という部分を $field['value'] ?? '' に書き換えれば、キーが存在しない場合は空文字が代入され、警告は出なくなる。

この作業は必ず「FTP を使えるか」「バックアップが取れるか」という前提の下で行う。くれぐれも子テーマで上書きできる範囲の関数であれば function.php に記述するべきだが、プラグインのコアファイルは直接触らざるを得ない。修正後はそのプラグインの自動更新を一旦停止し、公式の修正版がリリースされたら必ず元に戻してアップデートする手順を徹底する必要がある。

よくある質問

このエラーはサイトを完全に停止させる致命的なエラーですか

多くの場合、これは「Warning（警告）」であり、サイトの表示が真っ白になるような「Fatal error（致命的エラー）」とは性質が異なる。サイトは表示され続けるが、サーバーのエラーログファイルが短期間で肥大化する原因になる。また、管理画面のウィジェット設定画面やカスタマイザーでレイアウトが崩れたり、意図しない文字列が出力される可能性はある。

WP_DEBUG を false にすれば解決しますか

WP_DEBUG を false にすれば、エラーメッセージが実際のサイト画面やログファイルにすら出力されなくなる。しかしこれは「警告を見えなくした」だけであり、コードの潜在的な問題が解決したわけではない。PHP 8.x における動作が保証されていないコードを放置することになるため、開発環境ではログを取りつつ、本番環境では画面表示を切るという運用が基本になる。

エラーログの場所がわかりません

WP_DEBUG_LOG が true の場合、通常は /wp-content/debug.log に出力される。サーバーのコントロールパネル（cPanel など）に「エラーログ」機能がある場合はそちらにも記録される。FTP でアクセスしても見つからない場合は、wp-config.php で WP_DEBUG_LOG が正しく定義されているか、ファイルの書き込み権限があるかを確認する。

さくらインターネットやエックスサーバーで PHP 8.3 に変更したらこのエラーが出ました

国内の主要レンタルサーバーでは、管理画面から PHP のバージョンを簡単に切り替えられる。PHP 7.4 から 8.3 へ一気に上げると、旧式のコードを抱えたプラグインやテーマが一斉に警告を出すことがある。切り替え前にローカルやステージング環境で動作確認を行うのが理想だが、もし本番環境で出てしまった場合は、まずプラグインの一括更新を試し、それでも直らないものだけ個別に開発元へ報告するのが現実的な対処法だ。

functions.php でエラーの轍を消せませんか

残念ながら、特定のプラグインが内部で無造作に配列を直接参照している場合、テーマの functions.php からその挙動を直接上書きしてなかったことにはできない場合が多い。プラグインのコードに isset() などが欠如しているならば、前述の通りプラグインファイル自体を修正するか、プラグインのフックが用意されていればそれで値を事前に定義するなどの手段を取る必要がある。

この記事のポイント

• 「Undefined array key」は PHP 8.x で厳格化された構文チェックが原因
• プラグインを最新バージョンに更新することで根本解決する
• 一時しのぎには wp-config.php で WP_DEBUG_DISPLAY を false に設定する
• Null 合体演算子（??）を用いたコード修正は応急処置であり、アップデートで上書きされる前提で行う
• エラーログの肥大化を防ぎつつ、開発元へ報告することで結果的にエコシステム全体が改善される

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

www.aandgweb.co.jp

WordPressエディタが真っ白になる原因と直し方

管理画面のブロックエディタを開いた際に編集エリアが完全に白紙になる主な原因は、プラグインやテーマの競合、または PHP の致命的エラーだ。まず標準テーマへの切り替えと全プラグインの無効化で原因を特定し、それでも解決しない場合はデバッグモードでエラーログを確認する。

エディタ画面が真っ白になる根本的な原因

WordPress のブロックエディタ（Gutenberg）で編集画面を開いたときに真っ白なページしか表示されない現象は、大きく分けて 2 つの原因で発生する。1 つはプラグインやテーマの競合、もう 1 つは PHP の致命的エラー（「このサイトで重大なエラーが発生しました」と表示される類のもの）だ。

ブロックエディタは JavaScript を多用する高度な画面であり、複数のプラグインが読み込むスクリプト同士で競合が起きると、画面の描画が完全に停止してしまう。またテーマが古い jQuery や独自のエディタ拡張をロードしている場合も、エディタの初期化処理と衝突して空白画面を引き起こす。

PHP の致命的エラーが原因の場合は、エディタ画面そのものが生成される前に処理が中断されている状態だ。たとえばメモリ不足や、特定のプラグインが要求する PHP 拡張機能の不足、あるいは functions.php に記述された独自コードの文法ミスなどが該当する。こうしたエラーは管理画面全体に影響する場合もあるが、投稿編集画面だけが重い処理を要求するタイミングで発覚することも多い。

プラグインとテーマの競合を切り分ける手順

まず最初に試すべきは、プラグインの全無効化と標準テーマへの切り替えだ。この手順だけで多くの白紙エディタ問題は解決する。管理画面にアクセスできる状態であれば、以下の流れで原因を特定できる。

Health Check プラグインで訪問者に影響を与えずに調査する

本番サイトでプラグインを一括無効化すると、訪問者に見えているサイトのレイアウトが一時的に崩れるリスクがある。プラグイン「Health Check & Troubleshooting」を導入すれば、自分がログインしている間だけプラグイン無効化とテーマ切り替えが適用され、一般の訪問者には通常通りの表示が保たれる。

「Health Check & Troubleshooting」は WordPress.org の公式プラグインディレクトリから無料でインストールできる。有効化後に「トラブルシューティング」タブを開き「トラブルシューティングモードを有効にする」ボタンを押すだけで、安全に調査を開始できる。特定のプラグインだけを個別に再有効化しながら編集画面の挙動を確認できるため、競合元の絞り込みに非常に有効だ。

テーマの functions.php が原因になるケース

標準テーマに切り替えた途端にエディタが正常化した場合、それまで使っていたテーマ（あるいは子テーマ）の functions.php に問題がある可能性が高い。よくあるのは、エディタ向けのカスタムスタイルやブロック追加のコードが WordPress のバージョンアップ後に非推奨の関数を使い続けているケースだ。

functions.php の中で add_action('enqueue_block_editor_assets', ...) や add_filter('block_editor_settings_all', ...) を使ってエディタに介入している箇所があれば、それらを一旦コメントアウトして様子を見ると原因の切り分けになる。

デバッグモードでエラーログを取得する

プラグインとテーマの切り分けでも解決しない場合、PHP の致命的エラーが発生している可能性が高い。画面には何も表示されないが、裏側でエラーが起きている。そこで WordPress のデバッグモードを有効にして、エラーログをファイルに記録させる。

wp-config.php にデバッグ定数を追加する

FTP やレンタルサーバーのファイルマネージャーでサーバーに接続し、WordPress のルートディレクトリにある wp-config.php を編集する。ファイル末尾の /* That's all, stop editing! */ よりも手前に、以下の 3 行を追加または上書きする。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG を true にするとデバッグモードが有効になる。WP_DEBUG_LOG を true にすると、エラーの内容が /wp-content/debug.log ファイルに出力される。WP_DEBUG_DISPLAY を false にしておけば、エラーが画面に表示されず、訪問者にも影響が出ない。

設定後に問題のエディタ画面を再度開き、その後 /wp-content/debug.log をテキストエディタで開く。PHP のエラーメッセージが記録されていれば、どのファイルの何行目で問題が起きているかが具体的にわかる。たとえば「Allowed memory size of 〜 bytes exhausted」ならメモリ不足、「Call to undefined function 〜」なら関数の未定義が原因だと絞り込める。

ブラウザの開発者ツールで JavaScript エラーを確認する

PHP のエラーログに何も記録されていない場合、JavaScript の実行時エラーが原因でエディタが空白になっている可能性が高い。この場合はブラウザの開発者ツールを使う。

Chrome の場合、編集画面を開いた状態でキーボードの F12 キーを押して開発者ツールを起動し、「Console」タブを選択する。赤いエラーメッセージが表示されていれば、それがエディタの読み込みを止めている原因だ。Uncaught TypeError や Uncaught ReferenceError のようなエラーが出ていれば、特定のスクリプトが正しく動作していないことを示している。

エラーの内容にプラグイン名やテーマ名が含まれていることが多いため、そのプラグインを無効化すれば問題が解決する。コンソールにエラーが一切出ていない場合は、REST API の通信が遮断されているケースが疑われる。開発者ツールの「Network」タブで、wp-json を含むリクエストが赤く表示されていないか確認する。401（認証エラー）や 403（禁止）が返っている場合は、セキュリティプラグインやサーバー側の WAF（Web アプリケーションファイアウォール）が REST API をブロックしている可能性が高い。

よくある質問

プラグインを無効化する管理画面すら真っ白で開けない場合はどうするのか

FTP またはレンタルサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリにアクセスし、プラグインフォルダを一時的に別の名前にリネームする。たとえば plugin-name を _plugin-name に変更すれば、WordPress はそのプラグインを認識しなくなり、管理画面にアクセスできるようになる。

特定のページだけエディタが真っ白になるのはなぜか

特定のページに埋め込まれたショートコードやブロックが、対応するプラグインの JavaScript エラーを引き起こしている可能性が高い。またページのリビジョン数が極端に多い場合も、エディタの読み込みが重くなりタイムアウトすることがある。リビジョンを整理するか、該当ページを複製して編集し直すと改善する場合がある。

ブラウザを変えても同じ症状か確認したほうがよいか

確認する価値はある。まれにブラウザの拡張機能（特に広告ブロッカーやセキュリティ系）がブロックエディタのスクリプトを遮断しているケースがある。シークレットウィンドウや別のブラウザでログインして編集画面を開き、同じ症状が出るかどうかを見ると、ブラウザ側の要因かどうかを切り分けられる。

WordPress 本体の再インストールは効果があるか

コアファイルの破損が疑われる場合に限り効果がある。管理画面の「ダッシュボード」→「更新」から「WordPress を再インストール」を選ぶと、コアファイルだけがクリーンな状態に置き換わる。テーマやプラグイン、データベースには影響しないため、手軽に試せる。ただしプラグインの競合や PHP エラーが原因の場合は再インストールしても改善しない。

編集画面が真っ白な状態で記事を更新する応急的な方法はあるか

ブロックエディタが使えない場合の回避策として、クラシックエディタプラグインを有効化する方法がある。旧式の編集画面に切り替わるため、JavaScript の競合の影響を受けにくい。根本解決ではないが、急ぎの更新作業が必要な場合の一時的な回避策として使える。また「QuickPost」のような外部ツールを使う方法もあるが、環境に依存するため万能ではない。

この記事のポイント

• エディタの白紙はプラグイン/テーマ競合か PHP エラーが主因
• 全プラグイン無効化と標準テーマ有効化で原因を切り分ける
• Health Check プラグインで訪問者に影響なく調査できる
• wp-config.php のデバッグ設定でエラーログを取得する
• ブラウザの開発者ツールで JavaScript エラーも確認する

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている