Je travaille sur un nouveau plugin mais c'est la première fois que je sauvegarde, ce qui enregistrera une option dans la base de données.
J'utilise actuellement add_option
et j'ai supposé que
- l'activation échouait ou - la valeur erronée serait enregistrée dans la table wp_blogID_options
parce que je n'utilisais pas add_blog_option
. Tous les articles /littérature (Wrox, Apress, etc.) que j'ai lus disent que je dois utiliser pour add_blog_option
.
Mais tous mes tests (et l'inspection de la table SQL) me prouvent le contraire. Alors ... Qu'est-ce qui ne va pas avec add_option au lieu de add_blog_option lors de la création d'un plugin (installation unique ou multisite)?
Pour moi ... il semble que add_option
(ou même get_option
) fonctionne correctement. J'imagine que l'API Settings possède un wrapper de protection.
Cependant ... cela voudrait dire que add_blog_option
(ou get_blog_option) ne sont que pour les "puristes".
Ce que je viens d'apprendre, c'est qu'il y a 3 états d'activation de plug-in pour une configuration multi-site.
Considérez ceci pour un administrateur de site qui installe un nouveau plugin:
Scénario 1: vous pouvez utiliser 'add_option' en toute sécurité lors de l'activation d'un plugin (ou d'une activation réseau) car le plugin est sans état .
Scénario 2: vous devez utiliser 'add_blog_option' et parcourir chaque blog - si vous effectuez l'activation réseau comme le plugin sera actif .
Scénario 3: vous devez utiliser 'add_blog_option' et idéalement, vous n'autorisez pas l'activation réseau car le plug-in est en attente .
Dans mon cas, mon plugin ne fait rien jusqu'à ce que le propriétaire du blog crée une page avec le shortcode.
add_blog_option
appelle finalement add_option
lui-même pour ajouter l'option après la commutation du contexte vers l'ID de blog fourni. La différence est que add_option
ne fonctionnera que dans le contexte du blog actuel, où add_blog_option
vous permettra de spécifier un identifiant de blog pouvant être différent du contexte actuel.