WordPress のブロックエディターが読み込まれないときの直し方
ブロックエディターが読み込まれない原因の多くは JavaScript エラーです。プラグインやテーマの壊れたスクリプトが 1 つあるだけで React アプリ全体が止まり、エディターは最後まで描画されません。
公開
WordPress のブロックエディターが読み込まれない原因は、たいていの場合 JavaScript エラーです。プラグインやテーマの壊れたスクリプトが 1 つあるだけで React アプリ全体が止まり、エディターは最後まで描画されません。ブラウザの開発者コンソール（F12、Mac なら Cmd+Option+I）を開き、編集画面を再読み込みして、赤いエラーを読んでください。ほぼ必ず、例外を投げたファイル名が表示されます。その 1 行を見れば、どのプラグインを無効化すればよいかがわかり、たいていは 5 分もかからずに執筆へ戻れます。ネット上でよく勧められる「WordPress を再インストールする」「PHP の memory_limit を上げる」「Classic Editor に切り替える」という 3 つの対処法は、どれもたいてい見当違いです。
なぜエディターはこういう壊れ方をするのか
ブロックエディター（Gutenberg）は、wp-admin/post.php と post-new.php の中で動くシングルページの React アプリケーションです。WordPress は wp-blocks、wp-element、wp-editor、wp-edit-post といったスクリプトパッケージ群を読み込み（enqueue）、アプリは wp.domReady() を通じて起動します。JavaScript は、キャッチされない例外が最初に発生した時点で実行を停止します。そのため、エディターの初期化中に読み込み済みのスクリプトのどれか 1 つでも例外を投げると、それ以降の処理がすべて道連れになって止まります。丹念に用意した投稿エリアは、真っ白なペインか、「エディターで予期しないエラーが発生しました」というメッセージに崩れ落ちます。
さらに WordPress は、デフォルトで管理画面のスクリプトを連結（concatenate）してリクエスト数を減らします。つまり、あるプラグインの壊れた JS が、同じバンドルに含まれる無関係なスクリプトまで巻き込んで落とすことがあり、これが挙動だけを見ても犯人が特定しづらい理由です。コンソールを見れば特定できます。
2 つ目の壊れ方は見た目が異なります。エディターは読み込まれるのに、保存しようとすると「更新に失敗しました。返答が正しい JSON レスポンスではありません。」というエラーが出るのです。これは JavaScript の問題ではありません。エディターは /wp-json/wp/v2/ の REST API と通信しており、きれいな JSON が返ってくることを期待しています。プラグインやテーマの functions.php が JSON の 前に PHP の notice、warning、fatal を出力したり、セキュリティプラグインが REST ルートをブロックしたり、リダイレクト系プラグインが URL を書き換えたりすると、レスポンスが汚染されてエディターがパースできなくなります。
直し方（速い順に）
1. コンソールを読む。 DevTools を開いた状態で不具合を再現します。Uncaught TypeError ... some-plugin/build/index.js のようなエラーは、問題を起こしているプラグインをそのまま指し示しています。この 1 ステップだけで大半のケースは解決し、当てずっぽうの切り分け作業をせずに済みます。
2. ブラウザ側を除外する。 スーパーリロード（Cmd/Ctrl+Shift+R）を実行し、拡張機能を無効にしたシークレットウィンドウで試します。広告ブロッカーやプライバシー系拡張機能が、まれに管理画面のスクリプトを取り除いてしまうことがあります。シークレットウィンドウで動くなら、原因はブラウザ拡張機能か古いキャッシュであって、サイト側ではありません。
3. REST API を直接確認する。「正しい JSON レスポンスではありません」というメッセージを見た場合は、ブラウザで https://yoursite.com/wp-json/ にアクセスします。ずらりと並んだ JSON が返ってくるはずです。もし HTML や 500 エラー、ログイン画面へのリダイレクトが返ってきたら、それがバグです。エディター自体ではなく、あるプラグインが REST レスポンスを壊しています。
4. プラグインを切り分ける。 いったんすべて無効化してエディターが読み込まれることを確認し、そこから 1 つずつ有効化して、再び壊れるまで進めます。wp-admin に完全にログインできなくなっている場合は、SFTP でフォルダ名を変更して行います。
mv wp-content/plugins wp-content/plugins_offフォルダが消えると WordPress はすべてのプラグインを無効化します。名前を元に戻したうえで、プラグインを 1 つずつ出し入れしてください。
5. テーマを検証する。 Twenty Twenty-Four に切り替えます。壊れたエディター用 JS を読み込むテーマや、functions.php で PHP エラーを投げるテーマも、同じ症状を引き起こします。
6. ログを有効にして本当のエラーを読む。 特に REST/JSON 系の不具合については、wp-config.php でデバッグを有効にします。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );fatal エラーは、正確なファイル名と行番号とともに wp-content/debug.log に書き出されます。そのスタックトレースが読みづらい場合（名前空間付きのクラス名、require の連鎖、トレース 10 行の下に埋もれた fatal など）は、WordPress error log decoder に貼り付けてみてください。実際にどのプラグインの何行目が引き金になったのかが、平易な言葉でわかります。これが「何かが壊れている」と「このプラグインの 214 行目が壊れている」の違いです。
スクリプトの連結が本当の犯人を隠していると疑われる場合は、各スクリプトを個別に読み込ませて、コンソールのエラーがちょうど 1 つのファイルを指すようにします。
define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );やってはいけないこと
Classic Editor プラグインを入れて「直った」ことにしない。 これは何も直していません。ブロックエディターを隠して、エラーが見えなくなるだけです。壊れた JavaScript や壊れた REST レスポンスはそのまま残り、サイトエディター、ウィジェット、あるいは次のアップデートのときに再びあなたを苦しめます。まず原因を突き止めましょう。Classic に切り替えるのは、ブロックの使用をやめると意図的に判断した場合だけにしてください。
反射的に PHP の memory_limit を上げない。 ネットで最も好まれるコピペ対処法ですが、真っ白なエディターがメモリ不足であることはめったにありません。本当のメモリ枯渇なら、「Allowed memory size of N bytes exhausted」という specific な fatal が投げられ、それは debug.log に表示されます。その行が無いなら、メモリを増やしても何も変わりません。
WordPress のコアを再インストールしない。 コアファイルはどのインストール環境でもバイト単位で同一です。もしコアが問題なら、今この瞬間、世界中のすべての WordPress サイトのエディターが壊れているはずです。原因はほぼ必ずプラグインかテーマにあり、コアの再インストールは何も直さないまま、いろいろなものを上書きしてしまうリスクがあります。
最初の手として、やみくもにキャッシュプラグインをクリアしたり無効にしたりしない。 過度な JS の minify や連結がエディターを壊す こともある ので、検証する価値はあります。ただし、手当たり次第にキャッシュを飛ばす前に、まずコンソールを確認してください。当てずっぽうこそが、5 分で済む修正を半日仕事に変える原因です。
それでも解決しないときは
コンソールがきれいで、REST API が正しい JSON を返し、プラグインとテーマを完全に切り分けてもエディターが死んだままなら、答えはほぼ確実に debug.log の中にあります。WP_DEBUG_LOG を有効にし、不具合を一度再現させて、出てきた fatal を error log decoder にかけてください。スタックトレースがファイル名を教えてくれます。そこから始めましょう。