Les tiers devraient-ils utiliser $ wp_scripts / $ wp_styles-add_data?

30

Dans la classe WP_Dependencies , il existe une méthode nommée add_data . Cette fonction ajoute des données aux scripts / styles qui ont été mis en file d'attente lors du chargement de WordPress. Une utilisation fréquemment citée de cette fonction consiste à ajouter une condition lors de l’ajout de feuilles de style destinées à différentes versions d’IE. Par exemple, pour cibler IE8 et versions antérieures:

function test_wp_print_styles() {
    global $wp_styles;

    wp_enqueue_style( 'test-style', get_template_directory_uri() . '/css/test.css', array(), 1, 'all' );
    $wp_styles->add_data( 'test-style', 'conditional', 'lte ie8' );
}
add_action( 'wp_print_styles', 'test_wp_print_styles' );

Ceci sera rendu comme:

<!--[if lte ie8]>
<link rel='stylesheet' id='test-style-css'  href='http://trunkosaurus.dev/wp-content/themes/twentyeleven/css/test.css?ver=1' type='text/css' media='all' />
<![endif]--> 

Lorsque je regarde dans Core, je vois quelques endroits où cette méthode est utilisée:

  • WP_Styles->add_inline_style() : ajoute un style en ligne après le feuille de style référencée (réalisée via WP_Styles->print_inline_style() )

  • WP_Scripts->localize() : ajoute un objet codé JSON (entouré par le plus "public" wp_localize_script() function)

  • wp_plupload_default_settings() : ajoute un objet codé json (créé à partir de un tableau multidimensionnel) pour le script 'wp-plupload' (notez que c'est à venir dans 3.4)

  • lors de l'enregistrement / la mise en file d'attente des scripts et styles Ajout de données pour les scripts par défaut ( wp-includes/script-loader.php )

D'après les utilisations de la méthode, celle-ci ne semble pas avoir de cas d'utilisation spécifique. Dans wp_plupload_default_settings , cela semble permettre l’injection arbitraire de données. Dans wp_register_script , il semble être utilisé pour différencier les scripts d'en-tête et de pied de page. Dans add_inline_style , il est utilisé pour désigner le style en ligne à ajouter après la mise en file d'attente d'une feuille de style spécifiée.

Une excellente utilisation de cette fonction serait quelque chose comme le code suivant où vous mettez en file d'attente un script externe mais que vous devez lui envoyer quelques vars de configuration, dont certains proviennent de la base de données:

function zdt_enqueue_add_this() {
    global $wp_scripts;

    wp_enqueue_script( 'zdt-add-this', 'http://s7.addthis.com/js/250/addthis_widget.js#pubid=myidhere' );

    // Contrived example of database call to get a twitter handle stored in the db
    $author_twitter_handle = zdt_get_twitter_handle();

    $js = "var addthis_share = { templates : { twitter: '{{title}} {{url}} (by @" . sanitize_key( $author_twitter_handle ) . "' } };\n";
    $js .= 'var addthis_config = { ui_header_color: "#FFFFFF", ui_header_background: "#FA9628", ui_cobrand: "My Site" };';

    $wp_scripts->add_data( 'zdt-add-this', 'data', $js );
}
add_action( 'wp_enqueue_scripts', 'zdt_enqueue_add_this' );

Cela se traduira par:

<script type='text/javascript'>
/* <![CDATA[ */
var addthis_share = { templates : { twitter: '{{title}} {{url}} (by @tollmanz' } };
var addthis_config = { ui_header_color: "#FFFFFF", ui_header_background: "#FA9628", ui_cobrand: "My Site" };
/* ]]> */
</script>
<script type='text/javascript' src='http://s7.addthis.com/js/250/addthis_widget.js?ver=3.4-beta4-20731#pubid=myidhere'></script>

Notez que cela ne peut pas être accompli avec wp_localize_script , car l'objet addthis_share a des propriétés dans les propriétés ( J’ai écrit à propos de cette approche quelque peu sournoise auparavant ).

EDIT: Je me suis trompé en disant cela. wp_localize_script gère très bien les tableaux multidimensionnels.

Cette méthode semble très bien fonctionner pour les raisons suivantes:

  1. Il vous permet de joindre les données au descripteur de script pour qu'il soit toujours correctement mis en file d'attente avec le script. De plus, il sera intelligent de supprimer la mise en attente du script, de son ordre et de son placement.
  2. Il vous permet d'utiliser PHP pour envoyer des vars à JS.
  3. Cela semble plus organisé que d'utiliser wp_print_styles pour imprimer un script arbitraire qui sera traité ultérieurement par un script en file d'attente.

Certaines choses qui ne fonctionnent pas comme prévu m'inquiètent pour cette méthode. Un de ces problèmes est que si vous utilisez wp_localize_script avec $wp_scripts->add_data , vous pouvez obtenir des résultats inattendus. Par exemple:

// Contrived example of database call to get a twitter handle stored in the db
$author_twitter_handle = zdt_get_twitter_handle();

$js = "var addthis_share = { templates : { twitter: '{{title}} {{url}} (by @" . sanitize_key( $author_twitter_handle ) . "' } };\n";
$js .= 'var addthis_config = { ui_header_color: "#FFFFFF", ui_header_background: "#FA9628", ui_cobrand: "My Site" };';

$wp_scripts->add_data( 'zdt-add-this', 'data', $js );
wp_localize_script( 'zdt-add-this', 'addthis_share', array( 'var' => 'val' ) );

Produit:

<script type='text/javascript'>
/* <![CDATA[ */
var addthis_share = { templates : { twitter: '{{title}} {{url}} (by @tollmanz' } };
var addthis_config = { ui_header_color: "#FFFFFF", ui_header_background: "#FA9628", ui_cobrand: "My Site" };
var addthis_share = {"var":"val"};
/* ]]> */
</script>
<script type='text/javascript' src='http://s7.addthis.com/js/250/addthis_widget.js?ver=3.4-beta4-20731#pubid=myidhere'></script>

Attendu que ce script:

// Contrived example of database call to get a twitter handle stored in the db
$author_twitter_handle = zdt_get_twitter_handle();

$js = "var addthis_share = { templates : { twitter: '{{title}} {{url}} (by @" . sanitize_key( $author_twitter_handle ) . "' } };\n";
$js .= 'var addthis_config = { ui_header_color: "#FFFFFF", ui_header_background: "#FA9628", ui_cobrand: "My Site" };';

wp_localize_script( 'zdt-add-this', 'addthis_share', array( 'var' => 'val' ) );
$wp_scripts->add_data( 'zdt-add-this', 'data', $js );

Produit:

<script type='text/javascript'>
/* <![CDATA[ */
var addthis_share = { templates : { twitter: '{{title}} {{url}} (by @tollmanz' } };
var addthis_config = { ui_header_color: "#FFFFFF", ui_header_background: "#FA9628", ui_cobrand: "My Site" };
/* ]]> */
</script>
<script type='text/javascript' src='http://s7.addthis.com/js/250/addthis_widget.js?ver=3.4-beta4-20731#pubid=myidhere'></script>

La clé data définie par wp_localize_script est finalement remplacée par l'appel à $wp_scripts->add_data , alors que si vous appelez deux fois wp_localize_script pour le même script, la chaîne sera correctement concaténée.

Bien que tout cela soit un moyen très pratique d’imprimer un script arbitraire à utiliser avec un script en file d’attente, cela me fait penser qu’il ne devrait pas être largement utilisé en raison du risque de conflits. Je peux certainement voir un argument pour utiliser cela dans des projets personnels où le code ne sera pas utilisé dans les plugins / thèmes de la communauté.

J'ai également examiné Core Trac pour voir s'il existait des indices sur l'objectif de cette fonction. J'ai trouvé un ticket (http://core.trac.wordpress.org/ticket/11520) (épique) qui explorait d'autres moyens d'ajouter du JS arbitraire. Il semble donc intéressant de créer un meilleur moyen d’ajouter des JS arbitraires, sans savoir avec certitude si add_data devrait faire partie du processus.

Ma question principale est la suivante: les développeurs devraient-ils utiliser cette fonction? Dans certains cas (par exemple, wp_register_script ), cela semble être une fonction "privée" que des tiers ne devraient pas utiliser; Toutefois, dans d’autres cas (par exemple, wp_plupload_default_settings ), il semble être un moyen parfaitement raisonnable d’injecter du JS arbitraire avant un script mis en file d’attente.

Je n’imagine pas qu’il existe une réponse "correcte" à cette question, mais j'aimerais entendre ce que les autres développeurs pensent. J'imagine aussi qu'il y a des morceaux de ce puzzle que j'ai complètement négligés et j'aimerais entendre ce que les autres ont à dire à ce sujet.

    
posée tollmanz 10.05.2012 - 05:25

2 réponses

4
  

Cette fonction ajoute des données aux scripts / styles qui ont été mis en file d'attente lors du chargement de WordPress.

Pas vraiment. Il ajoute des données aux scripts / styles qui ont été registered .

  

La clé de données définie par wp_localize_script est finalement remplacée par l'appel à $wp_scripts->add_data , alors que si vous appelez wp_localize_script deux fois pour le même script, la chaîne sera correctement concaténée.

D'accord. Ils appellent tous les deux l'API sous-jacente (non accessible, interne) afin qu'elle soit écrasée (comme vous l'avez indiqué). Cela se produit quand on appelle $this->get_data( $handle, 'data' ); .

Question

  

Ma question principale est la suivante: les développeurs devraient-ils utiliser cette fonction?

Répondre

Simplement dit: Oui, quand vous n'avez aucune autre chance de faire ce dont vous avez besoin.

Autre exemple: vérifiez si un script a été enregistré (par exemple, json2/jquery ) et déplacez-le vers le pied de page (vérifiez extra['group'] ).

// Move scripts to the footer - in case it isn't already there
if ( ! $wp_scripts->get_data( 'json2', 'group' ) )
    $wp_scripts->add_data( 'json2', 'group', 1 );

if ( ! $wp_scripts->get_data( 'jquery', 'group' ) )
    $wp_scripts->add_data( 'jquery', 'group', 1 );

Remarque: Ceci ↑ ne fonctionne que pour les données classées sous extra !

Notes complémentaires

Contre-question: Avez-vous déjà essayé d'ajouter des dépendances aux scripts enregistrés par le noyau? Par exemple, essayez d’ajouter JSON2 selon vos besoins à jQuery . Ce n'est pas possible sans intercepter le global $wp_scripts :

global $wp_scripts;

$scripts = array( 
     'jquery'      => array( 'json2' )
    ,'jquery-form' => array( 'json2' ) 
);

foreach ( $scripts as $handle => $deps )
{
    // Ugly hack: Intercept the global to force the "natural"/needed order: JSON2 » jQuery
    $deps_default =& $wp_scripts->registered[ $handle ]->deps;
    $wp_scripts->registered[ $handle ]->deps = array_merge( $deps_default, $deps );
}

La classe ne peut pas faire beaucoup de choses. Donc, utiliser quelque chose comme ->add_data() est imo pleinement valide. Utilisez simplement ce que vous avez, car il est toujours préférable de vivre sans les classes de base.

    
réponse donnée kaiser 17.05.2012 - 13:23
1

WP 3.3 a beaucoup discuté de la gestion des données de script:

enlace

Notez que vous pouvez passer des tableaux imbriqués à wp_localize_data() maintenant:

wp_localize_script( 'jquery', 'jQueryL10n', array(
    'foo' => array(
        'bar' => array( 'apple', 'orange' )
    ),
) );

Ainsi, j'utiliserais add_data() s'il n'y avait pas d'API de niveau supérieur pour ce que je devais faire, sachant que son comportement pourrait changer dans certains cas extrêmes, comme lorsque la concaténation est impliquée.

    
réponse donnée scribu 18.05.2012 - 04:46

Lire d'autres questions sur les étiquettes