大規模WordPressサイトでプラグインが途中で止まるエラーの解決法
大規模なWordPressサイトでプラグインの一括処理が「0/」と表示されたまま進まず「error-generation stopped」で停止する現象は、PHPの実行時間やメモリ制限が主な原因だ。設定を調整しバッチサイズを小さくすれば、処理を最後まで走らせられる。
大規模サイトでプラグインが途中で止まる原因
WordPressの管理画面から実行するプラグインの一括処理は、Webサーバーを介したHTTPリクエストのなかで動く。このリクエストにはサーバー側で複数の時間制限がかかっており、処理がそれを超えると強制終了する仕組みだ。
とくに影響が大きいのは以下の3つだ。
- PHPの最大実行時間（max_execution_time）
- PHPのメモリ制限（memory_limit）
- WebサーバーやFastCGIのリクエストタイムアウト
5000件を超える投稿があるような大規模サイトでは、1回のリクエストですべてのデータを処理しようとすると、これらの制限に引っかかる。結果として「0/」のまま進捗が表示されず、しばらくしてエラー停止する。
プラグインのバッチ処理設定を見直す
最初に確認すべきは、そのプラグインがもつ「一度に処理する件数」の設定だ。多くの一括処理系プラグインは、内部的にデータを小分けにして処理するバッチサイズを指定できる。
プラグインの設定画面を開き、「1回あたりの処理件数」や「Records per iteration」といった項目を探す。デフォルトでは無制限に近い値になっていることも多く、これを10件〜50件程度まで下げるだけでエラーが解消するケースは多い。
バッチサイズを小さくすると処理全体の回数は増えるが、1回あたりの負荷が下がるためPHPやサーバーの制限にかかりにくくなる。この調整だけで問題が解決するなら、最も手軽でリスクの低い対処法だ。
一括処理を開始する
バッチサイズを小さくして再試行する
上の図は、バッチサイズを調整するだけで一括処理が正常に完了する流れを表している。
PHPの最大実行時間とメモリ制限を引き上げる
バッチサイズの調整だけでは改善しない場合、PHP側の制限値が厳しすぎる可能性が高い。とくにレンタルサーバーの共用プランでは、max_execution_time が30秒、memory_limit が128MB程度に設定されていることが多い。
まず wp-config.php に以下の行を追加して制限を緩和する。
set_time_limit(300);
define('WP_MEMORY_LIMIT', '256M');set_time_limit(300) はPHPの最大実行時間を300秒に延長し、WP_MEMORY_LIMIT はWordPressが利用できるメモリ上限を256MBに引き上げる。必要に応じて値をさらに増やしても構わない。
サーバー環境によっては、php.ini や .user.ini で直接 max_execution_time と memory_limit を指定できる場合もある。どちらの方法が有効かはサーバー仕様に依存するため、変更後は必ず phpinfo() やサイトヘルス画面で反映を確認する。
また、管理画面からの実行に限らず、サーバー負荷の高い処理ではメモリが不足しがちだ。256MBでも足りないようであれば512MBまで引き上げることを検討する。
サーバー側のリクエストタイムアウトを確認する
PHPの実行時間を延ばしてもエラーが続くなら、WebサーバーやFastCGIのリクエストタイムアウトが原因だ。Apacheのmod_fcgidを使っている環境では、FcgidIOTimeout や FcgidBusyTimeout が短く設定されていると、PHPが処理中でも接続を切られてしまう。
この設定はサーバー全体に影響するため、共用サーバーではユーザー側で変更できないケースがほとんどだ。該当しそうな場合はサーバー管理会社のサポートに「管理画面の長時間処理が途中で切れる」と伝え、設定の緩和が可能か問い合わせる。
VPSや専用サーバーを利用しているなら、ApacheやNginxの設定ファイルでタイムアウト値を直接編集できる。変更後はWebサーバーの再起動を忘れずに行う。
WP-CLIでバックグラウンド処理を実行する
サーバーがWP-CLIに対応しているなら、ブラウザからのHTTPリクエストではなくコマンドラインからプラグインの処理を走らせるのが最も確実な回避策だ。CLI実行にはWebサーバーのタイムアウト制限が適用されないため、大規模データでも安全に処理できる。
ただし、すべてのプラグインがWP-CLIコマンドを提供しているわけではない。まずプラグインの公式ドキュメントで「WP-CLI commands」の有無を確認し、該当するコマンドがあればターミナルから実行する。
実行例は以下のような形だ。
wp plugin-command run --batch-size=20WP-CLIが使えない場合は、処理を手動で分割してブラウザから複数回に分けて実行する方法も有効だ。たとえばカテゴリ別や投稿タイプ別に絞り込み、1回の処理対象を数百件以下に抑える。
これらの手順を順に試すことで、多くの大規模サイトで発生するタイムアウトエラーは解決できる。
よくある質問
共有サーバーでもPHPの最大実行時間は変更できるか
wp-config.php での set_time_limit() や .user.ini による上書きが許可されていれば可能だ。ただしサーバー側で一律に上限が決められており、設定値を超えて延長できない場合もある。
バッチサイズを小さくしても途中で止まる場合はどうすればよいか
メモリ制限と最大実行時間の両方を引き上げた上で、さらにバッチサイズを絞る。それでも改善しない場合は、サーバー側のリクエストタイムアウトが原因の可能性が高いため、サポートへの問い合わせやWP-CLIの利用を検討する。
「error-generation stopped」以外のエラーが表示されることはあるか
「このサイトで重大なエラーが発生しました」というWordPressの標準エラー画面や、「504 Gateway Timeout」といったサーバーエラーが表示されることもある。いずれも根本的な原因は処理時間の超過であることが多い。
特定のプラグインでしか発生しない場合はどう対処するか
まずそのプラグインの設定画面でバッチサイズを調整する。設定項目がなければ、開発元に問い合わせてフックやフィルターでバッチサイズを変更できないか確認する。別のプラグインで代替できる機能であれば、乗り換えも選択肢になる。
設定を変えてもまったく改善しない場合はサーバー移転が必要か
すべての設定を試しても解決しないなら、現在のサーバープランが大規模サイトの運用に適していない可能性が高い。VPSや専用サーバーなど、より自由度の高い環境への移行を検討するタイミングだ。
この記事のポイント
- 大規模サイトの一括処理停止はPHPとサーバーの制限が原因
- プラグインのバッチサイズを10〜50件に下げると効果的
- max_execution_timeとmemory_limitの引き上げも併用する
- 共用サーバーではサポートへの問い合わせが必要な場合もある
- WP-CLIが使えれば最も確実に回避できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Mollie決済プラグインでPHP警告「Undefined array key」が出たときの対処法
Mollie Payments for WooCommerce で「PHP Warning: Undefined array key “identifier”」という警告が出ても、決済フローや Apple Pay の動作に支障はない。この警告は PHP 側の配列キー未定義による軽微な通知であり、プラグイン開発元が修正を予定している。緊急の対応が必要でなければ、エラーログへの出力を抑える設定で一時的に回避できる。
なぜ「Undefined array key “identifier”」警告が発生するのか
この警告は、PHP 8.0 以降で強化された型と配列アクセスの安全性チェックによって表面化したものだ。Mollie プラグインの Apple Pay 関連クラス内で、変数やリクエストデータに「identifier」というキーが存在しない状態で配列アクセスを行っているために出力される。
PHP 8.0 以降の配列アクセスへの影響
PHP 7.x までは、配列内に存在しないキーを参照しても通知（Notice）または軽微な警告（Warning）で済む場面が多かった。しかし PHP 8.0 からは「Undefined array key」が Warning に格上げされている。テーマやプラグインが最新の PHP に完全対応していないと、こうした警告が表面化しやすい。
Mollie プラグインの該当コードが生む状況
警告の発生箇所は ResponsesToApple.php の 89 行目と ApplePayDataObjectHttp.php の 193 行目付近だ。Apple Pay のトークン処理やデータオブジェクトの動的生成時に、送信されてくるパラメータが一部欠落している場合や、プロパティが未定義のままアクセスされている場合に警告が記録される。
もう一つの「Creation of dynamic property」は PHP 8.2 で導入された非推奨通知で、クラスに明示的に宣言されていないプロパティへ動的に値を代入している場合に発生する。いずれも決済処理の本筋を妨げるエラーではなく、サーバーのエラーログに記録されるだけの通知レベルだ。
エラーログを確認して影響度を判断する
警告の発生頻度や実際の影響を把握するには、まずサーバーのエラーログを確認する。多くの国内レンタルサーバーでは管理画面のログビューアから確認できるほか、FTP で /wp-content/ 内の debug.log を直接ダウンロードしてもよい。
エラーログの保存場所と見方
WordPress のデバッグモードを有効にしている場合、wp-config.php に定義された WP_DEBUG_LOG の設定に従い、エラーログが出力される。デフォルトでは /wp-content/debug.log に保存される。
ログを開くと日付とともにエラーレベルが記録されている。「PHP Warning」と「PHP Deprecated」の行を探し、該当のプラグイン名とファイルパスが含まれているかを確認する。もし1時間に数千回単位で記録されているようであれば、ログファイルが肥大化してディスク容量を圧迫する可能性があるため対応が必要だ。
警告の発生頻度を調べる簡単なコマンド
SSH 接続が可能なサーバーであれば、grep コマンドで頻度を数えられる。以下のように実行すると「identifier」を含む警告の出現回数がわかる。
grep -c "Undefined array key \"identifier\"" /home/user/domains/example.com/public_html/wp-content/debug.log数十件程度であれば運用上の支障は少ないが、数百件以上ある場合は早めの抑制を検討する。
PHP 警告を一時的に非表示にする方法
根本的な修正がプラグイン側で提供されるまでの間、エラーログへの出力を抑える設定で運用上のノイズを減らせる。複数の段階的な手法があるので、サイトの状況に合わせて選択する。
エラーレポートレベルを変更する
wp-config.php に以下の定数を追加すると、Warning と Deprecated をログから除外できる。この設定は本番環境で推奨される標準的なエラー抑制の手法だ。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'error_reporting', E_ALL & ~E_WARNING & ~E_DEPRECATED );WP_DEBUG_DISPLAY を false にすることで画面表示を防ぎ、error_reporting のビット演算で Warning と Deprecated だけを除外する。Fatal error など重大なエラーは引き続き記録されるため、サイトの異常を見逃すリスクは低い。
Mollie プラグイン固有のフックで抑制する
よりピンポイントに対処するなら、Mollie が提供するフィルターフックを利用する方法もある。ただし、これはプラグインのバージョンによって動作が異なるため、公式ドキュメントを参照のうえ実装する必要がある。
多くの場合、前述のエラーレポート設定で十分に警告は抑制できる。プラグイン更新後に設定を元に戻すことを忘れずに、スケジュールに組み込んでおく。
wp-config.php を開くWP_DEBUG_DISPLAY を false に設定するerror_reporting を設定して Warning と Deprecated を除外プラグインのアップデートを待つときの注意点
Mollie の開発チームはこの警告を認識しており、将来のバージョンで修正が行われる見込みだ。プラグインの更新を待つ間は、以下の点に注意してサイトを運用する。
自動アップデートを有効にしておく
WordPress の管理画面で Mollie Payments for WooCommerce の自動アップデートをオンにしておくと、修正版がリリースされた際に即座に適用される。更新を手動で行う場合は、Mollie の changelog を定期的にチェックし、「identifier」や「dynamic property」に関する修正が含まれているかを確認する。
ログのローテーションを設定する
警告が高頻度で出ていると debug.log が急速に肥大化する。サーバーのログローテーション機能や、WordPress 用のログ管理プラグインを導入して、一定期間で古いログを圧縮・削除する仕組みを整えておく。これによりディスク容量の圧迫を防げる。
よくある質問
この警告が出ていても決済は正常に動くのか
多くの場合、クレジットカードや Apple Pay の決済処理に影響はない。PHP Warning や Deprecated は実行を停止させるエラーではなく、処理は継続される。実際に決済が通っているかは、テスト購入を行って確認するのが確実だ。
他の決済プラグインでも同じ警告は出るのか
PHP 8.0 以降に完全対応していないプラグインであれば、同様の「Undefined array key」警告が発生する可能性がある。Stripe や PayPal の公式プラグインでも、過去に似たような警告が報告され修正されている。プラグインが最新かどうかを常に確認することが重要だ。
プラグインを自分で修正してもよいのか
PHP の知識があるなら、該当行に isset() によるキー存在チェックを追加すれば警告は消える。ただし、プラグインのアップデートで修正が上書きされるため、修正を維持するには継続的な管理が必要だ。本番環境では推奨しない。
PHP のバージョンを下げれば解決するか
PHP 7.4 に戻せばこの警告は出なくなるが、PHP 7.4 はすでにセキュリティサポートが終了している。サイト全体の安全性を損なうため、PHP のダウングレードは避けるべきだ。サーバー環境は常にサポート対象の PHP バージョンを維持する。
「Creation of dynamic property」も同じ対処でよいのか
同じエラーレポートレベルの設定で抑制できる。こちらも PHP 8.2 以降の非推奨通知であり、機能停止を伴わない。根本対応はプラグイン側でプロパティ宣言を追加する必要があるため、開発元のアップデートを待つ形になる。
この記事のポイント
- 「Undefined array key」警告は決済機能に影響しない軽微な通知
- PHP 8.0 以降の配列アクセス厳格化によって表面化している
- エラーレポートレベルの変更で一時的にログ出力を抑制できる
- プラグインの自動アップデートを有効にして修正版の適用に備える
- PHP バージョンのダウングレードはセキュリティリスクがあるため避ける
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている