WordPress 7.1で投稿編集画面が真っ白に｜原因はテーマではなくブロック追加系プラグインだった【実例と4つの対処法】

WordPress 7.1に更新した翌日、複数のサイトで「投稿の編集画面を開くと真っ白で何も表示されない」という現象に見舞われました。新規投稿も既存記事の更新もできず、記事が書けない状態です。サイトの表示自体は正常なので訪問者には何の影響もないのですが、運営側からすると手も足も出ません。

厄介だったのは、発生するサイトと発生しないサイトがあり、しかもその境目が一見するとテーマの違いに見えたことです。最初は「テーマが7.1に対応していないのだろう」と考えたのですが、ブラウザの開発者ツールでコンソールを開いたことで話が一変しました。真犯人はテーマではなく、たまたま両方のサイトに入っていた1つのプラグインだったのです。

この記事では、WordPress 7.1で何が変わったのかを整理したうえで、実際に原因をコード1行まで特定した手順と、4つの対処法を紹介します。同じ症状で困っている方は、対処法の章から読んでいただいても構いません。そして重要なのは、これは特定のプラグインだけの問題ではなく、ブロックを追加する系統のプラグイン全般で起こりうるという点です。

発生した症状

まず、どんな状態だったのかを整理します。

• 投稿の編集画面を開くと画面が真っ白。新規投稿も既存記事の更新も、どちらもできない
• サイトの表示(フロント側)はまったく正常。訪問者には影響がない
• 管理画面の他のメニュー(プラグイン一覧、設定など)は問題なく開ける
• クラシックエディタを使っているサイトでは発生しない
• 複数のサイトで同時に発生した。共通点はWordPressを7.1に更新したこと

「真っ白」というのは、エラーメッセージすら出ないという意味です。WordPressが「このブロックにはエラーが含まれています」といった案内を出してくれるなら話は早いのですが、今回はエディタが起動しきる前に処理が止まっているため、何の手がかりも画面に表示されません。この時点で頼れるのはブラウザのコンソールだけ、というのが今回のポイントになります。

WordPress 7.1では何が変わったのか

原因の話に入る前に、7.1という更新がどういうものだったのかを押さえておきます。WordPress 7.1「Mary Lou」は2026年8月19日にリリースされました。編集体験の強化に重点が置かれた、かなり大きめの更新です。

7.1の主な新機能(ここは素直に嬉しい)

• ネイティブなレスポンシブ設定
  CSSを書かなくても、モバイル・タブレット・デスクトップごとの見た目をエディタ上で調整できるようになりました。これまでカスタムCSSで凌いでいた部分がかなり減ります。
• ホバー・フォーカス・アクティブの状態指定
  ボタンやリンクのマウスオーバー時の色などを、コードなしで設定できます。
• 非同期コラボレーション機能
  提案モード、リッチテキストによるコメント、通知、絵文字リアクションなど。複数人で記事をレビューする運用をしている現場には大きな追い風です。
• 新しいコアブロック「Tabs」「Playlist」
  タブ切り替えUIがプラグインなしで作れるようになりました。Playlistは波形表示にも対応しています。
• パフォーマンスの改善
  クエリーループブロックの遅延読み込みとキャッシュが改善されたほか、ページキャッシュが有効な環境では投機的読み込みが既定で「中程度」になり、体感的なページ遷移が速くなります。
• クラシックブロックの存続
  2026年6月にブロック挿入ツールからの削除が決まっていましたが、この決定は撤回されました。移行途中の現場にとっては朗報です。

不具合の火種になりうる変更

一方で、7.1には既存のテーマやプラグインを壊しかねない変更もいくつか含まれています。

変更点	影響を受けやすいもの
投稿エディタの完全iframe化	独自ブロック、エディタ用CSS/JS、管理画面のDOMを直接参照する実装
Block API v2以下の非推奨化	apiVersionが2以下のまま登録されている独自ブロック
@wordpress/componentsの既定サイズが40pxに統一	エディタのサイドバーUIを拡張しているプラグイン
Navigationコンポーネントの削除	同コンポーネントを利用していたプラグイン
投機的読み込みの積極化	スペックに余裕のない共用サーバー

特に大きいのが投稿エディタの完全iframe化です。7.0までは「古いブロックAPI(v2)のブロックが含まれていればiframe化を見送る」という救済措置がありましたが、7.1でその例外が撤廃され、テーマの種類やブロックのAPIバージョンに関係なく無条件でiframe化されるようになりました。しかもオプトアウトの手段は用意されていません。

iframeは親ページとは別のdocumentとwindowを持つため、グローバルのdocumentを前提に書かれたエディタ拡張のコードは、正しい対象を掴めなくなります。7.1で編集画面まわりの不具合報告が一気に増えたのは、この変更が主因です。

原因を特定するまでの手順

ここからが本題です。実際にどうやって原因を突き止めたのかを、順を追って書きます。同じ症状に遭遇したときにそのまま使える手順です。

STEP1　発生するサイトと発生しないサイトを並べる

まず切り分けです。管理しているサイトを見渡して、症状の有無を書き出しました。この時点で見えていたのは次のような状況です。

• テーマにRE:DIVERまたはSWELLを使っているサイト → 真っ白になる
• テーマにDiverやTCDを使っているサイト → 症状なし
• クラシックエディタで運用しているサイト → 症状なし

これを見て「RE:DIVERとSWELLが7.1に未対応なのだろう」と考えるのは自然です。実際、私も最初はそう判断しかけました。しかし、この見立ては後で完全に覆ります。切り分けは強力な手法ですが、共通点を見誤ると全然違う方向に進んでしまう、という典型例でもありました。

STEP2　開発者ツールのコンソールを開く

真っ白な編集画面を開いた状態でF12キーを押し、開発者ツールの「Console」タブを選んでページを再読み込みします。これが決定打でした。

ひとつコツがあります。ブラウザの拡張機能はコンソールに大量のログを出すので、切り分けのときはシークレットウィンドウ(拡張機能オフ)で確認すると、ノイズが減って格段に読みやすくなります。私の環境でも、SEO系の拡張機能のログが延々と流れて最初は見落としかけました。

STEP3　警告(黄色)とエラー(赤)を分けて読む

コンソールには大量のメッセージが出ますが、処理を止めているのは赤い「Uncaught」から始まる行だけです。ここを見誤らないことが何より重要でした。

実際、SWELLのサイトでは次のような警告が何十行も出ていました。

Block with API version 2 or lower is deprecated since version 6.9.
Note: The block "loos/accordion" is registered with API version 2.

loosはSWELLの開発元の名前空間です。つまりこれは「SWELLのブロックがAPIバージョン2のままなので、将来のiframe化に備えて3に上げてください」というお知らせであって、エラーではありません。処理は止まっていません。ここで「やっぱりSWELLが原因だ」と早合点していたら、まったく見当違いの対応をするところでした。

そしてその大量の警告の下に、赤い行がたった1つだけありました。

index.js?ver=0.3.7:1 Uncaught TypeError:
Cannot create property '__experimentalSkipSerialization' on boolean 'true'
    at index.js?ver=0.3.7:1:37364
    at blocks.min.js:3:49988
    at Array.map (<anonymous>)
    ...
    at edit-post.min.js:3

スタックトレースの読み方も押さえておきましょう。下から上に向かって処理が進んでいるので、edit-post.min.js(エディタの起動処理)から始まり、blocks.min.jsのArray.map(全ブロックを1つずつ登録していくループ)を通って、最後にindex.js?ver=0.3.7で例外が発生している、と読めます。エディタが立ち上がりきる前に死んでいるわけで、画面が真っ白になる理由もこれで説明がつきます。

STEP4　犯人のファイルを特定する

index.js?ver=0.3.7というバージョン番号が最大の手がかりでした。テーマ本体のバージョンにしては小さすぎる数字で、明らかに別の何かです。

フルパスの確認方法は3つあります。コンソールに出ているファイル名をクリックすると「Sources」タブが開いて場所が分かります。あるいは「Network」タブでファイル名を絞り込む方法、編集画面でCtrl+Uを押してソースを表示しver=0.3.7を検索する方法でも確認できます。

そしてここで決定的な事実が判明します。RE:DIVERのサイトとSWELLのサイトで、まったく同じindex.js?ver=0.3.7が読み込まれていたのです。別々の会社が作った2つのテーマが、たまたま同じバージョン番号のファイルを持つことはまずありません。つまり犯人はテーマではなく、両方のサイトに共通して入っていたプラグインでした。

原因はDIVERブロック(DBP)プラグインだった

ファイルの中身を開いて__experimentalSkipSerializationを検索すると、問題の箇所が見つかりました。DIVERブロック(Diver Block Pack)プラグインの、次のようなコードです。

addFilter("blocks.registerBlockType", "dbp/paragraph-attributes", function (e, t) {
  return e?.supports?.color && (
    e.supports.color.__experimentalSkipSerialization = ["background"]
  ), ...
});

何をしているコードかというと、WordPressがブロックを登録するタイミングに割り込んで、各ブロックの設定(supports)を書き換えています。ブロックを追加・拡張するプラグインではごく一般的な、まっとうな手法です。

問題はe?.supports?.color &&という安全確認の部分です。書いた方はオプショナルチェーン(?.)を使ってきちんと防御したつもりでいて、実際6.x系でも7.0でも問題なく動いていました。ところがこの書き方が確認しているのは「値が存在するか」だけで、「値がオブジェクトかどうか」ではありません。

WordPress 7.1で一部のコアブロックのsupports.colorがtrueという真偽値になった結果、trueは「存在する」と判定されて安全確認を素通りし、その直後に真偽値へプロパティを代入しようとして例外になります。JavaScriptでは真偽値にプロパティを生やせないので、そこで処理が止まる、というのが真相でした。

しかもこの処理は全ブロックを登録していくループの中で走ります。1つ引っかかった瞬間にエディタの初期化ごと停止するため、たった1行が編集画面全体を殺してしまうわけです。

後日RE:DIVERのフォーラムを確認したところ、DIVERブロックプラグインが原因ではないかという情報がすでに出ていました。コンソールから読み取った内容と一致していたので、これで確定です。

これはDIVERブロックだけの話ではない

ここが、この記事で一番お伝えしたい部分です。

今回たまたまDIVERブロックで発覚しましたが、「ブロック登録に割り込んでsupportsを書き換える」という設計自体は、ブロック追加系プラグインではごく普通に使われています。コアブロックにオリジナルの装飾オプションを足したり、独自の余白設定を追加したりする機能は、たいていこの仕組みで実現されています。

つまり、同じ書き方をしているプラグインは他にも存在する可能性が高く、次のような種類のものは注意が必要です。

• ブロック追加系プラグイン
  Snow Monkey Blocks、VK Blocks、Useful Blocks、Spectra、Kadence Blocksなど、コアにないブロックを大量に追加するタイプ。
• エディタ拡張系プラグイン
  既存ブロックに独自の設定項目やスタイルを追加するタイプ。まさに今回のDIVERブロックがこれにあたります。
• 独自ブロックを持つ有料テーマ
  SWELL、RE:DIVER、SANGOなど、テーマ側でブロックを提供しているもの。テーマ本体に組み込まれている場合も、専用プラグインに分かれている場合もあります。
• ページビルダー系プラグイン
  エディタのUIそのものを拡張するタイプ。iframe化の影響も受けやすい部類です。

誤解のないよう申し添えますが、ここに挙げた製品に不具合があるという意味ではありません。いずれも実績のある優れたプラグイン・テーマです。あくまで「7.1の変更で影響を受けうる仕組みを使っている可能性があるカテゴリー」として挙げています。実際、今回の件でもSWELLは無罪で、警告こそ出ていたものの編集画面を止めていたのは別のプラグインでした。

大事なのは、症状が同じなら調べ方も同じだということです。編集画面が真っ白になったら、テーマを疑う前にコンソールを開いて赤いエラーの発生元ファイルを見る。この手順さえ知っていれば、原因がどのプラグインであっても同じように辿り着けます。

4つの対処法

原因が分かったら、状況に応じて対処法を選びます。

対処法	向いている状況	難易度
原因プラグインを停止する	そのプラグインを実際には使っていない	易
開発元に報告して対応版を待つ	急いでいない・他に手がある	易
自分で応急パッチを当てる	コードを触れる。すぐ直したい	難
WordPressをダウングレードする	すぐ直したい。コードは触りたくない	中

対処1　原因プラグインを停止する

そのプラグインのブロックを実際には使っていないサイトなら、停止するだけで即座に復旧します。リスクもありません。

使っているかどうかは、投稿一覧の検索窓にブロックの接頭辞(DIVERブロックならwp:dbp)を入れて検索すれば分かります。管理画面の検索は本文も対象にするので、該当ブロックを含む記事があればヒットします。固定ページや再利用ブロックも忘れずに確認してください。phpMyAdminが使えるなら、こちらの方が確実です。

SELECT ID, post_type, post_title FROM wp_posts
WHERE post_content LIKE '%wp:dbp/%' AND post_status != 'trash';

逆に、そのプラグインのブロックを記事内で使っている場合は停止しないでください。既存記事の編集画面でブロックがエラー表示になったり、装飾が失われたりする可能性があります。

なお、どのプラグインが原因か絞り込む段階では「Health Check & Troubleshooting」プラグインが便利です。トラブルシューティングモードを使うと、ログイン中の自分にだけプラグインを無効化した状態が適用され、訪問者には通常のサイトが表示されます。本番サイトで安全に切り分けができます。

対処2　開発元に報告して対応版を待つ

本筋の解決はこれです。そしてコンソールのエラー文をそのまま添えて報告するのが、結果的に一番早い解決につながります。

報告に含めるべきは、症状、WordPressのバージョン、テーマとプラグインのバージョン、コンソールに出た赤いエラー文の4点です。可能なら該当コードの行も添えると、開発者は原因箇所を探す手間なく修正に入れます。「動きません」だけの報告と比べて、対応までの時間がまったく変わってきます。

対処3　自分で応急パッチを当てる(自己責任)

コードを触れる方であれば、型チェックを1つ足すだけで回避できます。今回の例なら次のような修正です。

// 修正前
e?.supports?.color && (e.supports.color.__experimentalSkipSerialization = ["background"])

// 修正後
e?.supports?.color && "object" == typeof e.supports.color && (e.supports.color.__experimentalSkipSerialization = ["background"])

trueが入っていた場合は処理をスキップし、オブジェクトのときだけ従来通り動くようになります。ただし、ファイルを編集する前に必ずバックアップを取ってください。そしてこの修正はプラグインを更新すると消えるので、当該プラグインの自動更新は一時的にオフにしておく必要があります。公式の修正版が出たら、自動更新を戻して更新すれば元通りです。

他社製品のファイルを直接書き換えるのは本来おすすめできる方法ではありません。あくまで公式の修正版が出るまでのつなぎと割り切ってください。

対処4　WP DowngradeでWordPressを7.0系に戻す

今回、私が採用したのがこの方法です。「WP Downgrade | Specific Core Version」というプラグインを使い、WordPressを7.0.4に戻しました。

手順はシンプルです。

• プラグイン「WP Downgrade | Specific Core Version」をインストールして有効化する
• 「設定」→「WP Downgrade」を開き、WordPress Target Versionに7.0.4と入力して保存する
• 保存後に表示される「Up-/Downgrade」ボタン、または「ダッシュボード」→「更新」から再インストールを実行する
• 編集画面を開いて、正常に表示されることを確認する

これで編集環境がそのまま7.1以前の状態に戻り、記事の更新が再開できます。プラグインのファイルを触らずに済むので、複数サイトを管理している場合でも手順が統一できるのが利点です。

ただし注意点があります。ダウングレードした状態は、その後のセキュリティ更新を受けられない状態でもあります。2026年7月に発覚したwp2shellのように、認証不要でサイトを乗っ取られる脆弱性が見つかることは実際にあります。あくまで一時的な措置と位置づけ、プラグインの対応版が出たら速やかに7.1へ戻してください。

また、ダウングレードした状態でWordPressの自動更新が有効なままだと、また7.1に上がって真っ白に戻ります。WP Downgradeを有効にしている間は目標バージョンが維持されますが、念のため挙動は確認しておいた方が安心です。

そして最も重要なのは、まだ7.1に更新していないサイトの自動更新を止めることです。原因が確定するまで、被害を受けるサイトをこれ以上増やさないことが先決になります。

今回の件から得られた教訓

• 編集画面が真っ白になったら、まずコンソールを開く
  画面に何も出ていなくても、コンソールには必ず手がかりがあります。テーマやプラグインを手当たり次第に止めるより、はるかに速く原因に辿り着けます。
• 警告とエラーを混同しない
  黄色い警告は将来の宿題、赤いエラーが今の犯人です。今回も、大量の警告に埋もれた1行の赤いエラーが答えでした。
• 「共通点」の見立てを疑う
  テーマが違うのに同じ症状が出るなら、共通しているのはテーマではなく別の何かです。切り分けで見えた共通点は、必ず裏を取ってから信じるべきでした。
• メジャーアップデートは検証環境で試す
  今回のような変更は事前に告知されています。複数サイトを管理しているなら、1サイトで試してから展開する運用にしておけば被害はゼロで済みました。
• 本体の自動更新を無条件にオンにしない
  マイナー更新(セキュリティ修正)は自動、メジャー更新は手動、という切り分けが現実的です。
• 更新前にバックアップを取る
  ダウングレードで戻せるとはいえ、戻せる状態を用意しておくのとぶっつけで挑むのとでは、心の余裕がまったく違います。

まとめ

WordPress 7.1は、ネイティブなレスポンシブ設定や共同編集機能など、待ち望まれていた改善が多数入った価値ある更新です。決して「危険な更新」ではありません。ただ、投稿エディタの完全iframe化をはじめとする内部的な変更が大きく、ブロックを追加・拡張するプラグインとの相性問題が表面化しやすいタイミングであることは確かです。

もし編集画面が真っ白になってしまったら、慌てずにF12でコンソールを開いてください。赤いエラーの発生元ファイルさえ分かれば、原因は必ず特定できます。そして特定できてしまえば、停止するなり、パッチを当てるなり、ダウングレードするなり、打つ手は必ずあります。

ご自身での切り分けが難しい場合や、複数サイトを抱えていて手が回らない場合は、無理に触る前にご相談ください。原因が分からないまま設定やファイルをあれこれ変更してしまうと、元の状態に戻す作業から始めることになり、かかる時間も費用も何倍にも膨らんでしまいます。