プラグインでadd_blog_optionの代わりにMultisiteでadd_optionを使用することの何が問題になっています
私は新しいプラグインに取り組んでいますが、データベースにオプションを保存するために保存するのが私の最初です。
現在私はadd_optionを使っています、そして私はそれを仮定しました
- アクティベーションが失敗する、または - 間違った値がwp_blogID_optionsテーブルに保存される
私はadd_blog_optionを使っていなかったからです。すべての 投稿 /文学（Wrox、Apressなど）私が読んだのはadd_blog_optionを使う必要があるということです。
しかし、私が行ったすべてのテスト（およびSQLテーブルの検査）は、私が間違っていることを証明しています。それで...プラグインを作るときにadd_blog_optionの代わりにadd_optionを使うことの何が問題になっていますか（それはシングルインストールかマルチサイトかもしれません）。
私には... add_option（あるいはget_optionさえ）はすべてうまくいくようです。 Settings APIには保護ラッパーがあると思います。
しかし、それはadd_blog_option（またはget_blog_option）の使用が「純粋主義者」のためだけのものであることを意味します。
私が「学ぶ」ようになったのは、マルチサイト設定のためのプラグインアクティベーションに関する3つの状態があるということです。
新しいプラグインをインストールするサイト管理者のためにこれを考えてください。
- プラグインはネットワークでアクティブ化されています - しかしセットアップを完了するには管理者が必要です（ステートレスと呼びます）。
- プラグインが有効になっていて、ブログごとに「独自の機能」はなく、設定を完了するために管理者ユーザは必要ありません（アクティブと呼びます）。
- プラグインが有効化され、ブログごとに独自の機能があり、設定を完了するには管理者ユーザーが必要です（保留中）。
シナリオ1：プラグインはステートレスなので、プラグインの有効化（またはネットワークの有効化）で 'add_option'を安全に使用できます。
シナリオ2： 'add_blog_option'を使用して各ブログをループ処理する必要があります - プラグインがアクティブになるのでネットワークアクティベーションを行う場合。
シナリオ3：あなたは 'add_blog_option'を使わなければならず、理想的にはプラグインが保留中なのでネットワークアクティベーションを許可しません。
私の場合、ブログの所有者がショートコードのあるページを作成するまで、私のプラグインは何もしません。
add_blog_optionは最終的に コンテキスト を提供されたブログIDに切り替えた後にadd_option自身を呼び出してオプションを追加します。違いは、add_optionは現在のブログのコンテキストでのみ機能するという点です。ここで、add_blog_optionでは、現在のコンテキストとは異なる可能性があるブログIDを指定できます。