2026年8月19日に公開されたWordPress 7.1。更新したら「サイトが真っ白になった」「ブロックの編集画面が変わった」「管理画面のカレンダーが動かない」という相談が増えています。この記事では、7.1公開後に報告されている不具合を「発生する環境」「影響の確認方法」「今できる対処」「7.1.1で直るのか」の4点で整理します。

先に結論をまとめます。WordPress 7.1の不具合の大半は本体そのものの故障ではなく、7.1の内部変更にプラグインが追随できていないことが原因です。代表例はWP Rocketの致命的エラー（3.23.2.2で修正済み）、ACFブロックV2の編集画面の変化（ACF 6.8.9で対応）、jQuery UI 1.14.2への更新による古い管理画面UIの不調です。修正版の7.1.1は2026年9月17日に公開予定で、バグ修正のみのリリースになります。

WordPress 7.1で報告されている主な不具合は？

執筆時点（2026年9月上旬）で、公式サポートフォーラム・プラグイン開発元・WordPress Tracで確認できる主な問題です。

症状	発生する環境	原因	今できる対処	7.1.1で直る？
サイト全体が「重大なエラー」で真っ白	WP Rocket 3.23.2.1以前＋PHP 8系。Elementor Proなど、クロージャでフックを登録するプラグインが同居していると発生	7.1でフックのコールバックIDが整数になり、WP Rocketの内部処理が型エラーを起こす	WP Rocketを3.23.2.2以上へ更新。管理画面に入れないならFTPでプラグインフォルダを一時的にリネーム	プラグイン側で修正済み。本体側の扱いはTrac #65919で議論中
ACFブロックの編集画面が変わり、本文内で編集できない	ACF（Advanced Custom Fields）のV2ブロック、特にeditモードを使うサイト	7.1で投稿エディターが常時iframe化され、wp-admin側のJS/CSSがブロック内で使えなくなった	ACF 6.8.9以上へ更新しV3ブロックへ移行。時間が必要なら公式の互換プラグインを使う	直らない（本体の仕様変更）
カスタムHTMLスニペットが表示されない	Simple Custom CSS and JS の旧バージョン	7.1のオブジェクトキャッシュ／遅延読み込みの変更で、早いタイミングの投稿取得が空になる	プラグインを3.54以上へ更新	プラグイン側で修正済み
管理画面の日付選択・ダイアログ・並べ替えが動かない	長く更新されていない管理画面系プラグインや自作コード	jQuery UIが1.14.2へ更新され、古いAPIが削除された	該当プラグインの更新。自作なら削除されたAPIの置き換え	直らない（本体の仕様変更）
縦向きの写真をアップロードすると横向きになる	7.1の新しい画像アップロード処理を使う環境で報告あり	調査中（Trac #66050、2026年9月5日報告）	アップロード後にメディアライブラリで回転。再現条件は未確定	未確定
更新そのものが「一部のファイルをコピーできませんでした」で失敗	ファイル権限・容量・PHPメモリに問題がある環境	7.1特有ではなく、サーバー側の要因	権限と容量を確認し、SSHやFTPで手動更新	7.1.1とは無関係

「本体のバグ」と呼べるものは意外と少なく、多くは本体の仕様変更に周辺が追いついていない状態です。7.1.1に上げれば全部直る、という話ではありません。

なぜWordPress 7.1でエラーが出やすいのか？

WordPress 7.1では、見た目の新機能以上に「内部の作り」が大きく変わりました。不具合の根っこは次の3つです。

投稿エディターの常時iframe化：テーマの種類を問わずiframe表示が必須になり、管理画面側のJS/CSSを前提にしたブロックやメタボックスが動かなくなりました。
フックの内部IDの生成方法の変更：高速化のため、コールバックの識別子が32文字の文字列から整数に変わり、文字列として扱っていたプラグインがPHP 8の型チェックでエラーになります。
画像処理のブラウザ側への移行とjQuery UIの更新：従来の画像系フックが動かない経路が生まれ、jQuery UI 1.14.2への更新で古いAPIが削除されました。

WP Rocketのケースは象徴的で、7.1ベータの段階で報告されていたのに修正版が出たのは正式公開の翌日でした。有名プラグインでも、メジャーアップデート当日に対応が間に合わないことは普通に起こると考えておくのが安全です。

自分のサイトが影響を受けるか確認する方法

次の順番で確認すると、影響の有無をほぼ判断できます。

「プラグイン」一覧にWP Rocket・ACF（Advanced Custom Fields）・Simple Custom CSS and JS・Elementor Proがあれば、まず最新版に更新する。
「ツール」→「サイトヘルス」→「情報」でPHPのバージョンを確認する。PHP 8系では致命的エラーとして表面化しやすい。
1年以上更新されていないプラグイン、特に管理画面にカレンダーやドラッグ操作を追加するものを洗い出す。
自作のブロックやメタボックスがあるなら、7.1の環境で編集画面を実際に開いて確認する。
すでにエラーが出ているなら、サーバーのエラーログを見る。「Cloudflare.php:562」の文字があればWP Rocketが原因です。

WordPress 7.1でエラーが出たときの対処法

すでに更新してしまい、サイトが表示できない場合の手順です。

まず原因のプラグインを止める：管理画面に入れないなら、FTPでプラグインのフォルダ名を変更（例：wp-rocket → wp-rocket-off）すると強制的に無効化できます。
プラグインを更新してから戻す：管理画面に入れる状態にしてから最新版へ更新し、フォルダ名を戻して再度有効化します。
修正版が出ていないプラグインなら、バックアップからWordPress 7.0系へ戻して対応を待つのが安全です。

「重大なエラー」画面の読み方と復旧手順は、WordPressの「重大なエラー」の直し方で詳しく解説しています。更新自体が失敗する場合は、安全なアップデート手順もあわせてご覧ください。

ここまでのまとめ：慌てて7.1に上げる必要はない

7.1の不具合は「プラグインの更新」でほぼ解決でき、直らないものは本体の仕様変更なので7.1.1を待っても変わらない。これがここまでの結論です。ここから先は、7.1.1の中身と、自作コードを持つ方向けの技術的な話です。

WordPress 7.1.1はいつ公開？何が修正される？

Make WordPress Coreの発表によると、WordPress 7.1.1は2026年9月17日15:00（UTC）に公開予定で、リリース候補（RC1）は9月10日です。日本時間では9月18日の未明になる見込みです。

7.1.1はバグ修正のみのメンテナンスリリースで、対象は「7.1の開発中に入り込んだ問題」と「最終段階で先送りされた問題」に限られます。修正候補はTracのレポート4と、GitHubの「7.1.x editor tasks」ボードで公開されています。

注意したいのは、この記事で挙げた不具合の多くは7.1.1の修正対象にならない点です。iframe化やjQuery UIの更新は仕様変更で、戻されることはありません。フックIDの問題（Trac #65919）を本体側で直すかどうかも、執筆時点では確定していません。7.1.1が公開されたら、この記事に実際の修正内容を追記します。

技術者向け：フックIDの変更でプラグインが壊れる仕組み

WP Rocketを壊した変更（changeset 62408、Trac #58291）は、フックの登録・解除を約20%高速化するためのものです。内部関数 _wp_filter_build_unique_id() が、クロージャや __invoke() を持つオブジェクトに対して、spl_object_hash()（32文字の文字列）ではなく spl_object_id()（小さな整数）を返すようになりました。

PHPでは「5292」のような整数と解釈できる文字列は、配列のキーに使われた瞬間に整数へ変換されるため、WP_Hook::$callbacks のキーが int になります。このキーに substr() などの文字列関数を通していたコードは、declare(strict_types=1) の下で TypeError を投げます。WP Rocketの Cloudflare.php:562 がまさにそれでした。

自作プラグインで $wp_filter を直接走査している箇所があれば、キーを文字列へキャストしてから扱うのが最小の対処です。

// 7.0以前は $key が必ず文字列だったが、7.1では int になり得る
foreach ( $wp_filter['deleted_post']->callbacks[10] as $key => $callback ) {
    $key = (string) $key; // 明示的にキャストしてから文字列関数に渡す
    if ( 0 === strpos( $key, 'MyPlugin' ) ) {
        // ...
    }
}

// 7.0以前は $key が必ず文字列だったが、7.1では int になり得る

foreach ( $wp_filter['deleted_post']->callbacks[10] as $key => $callback ) {

$key = (string) $key; // 明示的にキャストしてから文字列関数に渡す

if ( 0 === strpos( $key, 'MyPlugin' ) ) {

// ...

}

そもそも $wp_filter の内部構造に依存せず、has_filter() や remove_filter() で済ませられないかを先に検討してください。iframe化への対応はWordPress 7.1の新機能解説の開発者向けセクションでも触れています。

私の判断：自社サイトはまだ7.0系のまま

正直に書くと、当社のサイト edel-hearts.com は、この記事を書いている時点でまだWordPress 7.0系のままです。管理画面には「7.1が利用可能です」の通知が出続けていますが、メジャーアップデートは公開後7週間ほど様子を見るのが私の基準で、今回は7.1.1を待ってから上げる予定です。もちろん7.0.2のようなセキュリティ更新は別で、こちらは即日適用しています。

過去には、自動更新が「一部のファイルをコピーできませんでした」で止まったサイトを、SSHで入ってコマンドから更新し直して復旧したこともあります。更新失敗のほとんどはサーバー側の権限や容量の問題で、WordPressのバージョンとは関係ありません。当社の保守サービスでは毎日7世代のバックアップを取ったうえで更新し、問題があったときだけご報告しています。慌てて上げるより、戻せる状態を作ってから上げる。これが一番トラブルの少ない方法です。

まとめ：WordPress 7.1の不具合との付き合い方

7.1の不具合の大半はプラグインの未対応が原因で、プラグインの更新で解決する
WP Rocket・ACF・Simple Custom CSS and JS・古い管理画面系プラグインは要チェック
iframe化とjQuery UI更新は仕様変更なので、7.1.1を待っても元には戻らない
7.1.1は9月17日公開予定のバグ修正リリース。まだ更新していないなら、これを待ってからで十分
更新前のバックアップと、いつでも戻せる手順の確保が最優先

「アップデートしたら真っ白になった」「どのプラグインが原因か分からない」という場合は、WordPressトラブル対応サービスで原因特定から復旧までお引き受けします。今後のアップデートを安心して任せたい方は、バックアップと更新代行を含む保守サポートもご検討ください。自分のサイトが影響を受けそうか判断がつかない段階でも、無料相談からお気軽にどうぞ。

この記事を書いた人

矢部敦合同会社Edel Hearts 代表

WordPress専門の開発会社を経営。プラグイン開発・カスタマイズ・保守を専門とし、18時間におよぶUdemyのWordPress講座を開講。出典付きで回答するAIチャットボット「Edel AI Hybrid Chat」開発者。本ブログの記事は、実際の開発・運用で得た一次情報をもとに執筆しています。会社情報はこちら