WordPressのプラグイン競合をテストするには、クリーンな使い捨てWordPressサンドボックスで問題を再現し、症状が再現されるまでプラグインを1つずつ有効化します。WordPressのプラグイン競合とは、2つのプラグイン、またはプラグインとテーマやWordPressコアが、同じフック・エンキューされたスクリプト・データベースオブジェクトを巡って衝突することで起こり、修正は常にどの2つの要素が実際に衝突しているかを特定することから始まります。その分離をライブサイトではなく使い捨てサイトで行うことが、5分のテストと障害の差になります。
今すぐ始められます。このページ上部のWordPressを起動を押すと、wp.runが数秒でクリーンなWordPressインストールを開きます。競合テストに必要なコントロールされたベースライン環境で、サインアップ・クレジットカード・本番サイトへのリスクは一切不要です。
ライブサイトで競合を診断できない理由
「すべてのプラグインを無効化してから1つずつ再有効化する」という古典的なアドバイスは精神的には正しいが、実践上は危険です。実際に訪問者にサービスを提供しているサイトで実行することになります。すべての無効化はダウンタイムであり、決済の破損であり、二分探索中に失われたフォームです。
2つ目の静かな問題もあります。本番サイトは何かを分離するのに最悪の場所です。カスタムテーマ・mu-plugins・ドロップイン・オブジェクトキャッシュ・ホストレベルのページキャッシュ・特定のPHPビルドを抱えています。症状が現れたとき、原因が疑っている2つのプラグインなのか、その環境との何らかの相互作用なのかが判断できません。変数が多すぎて同時に動いています。
クリーンなWordPressサンドボックスはこれらの変数をすべて取り除きます。ストックテーマ・他のプラグインなし・既知のWordPressとPHPバージョンという環境が得られます。そこで競合が再現すれば、それは本物のプラグイン対プラグインの問題です。キャッシュでも、テーマでも、ホストでもありません。クリーンなインストールで再現しない場合も同様に有益です。問題はあなたの環境にあり、プラグイン作者が再現できないバグレポートを提出する手間が省けます。
WordPressプラグイン競合の段階的な分離方法
これがコアのワークフローです。各ステップは使い捨てのwp.runサンドボックス内で実行されるため、ここで行うことは本番サイトに影響しません。
- まずライブスタックを確認する。 本番環境でツール → サイトヘルス → 情報を開き、WordPressとPHPのバージョンをメモします。サンドボックスがそれに合っていないと、テストが環境を証明しないことになります。
- クリーンなベースラインを起動する。 同じWordPressとPHPバージョンで新鮮なwp.runサンドボックスを開きます。管理者認証情報がすでに生成された一時的な
*.wprun.siteのURLに着地します。デフォルトテーマのみで追加プラグインゼロの状態で、症状が発生しないことを確認します。これがコントロールです。 - 疑わしいプラグインを追加する。 関係するプラグインをインストールします。疑っている2つのプラグイン、またはまだ疑いのある対象がなければアクティブなリスト全体を入れます。既知のプリセットは起動URLパラメーターとして渡すか（例：
?plugin=woocommerce）、wp-admin内から各プラグインのZIPをアップロードします。 - 正確なトリガーを再現する。 サイトで壊れる正確なアクションを再現します。ページを読み込む・フォームを送信する・ブロックエディターを開く・チェックアウトを実行するなど。サンドボックスで症状を発生させられることを確認します。できない場合、競合は環境固有のものです。ステージングに移行してください。
- 1つずつ有効化する。 プラグインを個別にオンにし、各有効化後にトリガーを再実行します。症状を発生させるプラグインが主要な容疑者です。正確なバージョンとともにメモします。
- 両当事者を確認する。 競合には2つの側面が必要です。容疑者を有効にした状態で、他のプラグインを切り替えてどの組み合わせが壊れるかを見つけ、両方のプラグインと関係するバージョンを特定します。
- テーマを競合から除外する。 Twenty Twenty-Fourなどのデフォルトテーマに切り替えてから、自分のテーマに戻します。症状が自分のテーマが有効な場合のみ戻るなら、プラグイン対プラグインではなくテーマとプラグインの競合であり、修正はテーマにあります。
- 証拠を記録してURLを共有する。 バージョン・スクリーンショット・ブラウザコンソールや
WP_DEBUGのエラーを記録し、サンドボックスがまだ生きている間に一時的な*.wprun.siteリンクをメモやバグレポートにコピーします。
このループ全体が数分で終わり、サンドボックスは自動削除されるためクリーンアップが不要です。
具体例：SEOプラグイン対ページビルダー
コンタクトページがエディターでは正常に表示されるがフロントエンドでレイアウトが崩れ、SEOプラグインとページビルダーが衝突していると疑っています。
- ライブのWordPressとPHPバージョンに合わせたサンドボックスを起動します。
- デフォルトテーマとプラグインなしの状態で、ブロックで作ったページを開きます。レイアウトはクリーン。ベースライン確認。
- ページビルダーをインストールし、コンタクトレイアウトを再構築してフロントエンドで確認します。まだクリーン。
- SEOプラグインを有効化してリロードします。レイアウトが崩れます。これで対となるものが特定されました。
- ブラウザコンソールを開きます。SEOプラグインの出力が、ビルダーのテンプレートが想定していないマークアップを注入しています。コンソールと崩れたレンダリングをスクリーンショットに収めます。
*.wprun.siteのURL・両プラグインのバージョン・手順をプラグイン作者へのレポートに貼り付けます。
競合を証明し、両当事者を特定し、メンテナーが開ける再現環境を作成しました。本番サイトにどちらのプラグインも読み込ませることなく。
証拠として結果URLを共有する
「自分のサイトで壊れる」としか説明できない競合は、メンテナーが対応できません。ライブのクリーンな再現環境として手渡せる競合は修正可能なバグです。すべてのwp.runサンドボックスには共有可能な*.wprun.siteのURLがあるため、サポートチケット・プラグインのGitHub issue・チームメンバーへのメッセージに正確に失敗している環境を添付できます。同じインストールを開き、同じトリガーを実行すれば、あなたが見ているものが見えます。「自分の環境では動く」という膠着状態はありません。
よくある失敗
これらはテストを静かに無効化するプロセスエラーです。
- 本番環境でデバッグする。 ライブのプラグインを二分探索するのはダウンタイムであり、環境ノイズが本当の原因を隠します。代わりにクリーンな使い捨てインストールで再現します。
- 実際にはクリーンでないサイトでテストする。 残ったmu-plugins・ドロップイン・前回テストのデータベース行は分離の意味を完全に損ないます。保証されたベースラインが必要なたびに新鮮なサンドボックスから始めます。
- 一度に2つの変数を変える。 プラグインを切り替えながら同じステップでキャッシュをクリアするとシグナルが壊れます。1つ変えてテストし、次を変えます。
- すべての競合がプラグイン対プラグインだと思い込む。 テーマとWordPressコアも競合の当事者です。別のプラグインを責める前に常にデフォルトテーマのチェックを実行します。
- バージョンを合わせない。 ライブサイトが動作しているPHPとWordPressのバージョンで再現します。PHP 8.1でのみ存在する競合は8.4でテストしても現れません。逆も同様です。
- 証拠を保存する前にサンドボックスを有効期限切れにする。 一時サイトは自動削除されます。環境がまだ生きている間にスクリーンショット・バージョン・URLをキャプチャします。
ステージングで再現すべき場合
クリーンなサンドボックスは1つの質問に正確に答えます。*これらのプラグインは分離された状態で競合するか？*ほとんどの場合これが正しい質問であり、信頼できるプラグイン互換性テストへの最速の道です。しかし一部の競合は、実際のコンテンツ・ユーザーロール・カスタムフィールド・サーバー設定があって初めて現れます。サンドボックスがユーザーが明らかにヒットするバグを再現できない場合、問題は環境固有のものです。本番に近いステージングサイトを上に重ねてそこでデバッグします。サンドボックスを使って競合が実在することを証明し、プラグイン問題を素早く分離し、ステージングを使って特定のデータに対して修正を確認します。
FAQ
WordPressのプラグイン競合とは何ですか？
WordPressのプラグイン競合とは、2つのプラグイン、またはプラグインとアクティブなテーマやWordPressコアが、通常は同じアクションやフィルターにフックしたり、衝突するスクリプトをエンキューしたり、同じデータベースオブジェクトに書き込んだりすることで互いに干渉する場合に発生します。結果として、いずれのコンポーネント単独では発生しない画面の破損・致命的なエラー・保存の失敗・フロントエンドのリグレッションが起こります。
どのプラグインが問題を引き起こしているかを見つけるには？
クリーンなWordPressサンドボックスで問題を再現し、プラグインを1つずつ（速度のために半分ずつでも可）有効化し、各有効化後に失敗するアクションを再実行します。症状を発生させるプラグインが犯人です。残りを切り替えてそれと衝突する2つ目のプラグインを見つけます。
ライブサイトでプラグインを無効化して競合をテストしなければなりませんか？
いいえ、すべきではありません。本番でプラグインを無効化するとダウンタイムが発生し、環境ノイズが結果に混入します。ライブのWordPressとPHPバージョンに合わせた使い捨てサンドボックスを起動し、同じプラグインをインストールして、使い捨てサイトで分離手順を実行します。
テーマはプラグイン競合を引き起こすことがありますか？
はい。テーマは衝突するアセットをエンキューしたり、テンプレートをオーバーライドしたり、プラグインが使うのと同じアクションにフックしたりできます。常にTwenty Twenty-Fourなどのデフォルトテーマでテストしてください。デフォルトテーマで症状が消える場合、競合は2つのプラグイン間ではなくプラグインとテーマの間にあります。
バグレポートのためにプラグイン競合を共有するには？
サンドボックスで競合を再現し、正確なプラグインバージョンとトリガーする手順とともに一時的な*.wprun.siteのURLをバグレポートにコピーします。メンテナーは同じライブ環境を開いて問題を即座に再現でき、漠然とした苦情が対応可能なレポートに変わります。
競合が訪問者に届く前に見つける
クリーンなインストールで症状を再現し、2つのプラグインが特定されるまで二分探索し、テーマとバージョンを確認し、メンテナーが開けるリンクを手渡します。ライブサイトはその間ずっと稼働しており、テストは後片付けを何も残しません。