WooCommerce マイアカウントで顧客情報が保存されない原因と直し方
WooCommerce のマイアカウントページで顧客情報（アカウント詳細）を更新しても、保存や再読み込み後に古い情報に戻ってしまう場合、多くの原因はプラグインの重複フックや非互換性にある。なかでも EU VAT 系プラグインがアカウントページへ勝手に項目を追加し、保存時のデータ上書きや無効化を引き起こす事例が頻発している。
なぜアカウント詳細が保存されないのか
この不具合は大きく分けて3つのパターンに分類できる。優先度が高い順に、VAT フィールドの重複登録、他プラグインとの競合、そしてキャッシュやセッションの不整合だ。
実際のところ、管理画面から何度更新しても「このサイトで重大なエラーが発生しました」という表示が出ず、静かに更新前の値に戻ってしまうケースでは、原因1か原因2の可能性が極めて高い。
VAT フィールドの重複が引き起こす保存不能の仕組み
WooCommerce の最新バージョンでは、ブロックベースのチェックアウトに VAT フィールドを自動で追加する機能が実装された。これが影響し、特定の EU VAT 系プラグイン（WP VAT MOSS など）がマイアカウントページに別途 VAT 項目を出力する場合、同一ページに同じ名前のフィールドが2つ存在する状態になる。
この重複によって、ブラウザが送信する POST データとサーバー側で処理されるフィールド名が食い違い、WooCommerce の `update_user_meta` フックが期待どおりに動作しなくなる。保存ボタンを押しても「処理中」のまま動かない、または一瞬成功したように見えて古い情報が再表示されるという症状が起きる。
WP VAT MOSS など EU VAT 系プラグインの特定と更新
まず管理画面のプラグイン一覧から、以下のキーワードを含むプラグインが有効化されているかを確認する。
- WP VAT MOSS
- EU VAT Assistant
- WooCommerce EU VAT Number
- EU/UK VAT Compliance
これらのプラグインが1つでもインストールされていれば、バージョンが最新かどうかを確かめる。特に WP VAT MOSS の場合、バージョン1.4.6以前で今回の「VAT 重複」バグが報告されており、1.4.7以降にアップデートすることで重複フィールドが解消されるように修正されている。
アップデート後も改善しない場合は、プラグインを一時停止し、標準テーマ（Twenty Twenty-Four など）に切り替えてから再テストする。これで直れば、テーマまたは他のプラグインが VAT フィールドを追加出力している可能性が高い。
プラグインの競合を特定する手順
VAT 以外の情報（名前、メールアドレス、住所など）も更新できない場合は、より広範な競合テストが必要だ。以下の順でトラブルシューティングを進める。
STEP 2 で一時的に無効化するカスタムコードの例を挙げる。`woocommerce_save_account_details` や `woocommerce_save_account_details_errors` などアカウント保存に関わるアクションフックをすべて一時的にコメントアウトし、素の WooCommerce で保存が通るかどうかを見極めるのが確実だ。
キャッシュに惑わされず正しくテストするには
テスト中に「直ったかも」と思ったら実はキャッシュのせいだった、というのはよくある落とし穴だ。以下の点を押さえてテストを進める。
- テストは必ずシークレットウィンドウ（プライベートブラウズ）で行う
- W3 Total Cache や WP Rocket などのキャッシュプラグインを使用している場合は、テスト中は全キャッシュをクリアし、できればプラグインを一時停止する
- サーバー側で Varnish や Nginx の FastCGI キャッシュが動いているレンタルサーバーでは、サーバー管理画面からキャッシュを完全にパージする
- Cloudflare などの CDN を経由している場合は、Cloudflare ダッシュボードで「キャッシュを削除」を実行する
また、WooCommerce のセッションハンドラーがユーザー情報を保持しているケースもある。管理画面の「WooCommerce ＞ ステータス ＞ ツール」から「顧客セッションをクリア」を実行し、そのうえでアカウント更新を試してほしい。
デバッグログを有効にして根本原因を可視化する
ここまでの方法で解決しない、または原因プラグインを特定できない場合は、WordPress のデバッグモードを有効にしてエラーログを確認する。
FTP またはサーバーのファイルマネージャーから `wp-config.php` を開き、以下の定数を追加または変更する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );これにより `/wp-content/debug.log` に PHP エラーが出力されるようになる。アカウント詳細の更新を再現したあと、このファイルを開けば、どのプラグインのどのファイルでエラーが発生しているかが具体的に記録される。たとえば「PHP Fatal error: Uncaught Error: Call to undefined function vat_number_save…」のような行が見つかれば、該当するプラグインが犯人だ。
よくある質問
VAT フィールドが増えただけで保存できなくなるのはなぜか
WooCommerce はアカウント保存時に、同名のフィールドが複数あると最後の値だけを処理するか、あるいは処理自体をスキップする。このため表面上は入力できるのにサーバーに反映されず、リロードで元に戻ってしまう。
プラグインのアップデート後も改善しない場合はどうするか
プラグインを完全に削除してから再インストールし、データベースに残った不要なオプション値を手動で削除する。wp_options テーブルにプラグイン固有の設定が残っていると、バージョンアップ後も誤動作することがある。
標準テーマに切り替えられない事情があるときはどうすればよいか
ステージング環境（テスト用の複製サイト）を作成し、そこでのみテーマとプラグインの切り分けテストを行う。本番環境を触らずに原因究明できる方法として最も安全だ。
アカウント詳細の保存だけ失敗し、注文や住所変更は問題なく更新できるのはなぜか
WooCommerce のアカウント保存フックは、注文処理や住所変更のフックとは別に実行される。特定のプラグインがこのフックだけに悪影響を及ぼしている可能性が高い。逆に言えば、影響範囲が限定的なため原因プラグインの絞り込みはしやすい。
PHP のバージョンが古いと起きる問題か
直接的ではないが推奨環境を満たしていないと、プラグインが最新の WooCommerce フックに対応できず、予期せぬ挙動を引き起こすことがある。PHP 8.0 以上を強く推奨する。
この記事のポイント
- アカウント詳細の更新不能は VAT フィールド重複が最も多い原因
- WP VAT MOSS 1.4.7 以降へのアップデートで解決する事例が多数報告されている
- それ以外の競合はプラグインの1つずつ停止とキャッシュクリアで切り分けられる
- デバッグログでエラーを可視化すれば、修正の手がかりが得られる
- テストは必ずシークレットウィンドウとキャッシュ無効状態で行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressエディタが真っ白になる原因と直し方
管理画面のブロックエディタを開いた際に編集エリアが完全に白紙になる主な原因は、プラグインやテーマの競合、または PHP の致命的エラーだ。まず標準テーマへの切り替えと全プラグインの無効化で原因を特定し、それでも解決しない場合はデバッグモードでエラーログを確認する。
エディタ画面が真っ白になる根本的な原因
WordPress のブロックエディタ（Gutenberg）で編集画面を開いたときに真っ白なページしか表示されない現象は、大きく分けて 2 つの原因で発生する。1 つはプラグインやテーマの競合、もう 1 つは PHP の致命的エラー（「このサイトで重大なエラーが発生しました」と表示される類のもの）だ。
ブロックエディタは JavaScript を多用する高度な画面であり、複数のプラグインが読み込むスクリプト同士で競合が起きると、画面の描画が完全に停止してしまう。またテーマが古い jQuery や独自のエディタ拡張をロードしている場合も、エディタの初期化処理と衝突して空白画面を引き起こす。
PHP の致命的エラーが原因の場合は、エディタ画面そのものが生成される前に処理が中断されている状態だ。たとえばメモリ不足や、特定のプラグインが要求する PHP 拡張機能の不足、あるいは functions.php に記述された独自コードの文法ミスなどが該当する。こうしたエラーは管理画面全体に影響する場合もあるが、投稿編集画面だけが重い処理を要求するタイミングで発覚することも多い。
複数のプラグインやテーマが読み込むスクリプトが衝突し、エディタの初期化が止まる
メモリ不足・プラグインの不具合・functions.php の記述ミスなどで画面生成前に停止
セキュリティプラグインやサーバー設定が WordPress の REST API 通信を遮断している
プラグインとテーマの競合を切り分ける手順
まず最初に試すべきは、プラグインの全無効化と標準テーマへの切り替えだ。この手順だけで多くの白紙エディタ問題は解決する。管理画面にアクセスできる状態であれば、以下の流れで原因を特定できる。
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 〜」なら関数の未定義が原因だと絞り込める。
「Allowed memory size of 〜 bytes exhausted」→ wp-config.php で
define('WP_MEMORY_LIMIT', '256M'); を追加「Call to undefined function 〜」→ 該当のプラグイン/テーマを最新版に更新するか無効化
debug.log が空、または Notice/Warning のみ → PHP エラーは原因ではない
ブラウザの開発者ツールで 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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ブロックエディタが点滅してクラッシュする時の原因と直し方
ブロックエディタの画面が激しく点滅し、操作不能になったりエラーでクラッシュする場合、原因の大半はブラウザ拡張機能やキャッシュ、プラグイン競合による JavaScript の競合だ。セーフモードでの編集とブラウザのトラブルシューティングを順に行えば、大半のケースはすぐに編集を再開できる。
なぜブロックエディタが点滅してクラッシュするのか
今回の事象の中心にあるのは getComputedStyle@[native code] から始まる JavaScript エラーだ。ブロックエディタは React ベースの画面であり、DOM 要素のスタイルを動的に計算する処理を多用している。この getComputedStyle 呼び出しが失敗すると、React の内部状態が破綻し、画面全体の再描画が無限ループに陥って「点滅」が発生する。
エラーが起きるトリガーは主に以下の3つだ。
- AdBlock や Grammarly、翻訳ツールなど、ページの DOM 構造を書き換えるブラウザ拡張機能がエディタの動作と衝突している
- プラグインやテーマが独自に読み込む古い JavaScript ライブラリが、WordPress 本体のバンドル済み React と二重読み込みになっている
- ブラウザやサーバーに残ったキャッシュが、更新後のスクリプトと旧バージョンのスクリプトを混在させている
点滅はエディタが「レンダリング → クラッシュ → 再マウント → レンダリング」を一瞬で繰り返すために起こる。ユーザーからは、画面全体がチカチカしてボタンやブロックをクリックできない、またはクリックした瞬間に「このブロックでエラーが発生しました」と表示されて操作不能になる状態として見える。
エディタ画面全体が高速で明滅し、ブロックを選択できない。クリックすると「このサイトで重大なエラーが発生しました」と表示される。
エディタが安定し、ブロックの選択・編集・移動が問題なく行える。画面のちらつきは完全に消えている。
ビジュアルエディタの点滅を止めて編集を再開する手順
原因を一つずつ潰していくのが確実だ。以下の手順は、影響範囲が小さくすぐ試せるものから並べている。手順1〜3で解決しなければ、手順4以降の WordPress 内部の切り分けに進む。
ブラウザ拡張機能をすべて無効にして試す
最も短時間で試せて、かつ最も解決率が高い対処だ。ブロックエディタは高度な JavaScript で動作しており、広告ブロッカーや文法チェッカーなどの拡張機能が DOM に手を加えると、React の仮想 DOM と実際の DOM の整合性が崩れて getComputedStyle エラーが発生する。特に AdBlock 系、Grammarly、翻訳アドオン、ユーザースクリプト（Tampermonkey 等）が競合しやすい。
Chrome の場合、アドレスバー右の拡張機能アイコンから「拡張機能を管理」を開き、すべての拡張機能を一度オフにする。その状態でエディタを開き直し、点滅が収まるかを確認する。収まった場合は、拡張機能をひとつずつオンにして犯人を特定する。
シークレットウィンドウかゲストモードで動作を確認する
拡張機能を一括で無効化できるもっと手軽な方法が、シークレットウィンドウ（Chrome は Ctrl+Shift+N、Firefox は Ctrl+Shift+P）だ。シークレットモードでは拡張機能がデフォルトで無効になるため、ここで問題が再現しなければ、原因はほぼ確実に拡張機能かブラウザのキャッシュにある。
別のブラウザ（普段 Chrome を使っているなら Firefox や Edge）をインストールし、拡張機能を何も入れていない状態でエディタにアクセスするのも有効な切り分けになる。複数ブラウザで同じエラーが出る場合は、拡張機能ではなく WordPress 側の問題の可能性が高い。
ブラウザキャッシュとサーバーキャッシュを削除する
WordPress のバージョンアップやプラグイン更新の直後に点滅が始まった場合、ブラウザに古い JavaScript ファイルがキャッシュされている可能性が高い。キャッシュされた古いスクリプトと、サーバー上の新しいスクリプトが混ざると、関数の呼び出し不一致で React がクラッシュする。
- ブラウザのキャッシュと Cookie を全期間で削除する（Chrome 設定→プライバシーとセキュリティ→閲覧履歴データの削除→「キャッシュされた画像とファイル」にチェック→全期間）
- サーバー側で W3 Total Cache や WP Super Cache などのキャッシュプラグインを使っている場合は、管理画面から「全キャッシュを削除」する
- Cloudflare などの CDN を利用している場合は、ダッシュボードでキャッシュをパージする
- 一部のレンタルサーバーで提供される独自キャッシュ機能もオフにする
セーフモードでプラグインの競合を切り分ける
ここまでの手順で解決しない場合、WordPress 内部で JavaScript の競合が起きている。特定のプラグインやテーマが、WordPress 本体がバンドルしている React とは別バージョンの React を読み込んでいたり、jQuery の古いバージョンや別の JavaScript ライブラリを強制的に読み込んでいるケースが多い。
全プラグインを一度に無効化すると管理画面まで影響が出る操作もあるため、WordPress のトラブルシューティングモード（Health Check & Troubleshooting プラグイン）を使うのが安全だ。このプラグインをインストールして有効化すると、管理画面のツールバーに「トラブルシューティングモード」ボタンが現れる。これを押すと、自分だけに影響するセッションで、すべてのプラグインが無効化され標準テーマに切り替わった状態でエディタをテストできる。他の訪問者には通常通りのサイトが表示される。
トラブルシューティングモードでエディタが正常に動けば、原因はプラグインかテーマにある。次にプラグインをひとつずつ有効化していき、どのプラグインを有効にした瞬間に点滅が再発するかを特定する。Health Check プラグインが使えない環境では、本番に近いテスト環境（ステージング）を作って同じ手順を行う。
テーマを標準テーマに切り替える
有料テーマやカスタマイズの多いテーマは、独自のページビルダーやアニメーションライブラリを読み込んでいることがある。プラグインをすべて無効化しても直らない場合、テーマが原因の可能性が高い。一時的に Twenty Twenty-Five などの標準テーマに切り替え、エディタの点滅が止まるか確認する。
テーマを切り替えるとウィジェットやメニュー構成が変わる可能性があるため、先にサイトのバックアップを取ることを推奨する。点滅がテーマに起因していた場合は、テーマの開発元に getComputedStyle エラーの情報を添えて問い合わせるか、子テーマで競合するスクリプトの読み込みを停止させる。
点滅エラーの詳細を開発者ツールで特定する方法
どうしても原因がわからない場合や、特定のプラグインをどうしても無効化できない事情がある場合は、ブラウザの開発者ツールで詳細なエラー情報を収集する。
- Chrome で F12 キー（開発者ツール）を開き、「Console」タブを確認する
- 赤いエラーメッセージの右に表示される「ソース」のリンクをクリックすると、エラーが発生している JavaScript ファイルと行番号が表示される
- ファイルパスに
/wp-content/plugins/プラグイン名/や/wp-content/themes/テーマ名/が含まれていれば、そのプラグインまたはテーマがエラーの発生源だ - 「Network」タブで、404 エラー（Not Found）になっている .js ファイルがないかも確認する。ファイルの読み込みに失敗していると、依存する React の処理が途中で止まりクラッシュする
これらの情報を、原因と思われるプラグインやテーマのサポートフォーラムに提出すれば、開発者側での修正も期待できる。エラーメッセージを丸ごとコピーして伝えるとスムーズだ。
それでも直らない時の一時的な回避策
納期が迫っていてどうしても編集を進めなければならない場合、以下の回避策で作業を継続できる。
コードエディタで直接編集する
ビジュアルエディタが使えなくても、ブロックエディタの右上の三点メニューから「コードエディタ」に切り替えれば、HTML ベースでブロックの内容を編集できる。ビジュアルのプレビューは見られないが、少なくとも点滅に悩まされずにテキストの修正やブロック構造の調整は可能だ。
クラシックエディタプラグインを一時的に有効化する
Classic Editor プラグインをインストールして有効化すると、旧来のクラシックエディタで記事を編集できる。点滅の原因がブロックエディタ固有の React 処理にある場合、クラシックエディタでは問題が発生しないことが多い。作業が完了したらプラグインを無効化して元のブロックエディタに戻し、根本原因の調査を続ける。
よくある質問
同じブラウザで他の WordPress サイトは正常に動く。自サイトだけ点滅するのはなぜか
自サイトのプラグインまたはテーマが読み込んでいる JavaScript が原因だ。他の WordPress サイトが正常なのは、そのサイトでは問題のスクリプトが読み込まれていないからだ。「セーフモードでプラグインの競合を切り分ける」手順で原因のプラグインやテーマを特定する。
getComputedStyle エラーは WordPress のバージョンを戻せば直るか
バージョンを戻すことで一時的に直るケースはあるが、セキュリティ更新が適用されなくなるため推奨しない。WordPress 本体には問題がなく、特定のプラグインやテーマが新しい WordPress のバンドル済み React に対応していないことがほとんどだ。プラグインやテーマの更新を待つか、開発元に報告して対応を依頼する方が安全だ。
ブラウザのハードウェアアクセラレーションは関係あるか
ごくまれに、GPU レンダリングの不具合が画面の点滅を引き起こすことがある。Chrome の設定→システム→「ハードウェア アクセラレーションが使用可能な場合は使用する」をオフにして再起動すると直るケースも報告されている。ただし、getComputedStyle エラーを伴う場合は JavaScript の競合が原因の可能性が高い。
全プラグイン無効化と標準テーマでも直らない場合はどうするか
ここまで試しても直らない場合は、WordPress 本体のファイル破損やサーバー側の特異な設定（mod_security など）が影響している可能性がある。WordPress の再インストール（「ダッシュボード→更新」から「再インストール」を実行）を試す。それでもダメならサーバーのエラーログを確認し、PHP のメモリ制限や実行時間制限が不足していないかも調べる。
エラーのスタックトレースにプラグイン名が出ていない時はどう調べるか
エラーが react-dom.min.js や components.min.js で発生している場合、直接の原因箇所がミニファイされた WordPress 本体のファイルになっている。この場合は「Network」タブで、読み込まれているすべての .js ファイルを確認する。プラグインが読み込むスクリプトの数が多い順に疑い、ひとつずつ無効化して切り分ける。
この記事のポイント
- ブロックエディタの点滅と getComputedStyle エラーの主因はブラウザ拡張機能と JavaScript 競合
- シークレットウィンドウと拡張機能無効化で素早く原因を絞り込める
- Health Check プラグインのトラブルシューティングモードで安全にプラグインを切り分ける
- どうしても急ぐ場合はコードエディタや Classic Editor プラグインで一時的に編集を続行できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ExtendifyとElementorが競合して編集ボタンが消えた時の直し方
Extendify Onboarding and AI Assistant が有効な環境で「Edit with Elementor」ボタンが消えた場合、原因は Extendify のオンボーディング用 JavaScript が Elementor の管理画面 UI を上書きしていることにある。プラグインを無効化して削除すれば即座に復旧するが、競合を回避したい場合は Extendify の Script 読み込み制御か Elementor の連携設定を調整する必要がある。
なぜ Extendify を有効にしていると「Edit with Elementor」が消えるのか
この問題は、レンタルサーバー側が WordPress の初期セットアップ時に Extendify をプリインストールしているケースで頻発する。Extendify は Gutenberg エディタの拡張として動作し、管理画面の JavaScript 処理全体に影響を与える設計だ。Elementor のエディタ起動ボタンは、ブラウザ上で動的に生成される管理画面 UI の一部で、Gutenberg のスクリプトがロードされた後に挿入される。Extendify のスクリプトがこのタイミングを阻害すると、ボタン生成処理が飛ばされてしまう。
特に「オンボーディングガイド」という機能が原因になる。これは管理画面に重ねて表示されるチュートリアル用のオーバーレイで、初回インストール後に自動で立ち上がる。このオーバーレイがアクティブな間、特定の DOM 要素の描画がブロックされる仕様であり、その対象に Elementor の「Edit with Elementor」ボタンが含まれている。
Elementor 側の設定を正しく行い、投稿タイプで「ページ」にチェックを入れ、「Elementor Full Width」テンプレートを適用していても、管理画面の表示ロジックそのものが Extendify に遮断されるため、ユーザー側の設定では回避できない。
Extendify が有効な状態で Elementor の編集ボタンが消える仕組みを画面で比較した。管理画面の見た目はまったく変わらないのに、特定の操作要素だけが欠落するため、原因の特定に時間がかかりやすい。
管理画面から消えた「Edit with Elementor」ボタンを復活させる手順
Extendify 単体が原因かどうかを確定させる
まずはプラグインの競合切り分けの基本に入る。管理画面の「プラグイン」→「インストール済みプラグイン」から Extendify を探し、一時的に「無効化」する。この時点でページ一覧やブロックエディタを再読み込みし、「Edit with Elementor」が表示されるか確認する。復活すれば Extendify が原因で確定する。
もし無効化だけではボタンが戻らない場合、管理画面キャッシュの影響を疑う。ブラウザのハードリロード（Ctrl + Shift + R / Cmd + Shift + R）を実行し、さらにサーバー側のキャッシュプラグインがあれば全キャッシュを削除する。それでも改善しなければ、他のプラグインも含めた段階的な無効化に進む。
この手順で Extendify が原因かどうかがはっきりする。多くの場合、STEP 2 の段階ですでにボタンが戻る。
Extendify を残したまま競合を回避する方法
Extendify の AI 機能やオンボーディング自体は活用したいという場合、完全に削除する前に設定で回避できるかを試す。Extendify の管理画面「Extendify」→「Settings」にアクセスし、オンボーディングのガイド表示をスキップするか、Gutenberg 以外の場所でのスクリプト読み込みを制限するオプションを探す。バージョン 3.1 では細かい制御が難しいため、実質的には functions.php にコードを追加して Elementor の管理画面だけで Extendify のスクリプトを停止させる手段が現実的だ。
// ページ編集画面でのみ Extendify のスクリプトを解除する例
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( 'post.php' === $hook || 'post-new.php' === $hook ) {
wp_dequeue_script( 'extendify-assist' );
wp_dequeue_script( 'extendify-onboarding' );
}
}, 100 );上記のコードを有効化した子テーマの functions.php に追加すると、投稿編集画面での Extendify の干渉だけを選択的に遮断できる。完全な動作保証は環境次第だが、根本的な競合を残さずに両立させる現実解としては有効だ。
レンタルサーバーのプリインストールプラグインが原因の場合の注意点
国内のレンタルサーバーでも、WordPress のクイックスタート機能に独自のオンボーディングプラグインやテーマがプリインストールされているケースがある。こうしたプラグインはサーバー会社のブランドでパッケージされており、名前だけでは機能がわからないことも多い。管理画面が日本語であっても、元のプラグイン名が残っている場合や、逆にまったく別の名前に変わっている場合があるため、プラグイン一覧でバージョンや作者を確認する癖をつけておく。
ホスティングプロバイダーがプリインストールするプラグインには、キャッシュや高速化、セキュリティスキャン、オンボーディングアシスタントといった管理画面全体に影響するものが多い。Elementor の編集ボタンに限らず、管理画面上の特定のボタンや項目が突然消えたら、まずはプリインストールプラグインの無効化を試みてほしい。
他のプラグインでも同様の現象は起きるのか
同じように管理画面の JavaScript 全体を上書きするタイプのプラグインであれば、まったく同じ現象が起きる。管理画面の UI をカスタマイズするプラグインや、Gutenberg のブロックを拡張する多機能プラグインが競合しやすい。特に、Elementor と Gutenberg の両方を同時に運用しているサイトでは、両者のスクリプトロード順序が原因で、どちらかの編集ボタンが一時的に消えるトラブルが報告されている。
問題の特定には、ブラウザのデベロッパーツールでコンソールの JavaScript エラーを確認するのが有効だ。Elementor のボタン生成に失敗している場合、”Uncaught TypeError” や “Cannot read properties of null” といったエラーが出ていることが多い。これに加えて、ネットワークタブで Elementor 関連の .js ファイルの読み込み状況を見れば、どのプラグインが原因か絞り込みやすくなる。
よくある質問
Extendify を無効化したら Elementor の編集ボタンは戻ったが、Extendify は削除してもよいか
削除して問題ない。Extendify は Gutenberg の拡張と AI によるコンテンツ生成を目的としたプラグインで、Elementor をメインのページビルダーとして使うなら必須ではない。むしろ残しておくと将来のバージョンアップで再び競合するリスクがあるため、不要と判断したら完全に削除するほうが管理上は安全だ。
「Edit with Elementor」は表示されているがクリックしても反応しない
このケースは Extendify 以外にキャッシュプラグインやセキュリティプラグインが原因であることが多い。ブラウザのコンソールで JavaScript エラーを確認し、403 や 404 のリソース読み込みエラーが出ていれば、プラグインの除外設定を見直す必要がある。
同じ現象が発生したが Extendify は入っておらず、別のプラグインが原因のようだ。どう切り分ければいいか
全プラグインを一括で無効化し、標準テーマ（Twenty Twenty-Five など）に切り替えた状態で Elementor のボタンが復活するかを確認する。復活したら、プラグインを 1 つずつ有効化して原因を絞り込む。この方法で、どのプラグインが管理画面の JavaScript 処理を妨害しているかを確実に特定できる。
子テーマの functions.php にコードを追加するのが不安だ
コードスニペット用のプラグインを使えば、functions.php を直接編集せずに管理画面からコードの追加と削除ができる。競合が起きてもすぐに無効化できるため、動作テストにはこちらのほうが安全だ。
この記事のポイント
- Extendify が有効だと「Edit with Elementor」ボタンが管理画面から消えるのは、オンボーディングスクリプトが原因
- 無効化・削除で即座に復旧する。まずはプラグイン一覧から無効化して確認
- Extendify を残したい場合は、functions.php でスクリプトを選択的に停止するコードを使う
- レンタルサーバーのプリインストールプラグインが同様の競合を起こすケースがあるため注意
- 他のプラグイン切り分けは、全無効化→1 つずつ有効化の手順で行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Events Manager 7.3.7更新後に致命的エラーで画面が真っ白になった時の直し方
Events Manager 7.3.7 へ更新した直後にサイトが真っ白になり、WP_HTML_Tag_Processor::apply_attributes_updates() の致命的エラーが発生する現象は、別のプラグインやテーマが開始した出力バッファリングとの競合が原因だ。復旧には、プラグインを 7.3.6 以前に差し戻す。根本解決には、競合相手を特定して対処する必要がある。
なぜ 7.3.7 で WP_HTML_Tag_Processor の致命的エラーが起きるのか
表示されるエラーメッセージは「PHP Fatal error: WP_HTML_Tag_Processor::apply_attributes_updates(): Cannot use output buffering in output buffering display handlers」だ。これは、すでに出力バッファリング（ob_start）が始まっているのに、さらに別の出力バッファリングを入れ子で開始しようとしたときに PHP が送出する。
Events Manager 7.3.7 では、HTML 出力の整形やサニタイズに WordPress の WP_HTML_Tag_Processor を利用している。このクラスは内部的に ob_start() を使うことがあり、タイミングによっては二重バッファリングの禁止に抵触する。単体では問題にならなくても、先に出力バッファリングを開始する別のプラグイン（キャッシュプラグインやページビルダー、一部の翻訳プラグインなど）やテーマが組み合わさると、この競合が表面化する。
WP_HTML_Tag_Processor 経由で 2 重目のバッファを開始しようとして 致命的エラー で停止、画面が真っ白になる。まずはサイトを復旧させる 以前のバージョンに戻す手順
管理画面にアクセスできず真っ白な状態でも、FTP またはサーバーのファイルマネージャーでプラグインを差し戻せば、数分で復旧できる。データベース上のイベント情報や設定は保持される。
/wp-content/plugins/events-manager/ フォルダを events-manager-old にリネームするFTP が使えない場合の代替手段
レンタルサーバーの管理画面にファイルマネージャー機能があるなら、同じ操作ができる。phpMyAdmin から wp_options テーブルの active_plugins 行を直接編集してプラグインの無効化を試みる方法もあるが、操作ミスが起きやすいため、ファイルマネージャーでフォルダ名を変更するほうが安全だ。
競合するプラグインやテーマを特定する手順
7.3.7 へ戻したい場合や、今後のアップデートでも同様の競合を防ぎたい場合は、次の手順で原因の相手を突き止める。
Health Check & Troubleshooting プラグインを使う
「サイトヘルスチェック＆トラブルシューティング」プラグインは、管理者だけが特定のプラグインやテーマを有効化した状態をテストできる公式推奨ツールだ。有効化して「トラブルシューティングモード」を開始すると、サイトの外観を変えずに、Events Manager 7.3.7 だけを有効化した状態でエラーの再現を確認したり、1 つずつ他のプラグインと組み合わせて競合を絞り込める。
手動でプラグインを 1 つずつ検証する
- 管理画面の「プラグイン」→「インストール済みプラグイン」で、Events Manager 以外の全プラグインを無効化する
- テーマを標準テーマ（Twenty Twenty-Five など）に切り替える
- Events Manager 7.3.7 を有効化してエラーが出ないことを確認する
- 1 つずつ他のプラグインを有効化し、エラーが再現した時点で競合相手を特定する
- テーマも元に戻して再現するか確認する
エラーログの取得と開発者への報告
競合相手が特定できたら、Events Manager の開発元に情報を提供することで修正が期待できる。wp-config.php で WP_DEBUG を true にし、WP_DEBUG_LOG も true に設定すると、/wp-content/debug.log にエラーの詳細が記録される。
7.3.7 を有効化し競合プラグインも有効化した状態でエラーを発生させ、そのログを添えて公式フォーラムやサポートに報告する。同時に、競合相手のプラグイン開発者にも情報を伝えると、双方の調整が進みやすくなる。
よくある質問
7.3.7 に更新しなければ、この問題は起こらないのか
その通りだ。Events Manager 7.3.6 では WP_HTML_Tag_Processor を利用していないため、出力バッファリングの競合は発生しない。セキュリティ上や機能上の理由でアップデートしたい場合は、競合相手を特定してから更新するか、修正版のリリースを待つことを推奨する。
プラグインを削除してもイベントのデータは消えないか
Events Manager の予約データやイベント情報、設定はデータベースに保存されている。管理画面からプラグインを削除しても、これらのデータは保持される。ただし、完全に削除した場合、プラグイン側のアンインストール処理で消える可能性もあるため、事前にバックアップを取っておくとより安全だ。
他のプラグインでも同じようなエラーは出る可能性があるのか
WP_HTML_Tag_Processor は WordPress 本体の機能であり、他のプラグインでも利用される可能性がある。出力バッファリングを多用するプラグイン（キャッシュ系、出力圧縮系、外部出力を加工する系）と組み合わさると、同種の致命的エラーが起こりうる。発生時は同様の切り分け手順で原因を突き止められる。
管理画面にすら入れない場合、他に試せることはあるか
FTP でプラグインフォルダをリネームするのが最も確実な復旧手段だ。サーバー管理パネルのファイルマネージャーでも同様に操作できる。どうしてもファイルに触れない場合は、サーバー会社のサポートに依頼してリネームや無効化を依頼する方法もある。WP-CLI が使える環境なら wp plugin deactivate events-manager --skip-plugins=events-manager で無効化できる。
この記事のポイント
- Events Manager 7.3.7 の致命的エラーは、他のプラグインやテーマとの出力バッファリング競合で発生する
- 復旧には FTP でプラグインフォルダをリネームし、7.3.6 以前のバージョンに差し替える
- 競合相手は「サイトヘルスチェック＆トラブルシューティング」プラグインで安全に特定できる
- エラーログを添えて開発者に報告すれば、今後の修正を促せる
- プラグイン削除ではイベントデータは原則消えず、データベースに残る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceアナリティクスでOops something went wrongエラーが出た時の直し方
WooCommerce を 10.6.1 にアップデートした直後、アナリティクス概要に「Oops something went wrong」と表示され、ブラウザコンソールに TypeError: t(…)(…).tz is not a function というエラーが記録される場合、JavaScript のタイムゾーンライブラリを巡るプラグイン競合か、キャッシュの不整合が原因だ。まず全プラグインの無効化と標準テーマへの一時的な切り替えで原因を特定し、競合するプラグインを見つけ出すことから始める。
なぜ WooCommerce アナリティクスで tz is not a function エラーが起きるのか
WooCommerce の管理画面アナリティクスは、内部的に Moment.js とそのタイムゾーン拡張を使い、日付や時間の演算をおこなっている。10.6.1 では JavaScript アセットの読み込み順や依存関係に変更が入ったため、別のプラグインやテーマが同じ Moment.js タイムゾーンライブラリを異なるバージョンで読み込んでいる場合に .tz メソッドが上書きされるか、存在しない状態になり、今回の TypeError が発生する。
また、ブラウザやサーバー側のキャッシュに古いスクリプトが残っていると、管理画面で本来動くはずの新しいコードと混ざり、同様のエラーが出ることもある。まずは「どの拡張機能やテーマが影響しているか」を切り分けるのが近道だ。
エラーの原因を特定する手順
上図の手順で、問題の切り分けができる。WooCommerce 本体だけを有効にした状態でアナリティクスが正常に動けば、あとは再有効化の過程でエラーを再現させるプラグインを見つければよい。
全プラグインを無効化して競合を確認する
「プラグイン」→「インストール済みプラグイン」画面で、全てのプラグインにチェックを入れ、「一括操作」から「停止」を実行する。WooCommerce だけは残すか、最初はすべて停止し、その後 WooCommerce だけ有効化し直す。この状態で管理画面の「WooCommerce」→「アナリティクス」を開き、エラーが出ないか確認する。
テーマを Storefront など標準テーマに切り替える
有効化しているテーマの functions.php やフックが、管理画面の JavaScript 読み込みに干渉しているケースは意外に多い。「外観」→「テーマ」で Storefront や Twenty Twenty-Five など公式の軽量テーマに一時的に切り替え、同じくアナリティクス画面を確認する。
ブラウザキャッシュとサーバーキャッシュをすべて削除する
キャッシュ系プラグイン（W3 Total Cache、WP Rocket など）を使っている場合は管理画面からキャッシュを全削除する。さらにブラウザでシークレットウィンドウ（プライベートブラウジング）を開き、そちらで管理画面にログインしてテストすると、ローカルキャッシュの影響を排除できる。サーバー側で OPcache や Redis オブジェクトキャッシュを導入している場合は、それらのクリアもおこなう。
プラグインを1つずつ再有効化して原因を突き止める
無効化状態でエラーが消えたら、プラグインを1つ有効化するごとにアナリティクス画面を再読み込みし、エラーの再発をチェックする。再現したプラグインが競合元だ。よくあるのは、カスタムレポート系、日付や予約管理、多言語対応（WPML や Polylang）、ページビルダーの管理画面用スクリプトを追加するタイプのプラグインだ。
競合するプラグインを特定したあとの恒久対策
原因のプラグインが判明しても、サイト運営上どうしても外せない場合がある。そのときは、問題のスクリプトだけを管理画面のアナリティクスページでのみ読み込まないようにする手がある。
以下のコードを子テーマの functions.php に追加すると、特定のスクリプトをアナリティクス画面で解除できる。ここでは例として「moment-timezone」ハンドルを一旦解除し、WooCommerce が想定する正しいバージョンを再登録する方法を示す（実際のハンドル名は競合元により異なるため、ブラウザのデベロッパーツールで確認する）。
add_action( 'admin_enqueue_scripts', function( $hook ) {
if ( false === strpos( $hook, 'woocommerce_page_wc-analytics' ) ) {
return;
}
wp_dequeue_script( 'moment-timezone' );
wp_deregister_script( 'moment-timezone' );
wp_enqueue_script( 'moment-timezone', includes_url( 'js/moment-timezone.min.js' ), array( 'moment' ), null, true );
}, 100 );この例では WordPress 本体バンドルの moment-timezone を読み直しているが、WooCommerce が読み込むパスとは異なる場合がある。より安全なのは、競合プラグイン側の更新を待つか、Asset CleanUp 系のプラグインで該当スクリプトを該当ページでのみブロックする方法だ。
それでも直らない場合の応急処置としての WooCommerce のロールバック
どうしてもすぐにエラーを止めたいときは、WooCommerce を問題のなかったバージョン（例：10.5.2）に戻す方法がある。無料プラグイン「WP Rollback」を使えば、管理画面からワンクリックで以前のバージョンにダウングレードできる。
「プラグイン」→「新規追加」で WP Rollback をインストールし有効化すると、プラグイン一覧の WooCommerce に「ロールバック」リンクが現れる。そこから 10.5.2 を選択し、ロールバックを実行する。ただし、これは一時しのぎであり、セキュリティ修正などが含まれている場合はリスクがあるため、問題の根本解決を優先する。
よくある質問
プラグインをすべて無効化してもエラーが消えないのはなぜか
テーマの functions.php や子テーマに管理画面用のスクリプトを追加している可能性が高い。必ず標準テーマ（Storefront や Twenty Twenty-Five）に切り替えて確認する。また、ブラウザ拡張機能やサーバー側のキャッシュが残っている場合もエラーが継続する。
キャッシュを削除しても改善しない場合はどうするか
ブラウザのシークレットウィンドウを使うか、別のブラウザでテストする。サーバー側で OPcache や Varnish、CDN のキャッシュが効いている場合は、そちらも合わせてクリアする。WP CLI が使えるなら wp cache flush も試す。
特定のプラグインが原因とわかったが、そのまま使い続けたい
プラグイン開発元に WooCommerce 10.6.1 への対応状況を問い合わせ、アップデートを待つのが最も確実だ。緊急時は、前述のコード例や Asset CleanUp で競合を回避する方法があるが、サイト全体の動作確認を十分におこなったうえで適用する。
WooCommerce をダウングレードしても問題ないか
ダウングレードすると、10.6.1 で修正されたセキュリティ上の問題や不具合が再発する可能性がある。あくまで原因究明と修正が終わるまでの一時的な措置と考え、早急に恒久対策を講じる。
同じエラーがフロントエンドのカートやチェックアウトでも出る
管理画面だけでなくフロントエンドでも同様の TypeError が発生する場合、テーマかキャッシュプラグインの JavaScript 最適化機能（結合・圧縮）が原因になっていることが多い。キャッシュプラグインの設定で JavaScript の結合を一時的に無効にし、テーマを標準テーマに切り替えて症状が消えるか確認する。
この記事のポイント
- WooCommerce 10.6.1 でアナリティクスに tz is not a function エラーが出るのは JavaScript のタイムゾーンライブラリ競合かキャッシュ不整合
- プラグイン全無効化＋標準テーマへの切り替えで原因を特定し、1つずつ再有効化して競合プラグインを特定する
- 競合プラグインが見つかったら、更新を待つか functions.php でスクリプトを制御する
- 緊急時は WP Rollback で WooCommerce を一時的にダウングレードできるが、恒久対策が優先
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AI EngineとJetpackが衝突してGeminiが使えない時の解決策
AI Engine プラグインをバージョン 3.5.5 以降にアップデートすれば、この問題は即座に解決する。根本原因は Jetpack が REST API に追加する整数型 enum フィールドを、Google Gemini がツール定義で拒否していたことにある。AI Engine の開発者がこのスキーマ生成ロジックを修正し、文字列型以外の enum を自動除去するようになった。
どのようなエラーが発生するのか
Desktop Commander で AI Engine を MCP サーバーとして管理モードで接続し、AI モデルに Google Gemini を指定すると、次のようなエラーで通信が失敗する。
「GenerateContentRequest.tools[0].function_declarations[30].parameters.properties[jetpack_publicize_connections].items.properties[status].enum: only allowed for STRING type」という趣旨のエラーが返る。翻訳すると「enum は STRING 型にしか使えない」という厳格な制約に違反した形だ。
管理画面では具体的に「AI Engine が Gemini API からの応答に失敗しました」といった形で表示され、チャットが開始できないか、途中で止まる。管理モードでなければ発生しないエラーだ。
なぜ Jetpack と AI Engine が衝突するのか
核心は Google Gemini API の「ツール定義」に対する極めて厳格なバリデーションにある。Gemini は利用可能な関数のパラメータをスキーマで受け取るが、enum（許容値の固定リスト）を使う場合、そのデータ型を必ず文字列にしなければならない。
一方 Jetpack は、WordPress の投稿作成や更新時に使われる REST API エンドポイントへ、ソーシャルメディア連携用のフィールドを動的に追加している。その中の jetpack_publicize_connections フィールドには status というパラメータがあり、Jetpack はこれを整数型の enum（[0, 1]）として定義している。
AI Engine が WordPress のスキーマ全体を走査して Gemini 向けのツールリストを組み立てる際、この整数型 enum をそのまま継承してしまう。その結果、Gemini API がリクエスト全体を「400 Bad Request」ではねつける流れだ。
読み取り専用モードならば投稿作成系のツールが含まれないため、このエラーは発生しない。管理モードで書き込み権限を付与する場合に限って表面化する。
AI Engine 3.5.5 以降へのアップデートで恒久修正する
AI Engine の開発者によって、バージョン 3.5.5 で根本的な修正が加えられた。ツールスキーマを作成する際、文字列型以外の enum 定義を自動的に除去する処理が追加されている。
スキーマキャッシュのバージョンも同時に引き上げられているため、更新後に手動でキャッシュをクリアする必要はない。自動的に再生成され、Jetpack の整数型 enum は除去された状態でツールリストが構築される。
どうしてもアップデートできない場合の手動修正
何らかの理由で AI Engine を最新版にできない場合、子テーマの functions.php または Code Snippets プラグインに以下のコードを追加し、Jetpack の整数型 enum フィールドを強制的に文字列型へ変換できる。
<?php
/**
* Jetpack と AI Engine、Google Gemini の競合を修正する。
* Jetpack の status enum フィールドを文字列型に変換する。
*/
add_action( 'wp_enqueue_scripts', 'enqueue_parent_styles' );
function enqueue_parent_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
add_action( 'rest_api_init', 'fix_jetpack_enum_for_gemini', 9999 );
function fix_jetpack_enum_for_gemini() {
global $wp_rest_additional_fields;
if ( ! empty( $wp_rest_additional_fields ) ) {
foreach ( $wp_rest_additional_fields as $post_type => $fields ) {
if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections'] ) ) {
if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status'] ) ) {
// 問題を起こす整数 enum を除去
unset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['enum'] );
// データ型を文字列に明示
$wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['type'] = 'string';
}
}
}
}
}
?>コード追加だけでは修正されないケースがある。AI Engine はツールリストをデータベースに強力にキャッシュしているため、キャッシュを強制的に再生成させる必要がある。
Jetpack を無効化した状態でチャットを実行することで、AI Engine は Jetpack 関連フィールドのないスキーマを新規に作成する。Jetpack を再有効化した後は上記のフィルタが働き、問題の enum がスキーマに混入することはなくなる。
よくある質問
Jetpack を使っていなければこの問題は起こらないのか
Jetpack の jetpack_publicize_connections フィールドが原因であるため、Jetpack を導入していなければ発生しない。ただし、他のプラグインも整数型 enum を REST API に追加している場合は似たエラーが出る可能性がある。その場合も AI Engine 3.5.5 以降であれば同様に自動除去される。
読み取り専用モードではなぜ問題ないのか
読み取り専用モードでは、投稿の作成や更新といった書き込み系のツールが Gemini に送信されない。問題の jetpack_publicize_connections フィールドは投稿作成時に登場するため、ツールリストから除外される。管理モードだけが影響を受ける。
AI モデルが Gemini 以外でも同じエラーは出るか
このエラーは Gemini のツール定義バリデーションが特に厳格なために発生する。OpenAI の GPT シリーズなど、他の AI モデルでは整数型 enum を許容するものもあるが、根本原因はスキーマにあるため、どのモデルでも潜在的な問題になりうる。AI Engine 3.5.5 の修正で全モデルに対応できる。
AI Engine 3.5.5 にアップデートした後、スキーマキャッシュは本当に自動クリアされるのか
開発者によれば、スキーマキャッシュのバージョンナンバーが引き上げられているため、更新後の初回リクエスト時に自動的に再生成される。手動でキャッシュを削除する操作は不要。もし不安があれば、AI Engine の設定画面からキャッシュを手動クリアしても問題ない。
この記事のポイント
- AI Engine 3.5.5 以降のアップデートで根本解決する
- 原因は Jetpack の整数型 enum を Gemini が拒否するため
- 読み取り専用モードでは書き込み系ツールが送信されず問題は出ない
- 手動修正する場合は Jetpack 一時無効化によるキャッシュ再生成が必須
- 修正後は文字列型以外の enum が自動除去され、あらゆる AI モデルで安定する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
QSMプラグイン更新後にメディア画面のレイアウトが崩れた時の直し方
特定のプラグインを更新した直後にメディアアップロード画面のレイアウトが崩れた場合、まず該当プラグインのバージョンを更新前の状態に巻き戻すまたは一時的に無効化し、公式サポートへ報告するのが最も早い解決策だ。根本原因はプラグインが管理画面に読み込む CSS や JavaScript の競合にあり、プラグイン側の修正を待つ必要がある。
なぜ QSM プラグインの更新後にレイアウトが崩れるのか
プラグインのバージョンアップでメディアアップロード画面に限って表示が崩れる現象は、Quiz And Survey Master（QSM）v11.1.1 で報告されている。このバージョンで管理画面の他ページ向けに追加された CSS や JavaScript が、メディアライブラリのモーダルやグリッドレイアウトと競合するケースが主な原因だ。
WordPress の管理画面では複数のプラグインが同じ画面にスタイルを適用できる。あるプラグインが独自のフォーム用スタイルをグローバルに出力した場合、メディアアップローダーのドラッグ＆ドロップ領域やサムネイル一覧の幅計算が崩れ、ボタンが画面外に飛び出したり画像が縦一列に並んだりする。
この問題は QSM 側が読み込む管理画面用 CSS のセレクタ範囲が広すぎることに起因する。プラグイン開発者が自プラグインの設定画面だけに限定してスタイルを当てるつもりが、WordPress 全体の管理画面に影響するセレクタを使ってしまうことで発生する。
QSM を最新にしたままレイアウト崩れを直す方法
QSM プラグインに依存しているサイトでは単純な無効化が難しいため、まずはプラグイン公式の修正を待ちつつ、以下のいずれかの方法で一時的にレイアウトを正常化できる。
過去の安定バージョンに巻き戻す
WordPress ではプラグインのバージョンを手動でダウングレードできる。まず管理画面の「プラグイン」から QSM を一度削除する。削除してもアンケートデータや設問はデータベースに残る。
次に QSM の公式プラグインページ下部にある「以前のバージョン」 から v11.1.0 以前の安定版 ZIP を入手し、「プラグイン」→「新規追加」→「プラグインのアップロード」でインストールする。有効化後、メディアアップロード画面を再読込すればレイアウトは戻る。
このデモはレイアウト崩れが発生した際の切り分けとバージョン巻き戻しの流れを示している。プラグイン削除で既存データが消える心配はなく、過去バージョンの再適用で一時的に運用を継続できる。
管理画面の特定ページだけで無効化するコードを使う
QSM を有効にしたまま管理画面のメディアページだけでプラグインのスタイルを外したい場合、functions.php にフィルターフックを追加する方法がある。テーマの functions.php や Code Snippets プラグインを用いて以下のコードを追加する。
add_action('admin_enqueue_scripts', function($hook) {
if ('upload.php' === $hook || 'media-new.php' === $hook) {
wp_dequeue_style('qsm-admin-style'); // 実際のハンドル名に応じて変更
}
}, 100);上記の qsm-admin-style は実際に登録されているスタイルシートのハンドル名に置き換える必要がある。ハンドル名は QSM のプラグインソースコードを確認するか、ブラウザの開発者ツールで読み込まれている CSS ファイルの ID 属性から特定できる。
この方法はプラグインのアップデートでハンドル名が変わると再設定が必要になるため、あくまで暫定対応として位置づけるのが現実的だ。
自動更新を一時停止して様子を見る
プラグインの自動更新が有効になっている環境では、意図しないバージョンアップで管理画面が壊れるリスクが常にある。QSM を v11.1.0 に戻したら、プラグイン一覧で QSM の「自動更新を有効化」のチェックを外しておく。WordPress 本体の「更新」画面からも状況を監視し、次期バージョン v11.1.2 以降で修正パッチがリリースされたタイミングで手動更新する方が安全だ。
根本解決のためにすべきこと
レイアウト崩れが特定のプラグインに起因することが分かったら、積極的にプラグイン開発者へ報告するのが最も建設的な対応だ。QSM の公式サポートフォーラムや GitHub リポジトリで、以下の情報を添えて報告すれば修正が加速する。
- 現象が起きた WordPress のバージョンと PHP バージョン
- QSM のバージョン（v11.1.1）
- メディアアップロード画面のスクリーンショット
- ブラウザの開発者コンソールに表示された JavaScript エラー
開発者コンソールの確認方法は、Google Chrome の場合、Windows では F12 キー、Mac では Cmd + Option + I で「Console」タブに切り替え、赤字で表示されたエラーをキャプチャする。
開発者にとってコンソールエラーと発生条件の詳細は修正箇所を特定する決定的な手がかりになる。報告するときは感情的な内容を避け、「メディアページを開いたときだけレイアウトが崩れる。コンソールには ○○ というエラーが出ている」と具体的に伝えるとよい。
よくある質問
プラグインを無効化せずにメディアアップロードだけ使う方法はあるか
投稿画面の「メディアを追加」ボタンからもファイルをアップロードできる。メディアライブラリのグリッド表示が崩れていても、このモーダル画面では正常に動作するケースが多い。
QSM が原因かどうかを確実に特定するにはどうすればいいか
最も確実なのは Health Check & Troubleshooting プラグインを使ったトラブルシューティングモードだ。このモードではログイン中の自分だけにプラグインの無効化が適用されるため、サイト訪問者には影響を与えずに QSM のオンオフを切り替えられる。
バージョンを戻すとアンケートのデータは消えるのか
消えない。QSM の設問や回答データはデータベースの専用テーブルに保存されている。プラグインを削除しても WordPress の標準動作ではテーブルが削除されないため、再インストール後にすべてのデータが復元される。
子テーマの functions.php を編集するのが不安だ
Code Snippets プラグインを使えば管理画面から安全に PHP コードを追加できる。文法エラーがあるとスニペットが自動で無効化されるため、サイト全体が真っ白になるリスクを回避しやすい。
今回の問題は WordPress 本体のせいか
違う。WordPress 本体の更新ではなく、QSM プラグインの特定バージョン（v11.1.1）が原因だ。WordPress コアにはメディア画面のレイアウトに関する既知の不具合は報告されていない。
この記事のポイント
- QSM v11.1.1 への更新が原因でメディアアップロード画面のレイアウトが崩れる
- 即効対策は v11.1.0 以前の安定版に巻き戻すこと
- 暫定対策として functions.php で特定ページだけスタイルを停止できる
- 恒久解決にはプラグイン開発者への詳細なエラー報告が不可欠
- 自動更新を停止して次期バージョンでの修正を待つのが安全
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce支払いページで重大エラーが出る原因と直し方
WooCommerce の「支払いページ（Pay for Order）」で「このサイトで重大なエラーが発生しました」と表示されたり、決済フォームが読み込まれない場合、原因はほぼプラグインの競合かテーマのテンプレート不整合だ。管理画面からエラーログを確認し、プラグインの全無効化と標準テーマへの切り替えで原因を特定する手順を取れば、数十分で復旧できる。
Pay for Order ページで重大なエラーが出る原因
WooCommerce の Pay for Order（支払い）ページは、注文確認メールやマイアカウントの「注文の支払い」リンクから遷移する専用のチェックアウト画面だ。通常のチェックアウトと異なり、すでに作成済みの注文に対して決済だけを行う設計のため、内部で呼ばれる処理やパラメータが少し異なる。
決済プラグインやカスタムコードがこの固有のフローに対応していない場合、「このサイトで重大なエラーが発生しました」という WordPress の致命エラー画面が表示されたり、決済フォーム部分だけが真っ白になる。特に注文件数が多いサイトほど、Pay for Order の動作不良は直接売上に響くため即時対応が必要だ。
支払いページだけが壊れる仕組み
WooCommerce の内部では、Pay for Order ページの URL に pay_for_order=true と key（注文キー）というパラメータが渡される。通常のチェックアウトとは異なり、カートの中身を参照するのではなく、指定された注文 ID のデータを直接読み込んで決済処理を開始する流れだ。
このとき、決済ゲートウェイプラグインや注文カスタマイズ系プラグインが「カートが空」「注文データが見つからない」といった前提でコードを書いていると、Pay for Order のフローでは関数がエラーを吐き、画面全体が停止する。また、テーマが checkout/payment.php などのテンプレートを上書きしている場合、WooCommerce のバージョン更新に追従できておらず古いテンプレートが原因で決済フォームが欠落することもある。
エラーの詳細を特定する手順
Pay for Order ページでエラーが発生したら、まずエラーログを有効にして原因の PHP エラーを記録させる。WordPress 5.2 以降のサイトヘルス機能や、wp-config.php のデバッグ定数を使えば、エラーメッセージをファイルに出力できる。画面に何も表示されない場合でもログには原因が記録されているケースがほとんどだ。
デバッグログを有効化してエラーを特定する流れ。ログのパスがわからない場合は管理画面の「ツール」→「サイトヘルス」→「情報」タブの「WordPress 定数」セクションで確認できる。
wp-config.php に追加するデバッグ定数
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY を false にすることで、エラーを画面に表示せずログファイルだけに出力する。公開中のサイトでもこの設定なら訪問者にエラーメッセージを見せずに原因を特定できる。debug.log は /wp-content/ ディレクトリに生成される。
ログに記録されているエラーメッセージには、発生元のプラグインディレクトリ名やテーマ名が含まれる。たとえば /wp-content/plugins/woocommerce-gateway-stripe/ のようなパスが出れば、その決済プラグインが Pay for Order に対応できていない可能性が高い。
エラーログから原因を読み解く
Pay for Order ページで頻出するエラーには次のようなパターンがある。PHP の致命的エラー（Fatal error）では「未定義の関数を呼び出した」「null に対してメソッドを実行した」といったメッセージが記録される。特に Call to a member function 〜 on null は、注文オブジェクトの取得に失敗している典型的な兆候だ。
決済ゲートウェイプラグインが WC()->cart や WC()->session に依存している場合、Pay for Order のフローではこれらのオブジェクトが期待通りに動作せずエラーになる。ログにプラグイン名が出たら、まずそのプラグインを開発元のサポートに報告し、Pay for Order 対応の有無を確認するのが確実だ。
プラグイン競合を切り分ける短時間の方法
管理画面にアクセスできるなら、プラグインの一括無効化とテーマ切り替えによる切り分けが最も速い。この作業は公開中のサイトには影響が出るため、メンテナンスモードを有効にするか、低トラフィック時間帯に実施する。
プラグイン競合の切り分けで目指す最終状態。すべての不要プラグインを無効化し標準テーマに切り替えた状態で動作すれば、原因は無効化した中にある。
全プラグインを一括無効化して一つずつ再有効化する
WooCommerce 本体と、その動作に必須な決済プラグインを除くすべてのプラグインを一度無効化する。特に注意すべきは、キャッシュ系プラグイン、セキュリティプラグイン、そして注文カスタマイズ系のプラグインだ。Pay for Order の URL パラメータをキャッシュやリダイレクトルールが干渉して弾いているケースも多い。
無効化後に Pay for Order ページが正常に表示されれば、原因は無効化したいずれかのプラグインにある。次に、WooCommerce と決済プラグイン以外のプラグインを一つずつ再有効化し、その都度 Pay for Order ページを再読み込みしてエラーの再発を確認する。エラーが再発した時点で直前に有効化したプラグインが原因だ。
標準テーマに切り替えてテーマ由来の不具合を除外する
プラグインをすべて無効化しても直らない場合、使用中のテーマが WooCommerce のテンプレートを上書きしている可能性が高い。管理画面の「外観」→「テーマ」から Twenty Twenty-Five などの標準テーマに一時的に切り替え、再度 Pay for Order ページを表示する。標準テーマで問題なく動作するなら、元のテーマ側のテンプレートファイルが原因だ。
切り分け時に注意すべきキャッシュの削除
WooCommerce のチェックアウト周りはキャッシュの影響を強く受ける。プラグインを無効化しても、サーバーキャッシュや CDN キャッシュが残っていると古いエラー画面が表示され続けることがある。管理画面の「WooCommerce」→「ステータス」→「ツール」タブから「WooCommerce の一時データをクリア」「商品の参照カテゴリをカウントする」を実行し、さらに利用中のキャッシュプラグインのキャッシュも全削除してからテストする。
テーマと WooCommerce テンプレートのバージョン不整合を解消する
テーマが WooCommerce のテンプレートファイルを子テーマや独自ディレクトリで上書きしている場合、WooCommerce 本体がバージョンアップするとテンプレートの構造や関数が変更され、古いテンプレートでは Pay for Order の処理に失敗する。特に checkout/form-pay.php や checkout/payment.php は Pay for Order ページで直接使われるファイルのため、上書きされていると影響が大きい。
上書きテンプレートの状態を確認する
管理画面の「WooCommerce」→「ステータス」画面を開き、「テンプレート」セクションを表示する。ここに「上書きあり」と表示されているテンプレートの一覧がある。checkout/form-pay.php が上書きされていて、かつ WooCommerce 本体のバージョンより古いテンプレートバージョンが記載されている場合、このファイルを最新の WooCommerce テンプレートと比較して更新する必要がある。
テンプレートを安全に更新する手順
まず WooCommerce プラグインディレクトリの templates/checkout/form-pay.php を最新の状態で確認し、現在テーマ側で上書きしている同名ファイルと差分を比較する。差分が少ない場合はテーマ側のファイルを最新に置き換え、カスタマイズがある部分だけ必要な修正を手動で適用する。差分が多い場合は、WooCommerce のアクションフックを使ってテンプレート上書きを避ける設計に移行するのが長期的に安全だ。
よくある質問
Pay for Order ページだけがエラーになるのはなぜか
通常のチェックアウトと Pay for Order では WooCommerce 内部のフローが異なり、カートセッションの状態や注文オブジェクトの取得方法が変わる。多くの決済プラグインは通常のチェックアウトだけを想定して開発されているため、Pay for Order の特殊なパラメータを受け取った際に未定義エラーや null 参照が発生する。
管理画面にもアクセスできなくなった場合はどうすればよいか
FTP またはサーバーのファイルマネージャーで /wp-content/plugins/ ディレクトリにアクセスし、エラーの原因と思われるプラグインのディレクトリ名を変更する（例 plugin-name → plugin-name-disabled）。これで強制的にプラグインを無効化できる。復旧後に管理画面から原因の特定を進める。
WooCommerce のステータスページで推奨される PHP 設定はあるか
WooCommerce の推奨 PHP メモリ制限は 256MB 以上、実行時間の上限は 300 秒以上だ。「WooCommerce」→「ステータス」画面の「サーバー環境」セクションで現在値を確認し、不足している場合はレンタルサーバーの管理画面や php.ini から引き上げる。メモリ不足が原因で Pay for Order の処理中にプロセスが停止することもある。
特定の決済プラグインだけが Pay for Order で動かない場合の対処は
まずその決済プラグインの公式サポートに「Pay for Order ページでエラーが発生する」と明記して問い合わせる。急を要する場合は、WooCommerce 標準の銀行振込や代金引換などの決済手段を一時的に有効化して Pay for Order での支払いを受け付けつつ、該当プラグインの修正を待つ運用で売上を止めないようにする。
エラーログに何も記録されない場合はどうすればよいか
JavaScript のエラーが原因で画面が動作しないケースが考えられる。ブラウザの開発者ツール（F12 キー）の「コンソール」タブを開き、Pay for Order ページを読み込んだ際の赤いエラー表示を確認する。jQuery の競合や決済フォームのスクリプト読み込み失敗が主な原因で、PHP ログには記録されない。
この記事のポイント
- Pay for Order ページのエラーは主にプラグイン競合かテーマのテンプレート不整合が原因
- wp-config.php のデバッグ定数でエラーログを取得し原因プラグインを特定する
- 全プラグイン無効化と標準テーマへの切り替えで短時間に原因を切り分ける
- テーマの WooCommerce テンプレート上書きはステータス画面でバージョン確認し最新化する
- JavaScript エラーの場合はブラウザの開発者ツールで別途確認が必要
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている