GS Team Membersアップデート後にDiviサイトが壊れた場合の復旧と修正手順
GS Team Membersプラグインのバージョン2.7.17へのアップデート後にDiviサイトが壊れ「このサイトで重大なエラーが発生しました」と表示された場合、開発者が公開した修正版2.7.18へアップデートすれば解決する。リカバリーモードで管理画面に入りプラグインを一時停止したあと、最新版へ更新するだけでサイトは復旧する。
どんなエラーが発生しているのか
GS Team Members 2.7.17では、Diviテーマ向けの統合モジュールに含まれるファイル「TeamMembersModule.php」の25行目で、必要なインターフェースが見つからないという致命的なエラー（E_ERROR）が発生する。PHPが「インターフェースが存在しない」と判断し処理を停止するため、サイト全体が表示不能になる。
エラーメッセージの要点は次の通りだ。「Interface "ET\Builder\Framework\DependencyManagement\Interfaces\DependencyInterface" not found」という内容で、Diviのビルダーフレームワークが提供するDependencyInterfaceというインターフェースを読み込もうとしたが見つからなかったことを示している。
このエラーは管理画面にもフロントエンドにも影響し、WordPress本体が自動的にリカバリーモードへ移行させる。スタックトレースにはGoogle Site Kitも登場するが、これはエラーの連鎖で巻き込まれただけで、根本原因ではない。
なぜアップデートでサイトが壊れたのか
原因はGS Team Members側のコード不備だ。バージョン2.7.17でDivi向けの統合コードを更新した際、Divi本体のバージョンによっては存在しないインターフェースを参照してしまった。PHPでは存在しないクラスやインターフェースを使おうとすると即座に致命的エラーを投げるため、その瞬間にサイト全体の処理が停止する。
スタックトレースを見ると、DependencyInterfaceを読み込もうとした箇所からエラーが始まり、REST APIの初期化処理へ飛び火している。管理画面のダッシュボードでは複数のプラグインがREST API経由でデータを取得するため、Google Site Kitや他のプラグインの処理が次々にエラーに巻き込まれているが、これらは二次的なものだ。
根本的な問題はGS Team Members 2.7.17のコードにあるため、Diviを使っているユーザーだけがこのエラーに遭遇する。他のテーマやページビルダーを使っている場合は問題が起きない。
リカバリーモードで管理画面にアクセスする手順
サイトが壊れて管理画面にもアクセスできなくなった場合、WordPressは自動的にリカバリーモードへのリンクを記載したメールを管理者アドレスに送信する。このメールを使って管理画面へ入り、問題のプラグインを停止するのが最初の復旧手順だ。
リカバリーモードのリンクは24時間の有効期限が設定されている。メールが届かない場合は迷惑メールフォルダを確認し、それでも見つからなければFTPやサーバー管理ツールでプラグインフォルダの名前を変更して強制的に無効化する手段も取れる。
GS Team Membersを最新版へアップデートする
GS Team Membersの開発者はバージョン2.7.18でこの問題を修正している。アップデート内容は「Uncaught Error: Dependency Interface」への対応で、Diviテーマとの統合コードを修正したものだ。プラグインを停止した状態で管理画面の「プラグイン」ページを開き、「GS Team Members」が更新可能になっていればそのままアップデートを実行する。
更新が完了したらプラグインを再度有効化し、サイトのフロントエンドと管理画面の両方が正常に表示されることを確認する。この時点でプラグインのキャッシュが残っている可能性があるため、ブラウザキャッシュの削除も忘れずに行う。
もし更新通知が表示されない場合は、プラグインを一度削除してから新規インストールし直す方法もある。この場合、プラグインの設定や登録済みのチームメンバーデータが保持されるかどうかを事前に確認しておく必要がある。
FTPから手動でプラグインを停止する方法
リカバリーメールが届かない、あるいはメールアドレスが古くなっているなどで管理画面に入れないケースでは、FTPやサーバーのファイルマネージャーを使ってプラグインを一時停止する。手順は単純で、対象プラグインのフォルダ名を変更するだけだ。
サーバーに接続し「wp-content/plugins/」ディレクトリへ移動する。その中にある「gs-team-members」フォルダを「gs-team-members-backup」などにリネームする。WordPressはフォルダ名でプラグインを認識するため、名前が変わると自動的にプラグインが無効化される。
これでサイトが正常に表示されるようになったら管理画面へログインし、「プラグイン」ページでGS Team Membersが解除扱いになっていることを確認する。そのまま管理画面から最新版をインストールし、フォルダ名を変更した古いバージョンは削除しておく。
再発を防ぐためのアップデート前確認事項
プラグインのアップデートでサイトが壊れるリスクを減らすには、いくつかの事前対策が有効だ。第一に、本番サイトで直接アップデートを実行するのではなく、ステージング環境で事前にテストする方法が最も安全だ。国内のレンタルサーバーの多くは管理画面からワンクリックでステージング環境を作成できる機能を提供している。
第二に、WordPressにはプラグインの自動更新機能があるが、ビジネス用途で使っているサイトではこれをオフにし、すべてのアップデートを手動で確認する運用が推奨される。プラグイン一覧で更新通知を受け取ったら、そのプラグインの変更履歴（changelog）を読み、自分の環境に影響がありそうかを判断してから実行する。
第三に、バックアッププラグインを必ず導入し、アップデート前の状態をまるごと保存する習慣をつける。もし何か起きても数分で元に戻せる安心感が、トラブル時の心理的負荷を大きく下げる。
よくある質問
GS Team Members以外のプラグインでも同じようなエラーは起きるのか
起きる可能性は十分ある。特にDiviやElementorのようなページビルダー向けのアドオンを提供するプラグインは、テーマ側のバージョンと整合性が取れていないアップデートをリリースしてしまうことがある。致命的エラーに遭遇したら、まず該当プラグインを停止し、最新バージョンの有無を確認するのが基本だ。
リカバリーモードのメールが届かない場合はどうする
サーバーのメール送信設定が正しくない、管理者メールアドレスが古い、または迷惑メールに振り分けられている可能性がある。FTPで問題のプラグインを停止してから、WordPressの「設定」→「一般」で管理者メールアドレスを最新のものに更新し、SMTPプラグインを導入してメール送信を安定させるのが長期的な解決策になる。
Diviを使っていなければこのエラーは起きないのか
その通りだ。今回のエラーはGS Team MembersのDivi統合用コードに起因するため、他のテーマを使っているサイトでは発生しない。ただし、プラグインのアップデートで別のテーマとの組み合わせに問題が生じるケースは常にあり得るため、油断は禁物だ。
プラグインの更新前に毎回ステージングテストは必要なのか
小規模なサイトや個人ブログであれば必須ではないが、ECサイトや企業サイトなどビジネス用途では強く推奨される。数分のテストで数時間のダウンタイムを防げるなら、手間をかける価値は十分にある。最近の国内レンタルサーバーはステージング機能を標準搭載しているところも多い。
Google Site Kitは関係しているのか
関係していない。エラーのスタックトレースにGoogle Site Kitが登場するのは、REST APIの初期化時にたまたま処理が巻き込まれたためだ。GS Team Members単体の問題であり、Google Site Kit側での対応は不要だ。
この記事のポイント
- GS Team Members 2.7.17はDivi環境で致命的エラーを引き起こす
- リカバリーモードで管理画面に入りプラグインを停止すればサイトは復旧する
- 開発者が公開した修正版2.7.18へアップデートすれば根本解決する
- FTPでの手動停止も有効な代替手段だ
- 重要なサイトではステージング環境での事前テストが再発防止に効く
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Diviビルダーでカスタムパーマリンクのページが404になる原因と直し方
Diviビルダーでカスタムパーマリンクを設定した固定ページを編集しようとしたとき、編集画面が404エラーになる現象は、パーマリンク管理プラグインがビルダー専用のクエリパラメータを不正に処理しているために起こる。多くの場合、プラグインの詳細設定で特定のクエリ文字列を除外するだけで解決する。
なぜDiviビルダーがカスタムパーマリンクのページで404エラーを起こすのか
Diviのビジュアルビルダー（フロントエンド編集）は、管理画面から対象ページのURLに「?et_fb=1」といったクエリパラメータを付与し、そのページをiframe内で読み込んで動作する。このとき、パーマリンク管理プラグイン（Permalink Manager Lite など）が設定したカスタムパーマリンクのリダイレクトルールが厳しすぎると、「?et_fb」がついたURLを本来とは別の場所に転送したり、存在しないページとみなして404ステータスを返してしまう。ページ自体は正常に表示されていても、ビルダーという編集専用のアクセスだけがブロックされるかたちになる。
具体的には、パーマリンク管理プラグインの「リダイレクト設定」や「正規化」機能が、付加されたクエリ文字列を除去してしまったり、ビルダー用のパラメータを含むURLをリダイレクト対象から外す設定になっていないことが原因だ。また、一部のキャッシュ設定が影響して、ビルダーがキャッシュ済みの不完全なページを読み込んで404を返すケースもある。
Permalink Manager Lite の設定を調整して404を解消する
カスタムパーマリンクで運用している環境でDiviビルダーが使えなくなったら、まずパーマリンク管理プラグインの詳細設定を見直す。ここでは日本語環境でも多く使われている「Permalink Manager Lite」を例に手順を示すが、他のパーマリンク系プラグインでも同様の考え方で対処できる。
上記の「除外するクエリパラメータ」には「et_fb」とだけ入力すればよい。クエリキー名のみをカンマ区切りで列挙する仕様のため、値や「?」を含める必要はない。保存後にDiviビルダーでカスタムパーマリンクのページを開き直し、編集画面が正しく表示されるか確認する。
リダイレクト無効化で管理者の編集を保護する
もう一つの有効な方法は、特定のユーザーに対してリダイレクト機能を一時的に無効化する設定だ。「詳細設定」画面の「リダイレクトを無効化するユーザー」で「管理者」にチェックを入れて保存する。こうすると管理画面からビルダーを開く管理者のリクエストにはリダイレクトルールが適用されず、クエリパラメータがそのまま残るため404が発生しなくなる。ただし、この設定は公開側のパーマリンク動作には影響しない。
デバッグモードで原因を可視化する
設定を変更しても改善しない場合は、「ツール」→「Permalink Manager」→「設定」→「詳細設定」にある「デバッグモード」を有効にしてみる。デバッグモードをオンにすると、ビルダーで404になった際にプラグインがどのURLを解決しようとして失敗したか、詳細なログが記録される。これを見ることで「et_fb」以外に必要な除外パラメータが見つかったり、リダイレクトルールの競合を特定できる。
キャッシュプラグインの影響を切り分ける
パーマリンク管理プラグインの設定を見直しても直らないときは、サーバーキャッシュやWordPressのキャッシュプラグインの影響を疑う。ビルダー読み込み時の動的URLがキャッシュから誤ったレスポンスを返す場合があるため、以下の手順で一時的にキャッシュを無効化し、症状が消えるか確認する。
- 使用しているキャッシュプラグイン（WP Super CacheやW3 Total Cacheなど）を一時停止する
- サーバー側でNginxのfastcgi_cacheやApacheのmod_cacheを使っているなら、管理画面経由でキャッシュをクリアするか、一時的に無効にする
- ブラウザのキャッシュもクリアしてからビルダーを再読込する
キャッシュを切った状態で編集が成功したなら、キャッシュプラグインの「除外するURLパターン」に「?et_fb」を含む設定を追加する。たとえば、et_fb というクエリ文字列がついたリクエストはキャッシュしないように設定すれば、運用を続けながら編集機能を維持できる。
どうしても直らないときの代替手段
上記すべてを試してもビルダーが404を返す場合、根本的にプラグインの仕組みがDiviビルダーと相性が悪い可能性がある。以下の対策を順に検討する。
パーマリンクプラグインを別のものに切り替える
カスタムパーマリンク機能自体は別のプラグインでも実現できる。「Custom Permalinks」や「WP Permalink」など、Diviとの競合報告が少ないプラグインを試すことで、リダイレクトの挙動を根本から変えられる。ただし、移行時には既存のURL構造を維持できるか事前にテスト環境で確認する必要がある。
ページ編集時だけパーマリンクを一時的にデフォルトに戻す
最終手段として、編集したい固定ページのパーマリンク設定を一時的に「デフォルト（?p=123）」に変更してビルダーで作業し、公開直前にカスタムパーマリンクに戻す方法もある。ただし、編集のたびに手作業が発生するため、恒常的な運用には向かない。
よくある質問
エラーは「このサイトで重大なエラーが発生しました」ではなく「404 Not Found」と表示されるのはなぜか
Diviビルダーはページをiframeで読み込む際に、サーバーに実際のHTTPリクエストを送る。カスタムパーマリンクのルールがリクエストを処理できないと、WordPressのルーティングが失敗し「ページが見つかりません」という404ステータスが返る。これはPHPの致命的エラーではなく、あくまでもURL解決の失敗が原因だ。
特定の固定ページだけ編集できず、他のカスタムパーマリンクページは問題ないのはなぜか
スラッグの重複やリダイレクトルールの複雑さによって、一部のURLだけ誤って別のルールにマッチしてしまうことがある。全ページに同じカスタム構造を割り当てていても、個別に手動で追加したリダイレクト設定が干渉している場合もあるため、プラグインの「重複チェック」や「リダイレクトリスト」を確認する必要がある。
除外するクエリパラメータに「et_fb」を追加しても直らない場合はどうすればよいか
その場合は、ビルダーが使用する可能性のあるすべてのクエリパラメータを確認する。たとえば「et_fb」「et_pb_preview」「et_fb_iframe」「preview」「preview_id」などが考えられる。開発者ツールのネットワークタブでビルダー起動時に送信されるリクエストを調べ、404になっているURLに含まれるパラメータをすべて除外リストに追加する。
キャッシュプラグインを停止しても404が消えない
サーバーレベルのキャッシュ（VarnishやNginx FastCGI）が影響している可能性がある。レンタルサーバーの管理パネルからキャッシュを手動でクリアするか、サーバー会社のサポートに一時的なキャッシュ停止を依頼して切り分ける。WordPressのキャッシュプラグインだけでは制御できない層があるためだ。
この記事のポイント
- パーマリンク管理プラグインの除外設定に「et_fb」を追加すれば大半のケースで解決する
- 管理者向けのリダイレクト無効化も有効な回避策になる
- キャッシュプラグインやサーバーキャッシュが404を悪化させることがあるため、一時停止して切り分ける
- デバッグモードで詳細なログを確認すれば、除外すべき追加パラメータを特定できる
- 根本的に相性が悪い場合は、パーマリンクプラグインの変更も選択肢に入る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Diviポップアップを時間指定で自動表示するトリガー設定方法
Divi のポップアップを「ページを開いてから数秒後」や「一定のスクロール後」に自動表示するには、ポップアップ編集画面のトリガー設定を使う。Divi ビルダーで作成したポップアップであれば、標準機能だけで時間遅延やスクロール位置を細かく制御できる。プラグイン版のポップアップ機能を使っている場合でも、設定タブの名称こそ異なるが考え方は同じだ。
Divi ポップアップのトリガー設定を開く手順
まずは、すでに作成済みのポップアップの編集画面にアクセスする。WordPress 管理画面の「Divi」メニューから「Theme Builder」を開き、登録されているポップアップの一覧を表示する。該当のポップアップをクリックすれば、Divi ビルダーの編集画面が立ち上がる。
ポップアップの編集画面では、画面下部にある「設定」パネルの中に「トリガー」タブが存在する。ここが表示タイミングを決める中核部分だ。もし「トリガー」タブが見当たらない場合は、ポップアップを新規作成したときに「ポップアップの種類」を誤って選択した可能性がある。再度ポップアップの種類を確認し、「自動ポップアップ」など時間経過に対応した種類を選び直す必要がある。
ページ表示後の時間でポップアップを表示する手順
トリガー設定内で「時間遅延」を選択し、秒数を指定するのが最もシンプルな方法だ。ここでは具体的な操作の流れと、設定値の意味を明確にする。
時間遅延のトリガーを正確に設定するコツ
時間遅延のプルダウンを選ぶと、すぐ下に「遅延時間（秒）」という入力欄が現れる。ここに数字（半角）を入れるだけで、ページが完全に読み込まれてからその秒数が経過した時点でポップアップが出現する。
たとえば「5」と入力すれば、ユーザーがページにアクセスして5秒後に表示される。なお、この秒数は外部スクリプトや画像の読み込み完了を基準にするため、重いページでは体感より若干遅れることがある。3〜8秒程度の短めの数字にしておくと、ユーザーがページを離れる前に目に留まりやすい。
複数のトリガーを同時に有効化できることも覚えておきたい。時間遅延とスクロールを併用すれば「5秒経過、かつ 30% スクロールしたら表示」といったより複雑な条件も作れる。
スクロール量でポップアップを表示する手順
スクロールをトリガーにする場合は、同じ「トリガー」タブ内で「スクロール」を選択する。ページの何パーセントがスクロールされた時点で表示するかを、スライダーまたは数値入力で指定できる。
スクロールトリガーのパーセント設定の考え方
スクロール量の入力値は「ページ全体の高さに対する比率」を示す。たとえば 25% と設定すれば、ユーザーがページの4分の1までスクロールしたタイミングでポップアップが出現する。記事ページなど長いコンテンツでは 40〜60% に設定すると、読み進めたユーザーにだけ訴求でき、直帰率の高いユーザーを無駄に邪魔しない。
注意点として、ページの高さが極端に短い場合（例えばランディングページなど）、設定したパーセントに到達する前に画面外に出てしまい、ポップアップが表示されないことがある。そうしたページではパーセントを低めに調整するか、時間遅延との併用を検討するとよい。
設定したポップアップが表示されないときのチェックポイント
トリガーを正しく設定しているのに実際のページでポップアップが出てこない場合は、いくつかの典型的な原因を順に潰していく。
- キャッシュの影響を受けている。Divi の設定を変更したら、サーバー側キャッシュやブラウザキャッシュをクリアする。
- 表示条件（ポップアップが表示されるページのルール）が合っていない。特定のページのみに制限していないか確認する。
- ブラウザのポップアップブロッカーが反応している。Divi のポップアップは HTML/CSS ベースなので通常は影響を受けないが、拡張機能の干渉を疑う。
- JavaScript の競合が起きている。他のプラグインやテーマのスクリプトと衝突し、トリガーが発火していない可能性がある。全プラグインを一時停止して切り分ける。
特にキャッシュ系プラグインを使用している場合は、Divi の JavaScript ファイルが古いまま配信されているケースが多い。キャッシュを削除したうえでシークレットウィンドウからアクセスすれば、新鮮な状態で動作確認ができる。
よくある質問
時間遅延とスクロールの両方を同時に使えるか
Divi のポップアップ設定では、トリガータイプを複数組み合わせることができる。時間遅延とスクロールの両方をアクティブにすると「指定秒数が経過した、かつ指定のパーセントまでスクロールした」時にのみポップアップが表示される AND 条件になる。どちらか一方だけで十分なケースが多いが、コンバージョンを高めたいランディングページでは組み合わせも有効だ。
モバイル端末ではポップアップを非表示にできるか
「トリガー」タブの下にある「表示設定」セクションで、デバイスごとの表示オンオフを切り替えられる。モバイルのチェックを外せば、スマートフォンやタブレットでは一切ポップアップが表示されなくなる。画面サイズが小さい端末でポップアップが邪魔にならないようにするために、多くのサイトでこの設定が使われている。
ポップアップが何度も出るのを防ぐには
一度表示したポップアップを同じユーザーに再度表示しないようにするには、「表示設定」の「頻度」オプションを使う。「セッションごとに1回」や「日ごとに1回」などを選べば、Cookie によって表示回数を制限できる。時間遅延で表示するポップアップであっても、この設定を併用すればユーザー体験を損ねにくい。
ポップアップにカウントダウンタイマーを表示したい
Divi には標準でカウントダウンタイマーモジュールが用意されている。ポップアップのレイアウト内にそのモジュールを配置すれば、表示と同時にタイマーが動き始める。時間遅延のトリガーと組み合わせると「あと○秒で閉じます」といった演出も可能だ。なお、タイマーはサーバー時刻ではなくブラウザ側で動作するため、正確な時刻に基づくキャンペーンには向かない。
この記事のポイント
- Divi ポップアップの表示タイミングは「トリガー」タブで設定する
- 時間遅延は秒数、スクロールはパーセントで指定できる
- キャッシュや表示条件が原因で動作しないことが多いのでまず確認する
- モバイル非表示や表示頻度制限を併用するとユーザーに優しい
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている