Je suis en train de créer mon premier plugin et je me suis retrouvé dans l'obligation d'appeler les mêmes variables d'option dans différentes parties de la même page. J'ai donc cherché une solution et suis tombé sur des variables globales qui semblent fonctionner pour moi, mais après en avoir lu quelques-unes. les articles que les gens semblent opposer à l’utilisation de variables globales et, en outre, je ne suis pas tout à fait sûr de les utiliser correctement.
Voici ce que j'ai
/************************
* Variables
************************/
global $bClass, $cClass, $dClass, $cExpiry;
$bClass = $cClass = $dClass = $cExpiry = get_option('myoption');
Puis, comme je n’utilise qu’une seule option pour enregistrer les variables pertinentes dans un tableau, je renvoie la valeur comme celle-ci.
jquery
expires: <?php global $cExpiry; echo $cExpiry['cExpiry']; ?>,
et puis je l'utiliserais aussi dans d'autres fonctions de la même page.
Donc, cela fonctionne pour moi, mais je me demande toujours si je le fais bien.
update Merci pour l'explication les gars, j'ai fini par utiliser des variables locales et j'ai également trouvé une erreur dans mon code;
Comme toutes mes variables sont enregistrées dans une seule option, je n’ai utilisé qu’une seule variable locale;
$options = get_option('myoption');
Ensuite, j'aurais accès au tableau en plaçant la variable entre parenthèses
<?php echo $options['var1']; ?>
Alors qu'avant je faisais $bClass = $cClass = $dClass = $cExpiry = get_option('myoption');
qui est mauvais.
Il existe des moyens plus faciles que cela. Comme @Wyck a déjà déclaré que l’utilisation de globals est une mauvaise idée, voici une courte explication et la marche à suivre:
1) Tout le monde peut y accéder partout. Tout d'abord, cela sonne bien, mais vous pouvez également procéder comme suit:
// Your code: default value
global $foo;
$foo = 'bar';
// User setting:
global $foo;
$foo = get_option( 'baz' );
// Later in your code
if ( 'bar' === $foo )
// do something important
// Now I, the end user, do this in a template
// or Ernie, the novice developer, does this in his 3rd party plugin:
$GLOBALS['foo'] = 42;
et tout à coup, rien ne fonctionne comme prévu. Aussi simple que cela soit: les globes peuvent être interceptés. Ils ne sont pas libres de conflits et personne ne peutjamaisêtre sûr de ce qu'ils contiennent.
2) Une fois que vous savez maintenant qu’ils peuvent changer à la volée, vous savez qu’ils sontimprévisibles. Et si vous voulez les retrouver avec votre IDE (par exemple, PHPStorm, Eclipse/Aptana, etc.), vous ne saurez jamais où se trouve leur origine ou exactement où ils ont été modifiés ... sauf si vous restez assis pendant un bon moment et utilisez des choses comme les points d'arrêt et quelque chose comme XDebug et vous connaissez votre chemin.
3) Dois-je vraiment écrire plus? Je suppose que non.
Conclusion: Comme la plupart des options sont chargées automatiquement, elles sont déjà présentes sur chaque page/requête et ne doivent pas nécessairement être encapsulées dans un fichier global. Appelez simplement get_option()
chaque fois que vous en avez besoin.
Simple comme c'est: wp_localize_script()
Exemple: (peut également être utilisé avec les hooks login_enqueue_scripts
et admin_enqueue_scripts
)
add_action( 'wp_enqueue_scripts', 'wpse115840_scripts' );
function wpse115840_scripts()
{
wp_enqueue_script( 'wpse_handle', etc... );
// Here goes the magic:
wp_localize_script( 'wpse_handle', 'wspeObject', array(
'foo' => 'bar',
'bar' => get_option( 'baz' )
) );
}
Maintenant, vous pouvez accéder à toutes les données du tableau wp_localize_script()
(le 3ème argument) de votre fichier javascript que vous venez d’inscrire/mettre en file d'attente simplement en appelant wpseObject
. L'exemple suivant vous donnerait maintenant la valeur bar
:
console.log( wpseObject.foo );
et votre wpseObject.bar
conserverait votre valeur de paramètre baz
.