マルチサイト互換性には2つのタイプがあります。
- 受動的な互換性:マルチサイト固有の処理は何もせず、何も壊すことなく機能します。
- アクティブな互換性:マルチサイト固有の動作の変更または拡張。
私はあなたが1に出ていると思います。第2部については、WordCamp Prague 2015の私のスライドを参照してください。
マルチサイトについて何も言わないプラグインは、ネットワークプラグインとしてアクティブ化しないでください。たとえばWooCommerceは、インストール中にいくつかのカスタムテーブルを作成します。ネットワーク全体で有効にすると、サブサイトはこれらのテーブルを取得できず、空が頭に落ちます。
残念ながら、ほとんどのプラグインはアクティベーションタイプをチェックしないため、間違ったアクティベーションを行うことができます。
関連するのは、非互換プラグインのサブサイトでクリックしなければならない管理ポインターや特別な「概要」ページなどのUXの問題です。YoastのWP SEOはその一例です。これはすぐにそのプラグインで修正されると思います。:)
その他の問題は、そのマルチサイトで何をするかによって異なります。各サイトが1つの言語で記述され、サイトが相互に接続されている多言語Webサイトを構築している場合、コンテンツを記述するときに投稿を同期する必要があります。つまりswitch_to_blog()
、フックを呼び出しsave_post
、接続された投稿も保存します。save_post
現在、1つのリクエスト中に複数回呼び出されます。多くのプラグインはこのような状況を認識していないため、接続されている投稿の投稿メタ情報を上書きし、まだ最初の投稿にいると見なします。
ポストメタを処理していて、次のようなチェックが欠けているプラグインを探します。
if ( is_multisite() && ms_is_switched() )
return FALSE;
これらのプラグインは互換性がありません。
同様に、プラグインがユーザーのメタフィールドに触れたり、ルールを書き換えたりするときの問題も、特定するのは難しいですが。
一部のプラグインは、ファイル名にサイトIDを含めずにコンテンツをファイルに書き込もうとします。それらも壊れている可能性が非常に高いです。
トムが言ったように:テストインストールを作成し、想像できるすべてのユースケースを実行します。プラグインページを信頼することはできません。通常、とにかく十分な情報がありません。