WP Activity Log v5.6.4でアプリパスワード削除時に500エラーが出る原因と回避策
WP Activity Log v5.6.4を有効化したWordPressサイトで、プロフィール画面からアプリケーションパスワードを取り消すと「このサイトで重大なエラーが発生しました」と表示される場合、プラグインのアップデート待ちでは解決しない。原因はWP Activity Logが汎用のupdate_user_metaフックに対するメタキーの検証を怠っている点にあり、PHP 8ではcount()に文字列を渡すとTypeErrorが発生して致命的エラーになる。この記事では、エラーの仕組みから、手動での回避策、上位互換のためのコードパッチまでを具体的に示す。
エラーの全容と発火する条件
WP Activity Log v5.6.4に収録されたWP_User_Profile_Sensor::event_application_password_added()は、汎用のupdate_user_metaアクションにフックされている。関数シグネチャには$meta_keyが渡されているが、コールバック内でこれを一度も検証しない。代わりにHTTPリファラとREQUEST_URIだけを見て、アプリケーションパスワード変更のリクエストかどうかを判定している。
このため、ユーザーのプロフィール画面からアプリケーションパスワードを取り消すときに、REST APIへのDELETEリクエストが発行される。リファラチェックはプロフィールページを指し、URIチェックも/wp/v2/users/{id}/application-passwords/...を含むため、両方の条件を通過する。ここでBuddyBoss Appのようなプラグインが、同じリクエストのディスパッチ中にlast_activityというユーザーメタを更新すると、本来アプリケーションパスワードのメタを想定していたセンサーが誤ってそのtimestamp文字列を処理してしまう。
致命的エラーの発生箇所とスタックトレース
実運用のログには、次のような未捕捉のTypeErrorが記録される。PHP 8ではcount()の引数が配列またはCountableでない場合、警告ではなくTypeErrorがスローされる。WP Activity Logのコードは文字列をcount()に渡しているため、リクエストが500エラーになる。
スタックトレースを追うと、クラスの203行目でcount( $_meta_value )が呼ばれている。ここで$_meta_valueはtimestampの文字列であり、$old_valueは_application_passwordsの配列である。文字列をcount()に渡すとPHP 8ではTypeErrorが発生し、アプリケーションパスワードの取り消しは実行されないまま処理が失敗する。
第一の対処方法、プラグインの停止で被害を止める
まず、サイトが利用者から見て壊れている状態を早く解消するには、WP Activity Logを停止する。管理画面にアクセスできる場合は「プラグイン」画面からWP Activity Logを無効化する。アクセスできない場合はFTPでwp-security-audit-logディレクトリをリネームする。リネームするとWordPressがプラグインを検出できなくなり、自動的に無効化される。
第二の対処方法、一時的にPHPのエラー表示を止める
WP Activity Logを使い続けたい場合は、PHPのcount()エラーが致命的にならないよう回避策を施す。だが、これは根本解決ではなく症状を隠すだけだ。むしろ、エラー自体を修正するパッチを適用する方が安全である。ただし、プラグインのアップデートで上書きされることを理解した上で、運用上の措置として行うかどうかを判断してよい。
ソースコードを直接修正する根本対応
WP Activity Logの該当ファイルはwp-security-audit-log/classes/WPSensors/class-wp-user-profile-sensor.phpである。コールバックの先頭で、メタキーが_application_passwordsでない場合は早期returnするようガードを追加する。これが今回のエラーを確実に止める最小の修正だ。
public static function event_application_password_added( $meta_id, $user_id, $meta_key, $_meta_value ) {
if ( '_application_passwords' !== $meta_key ) {
return;
}
// 以下、既存の処理
}加えて、防御的措置としてcount()に渡す前に配列キャストを行うと、将来何らかの形で配列以外の値が混入した場合にも致命的エラーを防げる。メタキーガードだけでも今回の症状は解消するが、運用中のサイトでは両方の修正を施しておく方が堅牢だ。
} elseif ( count( (array) $_meta_value ) < count( (array) $old_value ) ) {修正後、コード上の同じパターンが他に残っていないか、deleted_user_metaやadded_user_metaへの登録も確認するとよい。同じクラス内で複数のフックが同様のリファラ＋URIチェックだけに頼っている場合、似た条件のリクエストで誤発火する可能性がある。
PHP 8環境で注意すべきcount()の挙動
PHP 7.xでは、count()に文字列を渡しても警告が出るだけで処理は継続されていた。しかしPHP 8ではTypeErrorとしてスローされるため、これまで表面化しなかったコードの前提ミスが致命的エラーとして現れる。WP Activity Logに限らず、WordPressプラグインの旧コードでは、更新順にこうした潜在バグが発覚することがある。
サイトをPHP 8系へ更新した直後に、特定の操作でのみ500エラーが出る場合は、エラーログにcount(): Argument #1 ($value) must be of type Countable|array, string givenのような記録が残っていないか確認する。該当する場合は、エラーを起こしているプラグインのコードが文字列をcount()に渡している可能性が高い。
- count()に文字列を渡すと警告のみ
- 処理は継続される
- 潜在的バグが表面化しない
- TypeErrorがスローされる
- 致命的エラーで500応答
- 操作が完了しない
よくある質問
WP Activity Logを無効化すると監査ログは消えますか？
無効化しても記録済みの監査ログはデータベースに残る。ただし、無効化している間に発生したイベントは記録されない。復旧後にプラグインを再度有効化すれば、既存のログを閲覧できる。
BuddyBoss Appが原因なのでBuddyBoss側を停止すれば直りますか？
BuddyBoss Appがユーザーメタを更新するタイミングが発火に重なっているが、根本的な誤動作はWP Activity Log側のフック設計にある。BuddyBoss Appが動いていなくても、別のプラグインが同様にRESTリクエスト中にユーザーメタを更新すれば同じエラーが起きる。
WP Activity Logのバージョンを下げれば回避できますか？
過去のバージョンが同じコードを含んでいる場合、単純なダウングレードでは解消しない。今回のクラスのコールバックを変更せずに添付された報告では、v5.6.5にも修正が含まれていないと指摘されている。信頼できる最新の修正が入るまでは、上記のコードパッチを適用するか、プラグインを停止する方が確実だ。
プロフィール画面でアプリパスワードを管理できる権限がないユーザーも影響を受けますか？
このエラーはアプリケーションパスワード管理を行えるユーザーに限らず、同じリクエスト経路でユーザーメタが更新される状況であれば発火しうる。ただ、発火条件としてプロフィール画面からの操作と、REST APIのURIにアプリケーションパスワードのパターンが含まれることが必要になる。
プラグインをアップデートしたら勝手に直りますか？
プラグインの開発者がメタキーガードを実装したバージョンをリリースすれば直る。ただし、現時点で修正が含まれているかはリリースノートとソースを確認する必要がある。修正が見つからないうちは、手動パッチか無効化で運用を守る。
この記事のポイント
- WP Activity Log v5.6.4の500エラーはPHP 8のcount()エラーが原因
- コールバックがメタキーを検証せず、アプリパスワードと無関係なユーザーメタで誤発火する
- メタキーガードを追加するコードパッチが根本解決になる
- 配列キャストを加えるとPHP 8の厳格なエラーに強いコードになる
- 修正版が出るまでは、プラグイン停止かパッチ適用で被害を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce ソーシャルログインで Facebook 連携時に Constant Contact が切断される原因と対処
WooCommerce にソーシャルログインを導入しているサイトで、ユーザーが Facebook アカウントを初めて連携しようとすると Constant Contact Forms の接続が切れる症状は、OAuth トークン処理の競合が起きている。Constant Contact Forms を無効化すると Facebook 連携が成功することから、プラグイン同士の干渉を切り分け、接続をリセットするのが解決の出発点だ。
なぜ Facebook 連携で Constant Contact が切断されるのか
この症状は、WooCommerce Social Login が Facebook の認可コードを処理するタイミングで、Constant Contact Forms の保有する OAuth トークンが無効化されることが原因だ。Constant Contact Forms のデバッグログに「invalid_grant（認可コードが無効または期限切れ）」と記録されるのは、API トークンの再取得時に、すでに使われたか上書きされた状態のコードを参照していることを示している。
両方のプラグインは、OAuth2 という同じ認証の仕組みを使う。Constant Contact Forms はメール配信 API に接続するため、WooCommerce Social Login は Facebook や Google のアカウント認証のために、それぞれトークンを保存・更新する。この 2 つのプラグインが同じ WordPress の保存領域（オプションやセッション）を参照していると、Facebook 連携の処理が Constant Contact 側の認可コードを破壊して切断に至る。
重要なのは、Constant Contact の登録フォームをログイン画面やコメント欄に設置していなくても、この競合は起こり得る。ソーシャルログインの実行自体がバックグラウンドで Constant Contact の API 通信を誘発し、無効化されたトークンで再取得を試みて切断されるからだ。
プラグイン競合を切り分けて原因を特定する手順
ソーシャルログインと Constant Contact Forms のどちらが原因かを特定するには、片方ずつ無効化しながら動作を確認する。以下の手順は、両プラグインが同時に有効な場合の症状を、競合の組み合わせごとに明確にするためのものだ。
このデモは、競合の組み合わせを 4 段階で特定する流れを示している。STEP 2 で Facebook 連携が成功すれば、Constant Contact Forms が干渉していることが確定する。
Constant Contact Forms の接続を復旧する方法
競合が確認できたら、Constant Contact Forms のトークンをリセットして再接続し、WooCommerce Social Login との共存を調整する。最初に行うのは接続情報の完全な初期化だ。
このデモは、エラー状態と復旧後の違いを示したイメージである。復旧の手順は以下の 4 つに整理できる。
Constant Contact Forms の接続を完全にリセットする
管理画面の Constant Contact Forms 設定から接続を解除し、その後データベースに残ったトークン情報を削除する。具体的には wp_options テーブルにある constant_contact や cc_ を含む transient を対象にする。削除後、再度 Constant Contact アカウントに接続して新しいトークンを取得する。
Facebook を一時的にオフにして Google だけで運用する
WooCommerce Social Login の設定で Facebook を無効化し、Google アカウントのみ許可する。この状態で Constant Contact Forms の接続が安定するなら、Facebook の OAuth フローに固有の競合であることが濃厚だ。ユーザーには Google ログインを案内し、Facebook 連携の復旧を急ぐ必要がなければこのまま運用してもよい。
トークン保存領域の競合を確認する
両プラグインが同じ wp_options キーやセッション変数を参照していないか、wp_options テーブルの内容を直接確認する。特に _transient_ で始まるキーを調べ、両プラグインが似た名称のキーを使っている場合は、そのカスタマイズが必要か検討する。この作業はデータベースに詳しい担当者が行うのが安全だ。
ログインフックを制御して競合を防ぐ
Constant Contact Forms が wp_login や authenticate のフックでトークン更新を実行している場合、WooCommerce Social Login の処理中だけそのフックを外すカスタムコードが有効なことがある。この手法はテーマの functions.php か、独自の小規模プラグインに追加する。コードを書く前に必ずバックアップを取り、テスト環境で動作を確認する。
ソーシャルログインとメール配信プラグインを共存させる設定
接続後の動作テストを必ず行う
Constant Contact Forms を再接続したあとは、以下のテストを毎回実施する。新しいユーザーで Facebook アカウントを連携して、Constant Contact Forms の接続ステータスが維持されるか確認する。既存ユーザーの Facebook ログインでも問題が起きないか確認する。Constant Contact のデバッグログに invalid_grant が記録されていないか確認する。これをテンプレート化しておけば、プラグイン更新のたびに安全に検証できる。
プラグイン更新前に競合を確認する
WooCommerce Social Login も Constant Contact Forms も頻繁に更新される。特に片方のプラグインが OAuth ライブラリを更新すると、再び競合が発生する可能性がある。本番環境に反映する前に、ステージング環境で Facebook 連携と Constant Contact の接続維持を確認しておくのが確実だ。
よくある質問
Google アカウント連携では問題が起きないのに Facebook だけで起きるのはなぜ？
Facebook の OAuth フローと Google の OAuth フローでは、使用する認可コードの形式や保存方法が異なる。Facebook の処理が Constant Contact Forms のトークン保存領域と衝突しやすい組み合わせになることがある。
Constant Contact Forms が切断されたまま放置すると何が起きる？
メール配信フォームからの登録が Constant Contact のリストに反映されなくなる。サイト来訪者はフォーム送信が成功したように見えても、実際には配信リストに追加されていない状態が続く。
データベースの transient を削除しても安全？
有効期限が切れた transient を削除するのは安全だ。ただし、接続中のトークンが保存されている場合、削除すると再接続が必要になる。削除する前に対象のキー名を控えておき、バックアップを取ってから行う。
この競合は特定のバージョンだけで起きるのか？
バージョンに依存する部分もあるが、OAuth を共用するプラグインの組み合わせでは長年報告されている。プラグインのバージョンが古いままの場合は、まず両方を最新化してから再確認する。
この記事のポイント
- Facebook 連携時に Constant Contact Forms が切断されるのは OAuth トークン競合が原因
- デバッグログの invalid_grant は認可コードの無効化を示すサイン
- Constant Contact Forms を無効化すると Facebook 連携が成功するかで切り分ける
- 接続リセット後に Google のみ運用、または保存領域の分離で対処する
- 接続復旧後は新規ユーザーの Facebook 連携テストを毎回実施する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerceのStripe決済が自動更新後に消えた時の原因と対処法
WooCommerceのStripe決済プラグインを自動更新した直後に、設定画面の「決済」タブからStripeが丸ごと消えた場合は、更新時に発生した致命的エラーか、他の決済プラグインとの競合が主な原因だ。まず「ステータス」→「ログ」で fatal-errors の有無を確認し、競合を切り分けた後、キャッシュ削除と設定の再保存で復旧できる。セキュリティパッチ自体がStripe決済を意図的に隠すことはない。
Stripe決済が消える原因は何か
Stripe決済プラグインのアップデート後に、WooCommerceの「設定」→「決済」画面からStripeの項目が消える現象には、いくつかの典型的な原因がある。セキュリティパッチの更新処理そのものがStripeを除外する仕様は存在しないため、まず「更新に伴って別の何かが壊れた」と考えるのが正しい。
最も多いのは、アップデート処理中に発生した致命的エラーだ。プラグイン更新時にPHPのメモリ不足やファイルの不整合が起きると、WooCommerceがプラグインを正常に読み込めなくなり、決済方法の一覧からStripeが消える。管理画面には「このサイトで重大なエラーが発生しました」と表示される場合もあれば、画面に何も表示されず設定一覧だけが欠けるケースもある。
次に多いのがプラグイン競合だ。複数の決済ゲートウェイ系プラグインを導入していると、アップデート後に読み込み順序が変わって競合し、Stripeが一覧から漏れることがある。WooCommerceの決済方法はフィルターを通して一覧に追加されるため、競合相手のプラグインがエラーを出すと後続の読み込みが止まり、Stripeが表示されない。
キャッシュが原因になるケースも見逃せない。アップデート直後にサーバーキャッシュやオブジェクトキャッシュへ古い状態が残っていると、管理画面の一覧にだけ反映されずStripeが消えて見える。ブラウザキャッシュでも同様の現象が起こる。
このデモは、決済タブでStripeが消えた状態から復旧した状態への変化を示している。ここから先の手順を順に実行すれば、原因の特定と復旧まで進められる。
致命エラーログで原因を特定する手順
最初に確認すべきは、WooCommerceが記録している致命的エラーのログだ。管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開くと、保存されているログの一覧が表示される。この中に fatal-errors で始まる名前のログがあれば、アップデート時になんらかの致命的エラーが発生している。
fatal-errors ログを開くと、エラーが発生した日時、原因となったプラグインやテーマ名、エラーが起きたファイルのパスが確認できる。Stripeプラグインのファイルパスが記録されていれば、そのエラーが原因で一覧から消えた可能性が高い。ログの内容は専門的なPHPの記述が多いが、どのプラグインでエラーが出たかを特定できれば十分だ。
ログに何も出ていない場合は、WP_DEBUG（デバッグモード）を有効にして再現させる方法もある。wp-config.php にデバッグ定数を追記してから決済設定画面をリロードすると、画面にエラー文言が直接表示される。ただし共用サーバーでは本番サイトでデバッグをオンにするとセキュリティ上望ましくないため、確認後は必ず元に戻す。
プラグインの競合を切り分ける
致命エラーログが出ていない、または出ていても原因が特定できない場合は、プラグイン競合の切り分けに進む。決済系プラグインを複数導入している環境では、どれか1つがStripeの読み込みを妨げている可能性がある。
切り分けの基本は「一度に全部を無効化しない」ことだ。Stripeを除く他の決済プラグインを1つずつ無効化し、そのつど「設定」→「決済」画面をリロードしてStripeが表示されるか確認する。たとえば「WooCommerce PayPal Payments」や「Amazon Pay」などを無効化するたびに確認を繰り返すと、競合相手を特定できる。
決済プラグインだけでなく、最近更新したプラグインやテーマも疑う。プラグインを全無効化してもStripeが表示されない場合は、テーマを標準テーマの「Twenty Twenty-Four」などに切り替えて同じ画面を確認する。テーマ側のフックが決済一覧を書き換えている例も過去にある。
このデモは、Stripe決済が消えたときに進めるトラブルシューティングの流れを示している。各ステップの詳細は本文の対応する見出しで確認できる。
キャッシュ削除と設定の再保存で復旧させる
競合の切り分けで原因が特定できた場合も、原因がまだ判明しない場合も、次に試すのはキャッシュの削除とStripe設定の再保存だ。この2つを実行するだけで、実害のない一時的な不整合が解消されてStripeが一覧に復活することが多い。
キャッシュ削除は、レンタルサーバーの管理画面で提供されているサーバーキャッシュ、WooCommerceのシステムが内部で使うオブジェクトキャッシュ、そして自分が閲覧しているブラウザのキャッシュの3つを対象にする。キャッシュ系プラグインを導入している場合は、そのプラグインの管理画面から全キャッシュを削除してから、決済設定画面をリロードする。
Stripe設定の再保存は、WooCommerceの「設定」→「決済」でStripeの項目が表示されていなくても実行できる場合がある。「決済」タブの一覧にStripeが出ていなくても、左メニューに「Stripe」の設定ページが残っていれば、そこを開いて「変更を保存」を押す。これにより設定値が再評価され、一覧に反映される。
設定を保存し直すと、StripeのAPI接続状態も再チェックされる。接続が切れていた場合は「接続」ボタンが表示されるため、そこからStripeアカウントに再接続できる。APIキーが無効になっている、あるいはテストモードと本番モードの切り替えが正しくない場合も、再接続で直るケースがある。
それでも直らない場合の追加チェック
ここまでの手順を実行してもStripeが一覧に表示されない場合は、環境そのものに問題がある可能性が高い。「WooCommerce」→「ステータス」→「システムステータス」を開き、WordPress本体、WooCommerce本体、PHPの各バージョンがStripeプラグインの推奨要件を満たしているか確認する。プラグイン更新後にPHPのバージョン要件が引き上げられ、サーバーのPHPが古いままだと読み込みに失敗することがある。
システムステータスレポートには、有効化している全プラグインの一覧と、WooCommerceが認識している各設定値がまとまっている。この中でStripeプラグインが「有効」になっているか、「非アクティブ」や「エラー」になっていないかを確認する。プラグイン一覧のページでStripeが有効化されていても、WooCommerce側で読み込めていない状態が可視化されることがある。
最終手段として、以前の安定したバージョンへロールバックする方法もある。プラグインの配布ページから過去バージョンのZIPファイルを取得して手動で上書きするか、「WP Rollback」のようなロールバック用プラグインを使って1つ前のバージョンへ戻す。ただしロールバックはセキュリティパッチを巻き戻すことになるため、あくまで復旧のための一時的な手段として扱い、原因を特定した上で最新版へ戻す計画を立てる。
よくある質問
Stripe決済が消えたのは自動更新の不具合か
自動更新自体がStripeを意図的に外すことはない。更新処理の中で発生した致命的エラーや、更新後に顕在化したプラグイン競合が原因であるケースがほとんどだ。ログを確認して切り分けることで特定できる。
セキュリティパッチによってStripeが意図的に隠されることはあるか
通常のセキュリティパッチがStripe決済を隠す仕様は存在しない。もしセキュリティ上の理由で決済方法が制限されるなら、公式リリースノートに明記される。リリースノートに記載がないのに消えた場合は、パッチの直接の影響ではなく別の要因を疑う。
Stripe Linkだけが表示されない場合は何を確認するか
Stripeゲートウェイ自体は表示されているが、Stripe Linkという特定の支払い方法だけが表示されない場合は、Stripe設定ページ内の「支払い方法」セクションでLinkが有効化されているか確認する。また、Stripeのアカウント側でLinkが利用可能な地域・通貨であるかも確認が必要だ。
システムステータスレポートのどこを見れば原因が分かるか
まず「環境」セクションでPHPとWooCommerceのバージョンが要件を満たしているか、次に「有効なプラグイン」でStripeが正常に読み込まれているか、そして「ログ」セクションでエラーが記録されていないかを順に確認する。レポートはサポートに共有する際にもそのまま使える。
プラグインを以前のバージョンに戻してもよいか
復旧を優先するなら一時的なロールバックは有効な手段だ。ただしセキュリティパッチを含む更新を巻き戻すため、原因を特定して修正した後は最新版へ戻すことが前提になる。ロールバック前に必ずサイト全体のバックアップを取る。
この記事のポイント
- Stripeが決済一覧から消えた主因はupdate時の致命的エラーとプラグイン競合
- セキュリティパッチ自体がStripeを隠すことはない
- 最初にWooCommerceの「ステータス」→「ログ」で fatal-errors を確認する
- 競合切り分け後はキャッシュ削除とStripe設定の再保存で復旧を試す
- 復旧しない場合はシステムステータスでPHP・WooCommerceの要件を確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Rank Math有効時にElementorパネルがフリーズする原因と復旧手順
Elementorのウィジェットパネルが突然操作不能になり、半透明のまま固まってしまう。この症状はRank Math SEOが同時に有効になっている環境で特に発生しやすく、複数のプラグインが読み込むスクリプトの衝突が原因だ。キャッシュのクリアと一部モジュールの無効化、またはバージョン管理で大半は改善する。
なぜRank Mathを有効にするとElementorパネルが固まるのか
この問題の根本には、WordPress管理画面で複数のプラグインがそれぞれJavaScriptやCSSを読み込む「競合」がある。Elementor Editorはページ上のあらゆる要素をドラッグアンドドロップで編集できる高度なインターフェースだが、そのぶん大量のAjax通信とDOM操作を行う。一方Rank Mathは、コンテンツAIやインスタントインデックス、スキーママークアップなど多機能なSEOツールを提供しており、画面内で動作する独自のスクリプトを多数読み込む。
両者が同時にロードされると、メモリ上で予期せぬエラーが発生したり、読み込み順序の不整合からElementorのウィジェットパネルがゾンビ化（グレーアウト状態）することがある。とくに最近のバージョンアップで機能が増えた直後や、サーバー側のPHPメモリ割り当てがギリギリの場合に表面化しやすい。
まずは本当に競合かどうかを確実に特定する
似たような症状は他のプラグインでも起こりうる。まずはRank Mathを含む全プラグインを停止し、Elementorだけの状態で正常に動作するかを確認する手順が切り分けの基本だ。
プラグイン停止モードを使った最小構成テスト
WordPressには「トラブルシューティングモード」を提供するプラグインがあるが、手動で行う方法も確実だ。管理画面の「プラグイン」→「インストール済みプラグイン」から、Rank Mathを除くすべてのプラグインを一時的に無効化する。その後、標準テーマ（Twenty Twenty-Fiveなど）に切り替えたうえで、Elementor Editorを開いてパネルが動くかテストする。
ここで問題が解消すれば、次にRank Mathだけを有効化し、再度パネルの挙動を確認する。Rank Mathを有効化した瞬間にフリーズが再現するなら、このプラグインがトリガーであると断定できる。
ブラウザコンソールでエラーの詳細を確認する
Chromeの場合、F12キーでデベロッパーツールを開き「Console」タブを見る。パネルが固まった直後には、赤字のJavaScriptエラーがいくつか記録されている。とくにUncaught TypeErrorやload-scripts.phpで始まるエントリがあれば、読み込み競合の有力な手がかりになる。エラー文言をメモしておくと、Rank Mathのサポートに問い合わせる際の情報になる。
Elementorパネルを復旧させる現実的な4ステップ
原因が特定できたら、以下に示す順に作業することで元の状態に戻せる。いきなりプラグインの再インストールをする前に、まずはキャッシュとモジュールの調整で解決できる場合が多い。
上記は概念的なフローであり、実際の作業では各ステップ後に必ずEditor画面をリロードして状態をチェックする。
STEP 1 Rank Mathを無効化して即座に確認する
緊急時に最も手早い対処はRank Mathの一時停止だ。「プラグイン」一覧からRank Mathを「無効化」し、Elementor Editorを開き直す。パネルが正常に戻ったら、問題がRank Math由来であることが確定する。この状態で作業は継続できるため、更新が急ぎの場合はSTEP 1だけでその場をしのげる。
STEP 2 キャッシュをあらゆる層で削除する
無効化だけでは根本解決にならない。Rank Mathを再び有効化する前に、キャッシュを丁寧に消す。WordPress側ではキャッシュ系プラグイン（W3 Total CacheやWP Super Cacheなど）を使っているなら管理画面から「全キャッシュ削除」を実行する。サーバー側でNginx FastCGI CacheやVarnishが動いている場合はホスティングの管理パネルからも同様に行う。最後にブラウザのキャッシュとCookieも削除し、シークレットウィンドウでEditorにアクセスすると、より確実に変化を確認できる。
STEP 3 Rank Mathのモジュールを調整する
Rank Mathには多数の拡張モジュールが用意されており、その組み合わせによってはElementorのスクリプトと干渉することがある。Rank Mathの管理メニュー「Rank Math」→「ダッシュボード」→「モジュール」へ進み、以下の機能をひとまずオフにしてみる。
- コンテンツAI
- インスタントインデックス
- SEO分析（管理画面で動作するウィジェット）
これらの機能は編集画面に独自のメタボックスや通知を追加するため、競合の原因になりやすい。変更を保存し、再度Elementor Editorでパネルの挙動をチェックする。症状が消えたら、ひとつずつモジュールをオンにして犯人を特定することもできる。
STEP 4 両プラグインを最新状態に保つ
WordPress本体、Elementor、Rank Mathのすべてが最新版であれば、開発者同士が互換性を確認した上でリリースしている可能性が高い。バージョンに偏りがあると、片方だけが想定する関数が欠落しているケースがある。アップデート後は必ずSTEP 2のキャッシュクリアを再度行う。
再発を防ぐために日頃からできること
大規模な編集を始める前に、Rank Mathのモジュール状態を簡易チェックリストにしておくと、いざという時のダウンタイムを大幅に減らせる。また、PHPのメモリリミットが最低でも256MB以上確保されているかを確認するのも効果的だ。
万一どうしても競合が解消しない場合は、Rank MathをElementor編集時だけ一時的に無効化する運用でも実務上は問題になりにくい。ただし、無効化すると編集中のSEOスコアが変動する可能性があるため、プレビュー公開前に再度有効化してSEO設定を確認する習慣をつけておく。
よくある質問
他のSEOプラグインでも同じことが起きますか
Yoast SEOやAll in One SEO Packでも類似の競合は報告されているが、発生条件や修正パッチはプラグインごとに異なる。まずは同じ手順で特定し、問題が発生したプラグインに合わせた対処を行うとよい。
Rank Mathを無効化するとSEO順位に影響しますか
短時間（数分〜数十分）の無効化であれば、検索順位への直接的な影響はまずない。ただし、その間にクローラーがサイトを訪れると、メタタグが一時的に変化する可能性があるため、公開状態の確認は忘れずに行う。
キャッシュをすべて消さずに直す方法はありますか
管理画面の問題はサーバーレベルのページキャッシュと直接関係しないこともあるが、ブラウザ上に競合する古いスクリプトが残っていると再発しやすい。最低限ブラウザキャッシュだけは削除し、あわせて管理画面用のバックグラウンド処理キャッシュがないか確認する方が確実だ。
プレビュー画面だけ固まる場合はどうすればいいですか
プレビュー表示は管理画面とフロントエンドの両方のスクリプトが混在しやすい。まずはパーマリンク設定を再保存し、.htaccessをリフレッシュする。それでも治らない場合は、テーマのfunctions.phpで読み込みを遅延させるカスタムコードを追加する選択肢もある。
競合が直ったのにしばらくすると再発します
キャッシュ系プラグインやCDNが古いファイルを配信し続けている可能性が高い。Originサーバー上のキャッシュも含めて一掃し、変更後にCDNのパージが自動でかかる設定になっているか見直すことを推奨する。
この記事のポイント
- Rank Mathの有効化直後にElementorパネルが固まるのはスクリプト競合が原因
- 最小構成テストで競合相手を特定するのが最短の道
- 即効復旧にはRank Mathの一時無効化と全キャッシュ削除が有効
- 不要なSEOモジュールをオフにすることで競合を回避できる
- バージョンの統一と定期的なキャッシュクリアで再発を防げる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ManageWP でサイトがオフラインエラーになる All-In-One Intranet 競合の直し方
ManageWP のダッシュボードでサイトが「オフライン」表示になり Worker プラグインの再接続に失敗するエラーが出る場合、All-In-One Intranet プラグインの強制ログイン機能が外部通信をブロックしている可能性が高い。プラグインを最新版にアップデートするか、提供されているフィルターフックで ManageWP のアクセスだけを許可すれば直ちに解決する。
なぜ ManageWP が All-In-One Intranet 導入後に接続不能になるのか
All-In-One Intranet は WordPress サイト全体を非公開化するプライバシー保護プラグインだ。設定を有効にすると、訪問者がログインしていない限り、あらゆるページへのアクセスを遮断する。この制御は WordPress のリクエスト処理そのものにかかり、人間のブラウザアクセスだけでなく、バックグラウンドで動作する管理ツールの通信も一律に弾いてしまう。
ManageWP はサイトで ManageWP Worker プラグインを経由して、ダッシュボードからの一括更新や監視を実現している。この通信は非ログイン状態の外部リクエストとして届くため、All-In-One Intranet の「未ログインユーザーをブロック」のルールに引っかかり、結果として「Worker プラグインがアクティブでない」という誤ったエラーを ManageWP 側に返してしまう。
このデモは、All-In-One Intranet が ManageWP の通信を遮断する流れと、除外設定後の正常な通信を示している。
アップデートで競合を根本解決する
プラグイン開発元がこの競合を把握しており、バージョン 1.10.0 で ManageWP をはじめとする外部管理ツール（MainWP、WP Umbrella など）との通信が復旧する修正が行われた。古いバージョンを使い続けているなら、まずは All-In-One Intranet を最新にアップデートするだけで問題が解消する。
アップデート前のキャッシュとバックアップ
プラグインの更新前に、サイト全体のバックアップを取得しておく。管理画面から「ダッシュボード」→「更新」を開き、「プラグイン」セクションで All-In-One Intranet の新しいバージョンの有無を確認する。
更新が完了したら、サーバーキャッシュや CDN キャッシュをすべてクリアする。ManageWP 側のキャッシュもリセットするために、対象サイトの「サイトを再接続」を一度だけ実行し、オフライン表示が消えるか確認する。
フィルターフックで ManageWP を手動除外する
プラグインを何らかの理由で最新版にできない場合や、最新版でも何かしらの要因で競合が続くなら、All-In-One Intranet が用意している aioi_allow_public_access フィルターフックで ManageWP Worker のアクセスだけ許可する方法がある。このフックを使うと、サイトの他のプライバシー設定を維持したまま、特定のエンドポイントやリクエストを認証不要で通過させられる。
子テーマの functions.php にコードを追加する
フィルターフックは、利用している子テーマの functions.php にコードを追記して適用する。FTP やホスティングのファイルマネージャーで直接編集するか、管理画面の「外観」→「テーマファイルエディター」から functions.php を開く。
add_filter( 'aioi_allow_public_access', function( $allow ) {
// ManageWP Worker の要求を常に許可する
if ( defined( 'MWP_ACTION' ) || isset( $_GET['mwp_action'] ) ) {
return true;
}
return $allow;
});上記のコードは、ManageWP Worker プラグインがリクエストの際に内部でセットする定数やクエリパラメータを目印にしている。もし Worker プラグインが異なるパターンのリクエストを送っていたとしても、フック内の条件を適宜拡張すればよい。
コードを追加したらファイルを保存し、ManageWP ダッシュボードで対象サイトを再接続する。このタイミングでオフラインエラーが出なくなり、正常に一覧に戻ってくるはずだ。
この STEP 図は、フィルターフックでアクセスを許可し、ManageWP の接続を復旧するまでの一連の流れを視覚化したものだ。
回避策が効かない場合の追加切り分け
ごく稀に、All-In-One Intranet のバージョンアップやフィルター適用後もエラーが消えないケースがある。その場合は、他のセキュリティプラグインが重複して通信を遮断していないか確認する。
プラグインの競合を最小構成で検証する
一時的に全プラグインを無効化し、All-In-One Intranet と ManageWP Worker だけを有効化する。この状態で ManageWP が接続できるなら、ほかのプラグインに問題を起こしているものがあると判断できる。1つずつ有効化していき、再発タイミングを特定する。
ファイアウォールとサーバー設定の二重ブロックに注意する
Wordfence などの WAF（ウェブアプリケーションファイアウォール）が ManageWP の IP アドレスをブロックしている可能性もある。プラグインの設定や cPanel の IP ブロック機能で、ManageWP の公式 IP アドレス帯域が許可リストに入っているか確認する。また .htaccess にリダイレクトや BASIC 認証をかけている場合、一時的に解除して影響を切り分ける。
よくある質問
All-In-One Intranet を無効化したくないが、セキュリティは維持できるか
フィルターフックによる除外は、ManageWP Worker が利用する特定のリクエストに絞って施せる。サイトの他の全ページは引き続きログイン必須の状態を保つため、セキュリティレベルを落とすことなく管理だけを外部から行える。コードの条件式を Worker 限定にすることで、意図しない一般リクエストの流入は防がれる。
ManageWP 以外の管理ツールでも同じ問題は起きるのか
MainWP、WP Umbrella など、サイトに Worker 的なプラグインを入れて外部から操作する仕組みの管理ツール全般で発生する可能性がある。All-In-One Intranet のバージョン 1.10.0 ではこれらツールとの互換性も修正されているため、最新版で問題が起きることはほぼない。
アップデート後に ManageWP がまだオフライン表示のままだがどうすればいいか
まず ManageWP のダッシュボードで該当サイトを明示的に「再接続」させる。続いてサーバー側のキャッシュ（プラグインベースのキャッシュやホスティングのサーバキャッシュ）を完全にクリアする。それでも反映されない場合、Worker プラグイン自身をいったん削除し、ManageWP ダッシュボードから新規にインストールし直すと設定がリフレッシュされる。
functions.php を直接編集するのに抵抗がある。安全な方法はあるか
必ず親テーマではなく子テーマの functions.php を編集する。編集前にファイルをダウンロードしてバックアップし、テーマファイルエディターを使う場合は保存前にコードの誤字を確認する。それでも不安なら、Code Snippets プラグインを導入し、管理画面からスニペットとして同じコードを追加する方法もある。
数か月前から Worker の再接続に失敗していたが、データは失われるか
ManageWP 側の管理データ（サイトの追加設定や監視ログなど）は失われない。再接続が成功すれば、プラグインやテーマの更新状況はそのまま引き継がれる。ただし、オフライン期間中にあったサイト側の変更は、再接続後に初めて ManageWP 側で認識される。
この記事のポイント
- ManageWP のオフラインエラーは All-In-One Intranet のプライバシー保護が原因
- プラグインの 1.10.0 へのアップデートで競合は根本的に解決する
- すぐ対応したい場合は
aioi_allow_public_accessフィルターで手動除外 - コード追加は子テーマの functions.php に限定しバックアップを取る
- キャッシュクリアと再接続の実行を必ず忘れずに行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Yoast SEOとLearnDashの競合でコースが表示されないときの解決策
LearnDash 5.1.8 と Yoast SEO を同じサイトで動かすと、コースやレッスンの本文領域が空白になり、マークアップも生成されなくなる問題は、Yoast SEO の解析エンジンが LearnDash のコンテンツ出力に干渉しているのが原因だ。Yoast SEO 側の設定で特定の投稿タイプの解析を無効化するか、LearnDash を最新バージョンに更新すれば回避できる。
なぜ Yoast SEO と LearnDash で本文が消えるのか
この不具合は、両プラグインが吐き出す HTML の構造やフックの衝突に起因する。Yoast SEO はコンテンツ解析のために内部で出力バッファを操作し、記事本文の前後に独自の HTML コメントや隠し div を挿入する。一方 LearnDash はコースやレッスンを表示する際に、独自のテンプレート階層とコンテンツフィルターを使って本文を組み立てる。この組み合わせで、Yoast SEO の解析プロセスが LearnDash のメインコンテンツ領域のレンダリングを途中で止めてしまい、結果的に空の div だけが出力される状態になる。
多くのケースでは、PHP のエラーログにもブラウザのコンソールにもエラーは出力されない。この「痕跡のない空白」がトラブルシューティングを難しくしている。問題が表面化するのは、LearnDash が 5.1.8 にアップデートされ、かつ Yoast SEO がバージョン 21 系や 22 系など新しいエンジンを搭載した組み合わせだ。同様の競合は LearnDash のサポートフォーラムでも複数報告されており、開発チームも認識している。
上図は典型的な症状の遷移を表している。次項から実際の修正手順を説明する。
設定変更で競合を解消する 3 つの手順
手順の詳細は以下のとおりだ。この操作に FTP やコード編集は不要で、管理画面の中だけで完結する。
Yoast SEO の検索アピアランスを開く
WordPress 管理画面の左メニューから「Yoast SEO」→「検索アピアランス」へ進む。ここでサイト全体の表示設定と、カスタム投稿タイプごとの解析可否を管理できる。
コンテンツタイプタブで LearnDash 項目を無効化する
「検索アピアランス」画面の上部には「一般」「コンテンツタイプ」「メディア」「タクソノミー」「アーカイブ」などのタブが並んでいる。「コンテンツタイプ」をクリックすると、登録されているすべての投稿タイプが一覧表示される。ここで LearnDash に該当する Courses（sfwd-courses）、Lessons（sfwd-lessons）、Topics（sfwd-topic）、Quizzes（sfwd-quiz） などの項目を探す。各項目の右側にある「Yoast SEO の分析を有効にする」スイッチをすべてオフにする。また、すぐ下の「読みやすさの分析を有効にする」も同様にオフにする。
設定を保存してキャッシュをクリアする
画面下部の「変更を保存」ボタンをクリックする。保存後、サイトキャッシュやサーバーキャッシュを利用している場合は、念のため全キャッシュを削除する。管理画面から再度 LearnDash のコースページにアクセスし、本文が正しく表示されるようになっていれば完了だ。
LearnDash のバージョンアップで根本解決を図る
上記の設定変更は対症療法であり、Yoast SEO の解析機能を一部犠牲にする方法だ。根本的には、LearnDash 側で Yoast SEO との互換性を高めたバージョンがリリースされるのを待ち、アップデートするのが望ましい。実際、LearnDash 5.1.8 のリリース後に同様の競合が複数報告されており、開発チームが修正パッチを準備している可能性が高い。
LearnDash の最新バージョンを確認する
WordPress 管理画面の「ダッシュボード」→「更新」、あるいは「プラグイン」→「インストール済みプラグイン」で LearnDash に更新通知が出ていないかチェックする。5.1.9 以降のバージョンが利用可能であれば、適用してから Yoast SEO の解析を再度有効に戻してみるとよい。なお、更新前に必ずサイト全体のバックアップを取ることは大前提だ。
それでも改善しない場合の追加チェック
まれに、Yoast SEO の「カスタム投稿タイプごとの noindex 設定」が一部影響しているケースもある。先ほどの「検索アピアランス」→「コンテンツタイプ」で、LearnDash の投稿タイプを「検索エンジンに表示する（index）」に設定し直すと、内部のフラグがリセットされて競合が解消したという報告もある。設定をいったんデフォルトに戻してから再度解析をオフにする、という手順を試してみる価値はある。
よくある質問
Yoast SEO を無効化せずに済ませたいが他に方法はあるか
Yoast SEO 全体を無効化するより、上記のとおり LearnDash の投稿タイプだけ解析をオフにする方法が最も手軽で影響が小さい。コースやレッスンの SEO タイトルやメタディスクリプションは Yoast SEO の「検索アピアランス」とは別の編集画面から入力できるため、最低限の SEO 対策は維持できる。
LearnDash 以外の LMS プラグインでも同じことが起きるのか
LifterLMS や LearnPress など他の LMS でも、Yoast SEO の解析がカスタム投稿タイプのテンプレートと干渉する事例は報告されている。いずれも Yoast SEO のコンテンツタイプ設定から解析をオフにすることで対処可能だ。
コンソールやログに何も出ないのはなぜか
PHP の致命的エラーが発生しているわけではなく、Yoast SEO が出力バッファ内でコンテンツの一部を誤ってカットしているだけだからだ。そのため WordPress のエラーログやブラウザの開発者ツールにも痕跡が残らない。
設定を変えても直らない場合はどうすればよいか
テーマや他のプラグインとの三重競合も考えられる。一度すべてのプラグインを停止し、標準テーマ（Twenty Twenty-Five など）に切り替えて LearnDash と Yoast SEO だけを有効にして再現するか確認する。原因を特定したら、該当プラグインのサポートに問い合わせるか、LearnDash のバージョンダウンを検討する。
LearnDash をダウングレードするのは安全か
緊急避難として 5.1.7 以前に戻す方法もあるが、セキュリティや機能面で後退するリスクを伴う。どうしても表示をすぐに復旧させたい場合に限り、バックアップを取ったうえで実施する。長期運用には上記の設定変更と最新版へのアップデート待ちを推奨する。
この記事のポイント
- LearnDash 5.1.8 と Yoast SEO の組み合わせでコース本文が空白になる不具合は、Yoast SEO の解析エンジンが原因
- 管理画面の「Yoast SEO」→「検索アピアランス」→「コンテンツタイプ」で LearnDash の投稿タイプの解析をオフにすれば即座に解消
- PHP ログやコンソールにエラーが出ないため、見落としやすい
- 根本対応は LearnDash の最新バージョンへのアップデートだが、緊急時は上記の設定変更でしのぐ
- 他の LMS プラグインでも同様の競合が起きる可能性があるので、同じ手順で対処可能
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている