¿Deben los terceros usar $ wp_scripts / $ wp_styles-add_data?

Dentro de la clase WP_Dependencies existe un método llamado add_data . Esta función agrega datos a los scripts / estilos que se han puesto en cola durante la carga de WordPress. Un uso comúnmente citado para esta función es agregar un condicional al agregar hojas de estilo dirigidas a diferentes versiones de IE. Por ejemplo, para apuntar a IE8 e inferior:

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' );

Esto se procesará como:

<!--[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]--> 

Cuando miro a través de Core, veo un puñado de lugares donde se usa este método:

• WP_Styles->add_inline_style() : agrega un estilo en línea después de hoja de estilo a la que se hace referencia (realizada a través de WP_Styles->print_inline_style() )

• WP_Scripts->localize() : agrega un objeto codificado json (envuelto por el más "public" función wp_localize_script() )

• wp_plupload_default_settings() : agrega un objeto codificado json (creado a partir de una matriz multidimensional) para el script 'wp-plupload' (tenga en cuenta que esto se publicará en 3.4)

• Al registrar / poner en cola los scripts y estilos Agregar datos para scripts predeterminados ( wp-includes/script-loader.php )

Desde la lectura a través de los usos del método, no parece tener un caso de uso específico. En wp_plupload_default_settings , parece permitir la inyección de datos arbitrarios. En wp_register_script , parece ser usado para diferenciar entre los scripts de encabezado y pie de página. En add_inline_style , se usa para denotar el estilo en línea que debe agregarse después de que se encola una hoja de estilo especificada.

Un uso excelente para esta función sería algo así como el siguiente código en el que está colocando una secuencia de comandos externa, pero necesita enviar algunos valores de configuración, algunos de los cuales provienen de la base de datos:

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' );

Esto resultará en:

<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>

Tenga en cuenta que esto no se puede lograr con wp_localize_script porque el objeto addthis_share tiene propiedades dentro de las propiedades ( Escribí sobre una forma un tanto pirateada de esto antes ).

EDITAR: Me equivoqué al afirmar esto. wp_localize_script maneja matrices multidimensionales muy bien.

Este método parece funcionar realmente bien por las siguientes razones:

1. Le permite adjuntar los datos al identificador de la secuencia de comandos para que siempre esté en cola con la secuencia de comandos. Además, será inteligente en cuanto a la eliminación del enqueque del script, el orden del script y la ubicación del script.
2. Le permite usar PHP para enviar vars a JS.
3. Parece más organizado que el uso de wp_print_styles para imprimir un script arbitrario sobre el que se actúa después mediante un script en cola.

Hay algunas cosas que no funcionan como se esperaba y me preocupan por este método. Uno de esos problemas es que si usa wp_localize_script junto con $wp_scripts->add_data , puede obtener resultados inesperados. Por ejemplo:

// 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' ) );

Produce:

<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>

Considerando este 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 );

Produce:

<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 clave data establecida por wp_localize_script finalmente se sobrescribe con la llamada a $wp_scripts->add_data , mientras que si llama a wp_localize_script dos veces para el mismo script, la cadena se concatenará correctamente.

Si bien todo esto es una forma realmente útil de imprimir un script arbitrario para usarlo con un script en cola, me hace pensar que no debería usarse ampliamente debido a posibles conflictos. Ciertamente puedo ver un argumento para usar esto en proyectos personales donde el código no se usará en complementos / temas de la comunidad.

También miré Core Trac para ver si había alguna pista sobre el propósito de la función. Encontré un ticket (http://core.trac.wordpress.org/ticket/11520) (uno épico) que exploró otras formas de agregar JS arbitrarios. Por lo tanto, parece que hay interés en crear una mejor manera de agregar JS arbitrarios, pero no está seguro de si add_data debería ser parte del proceso.

Mi pregunta principal es: ¿deberían los desarrolladores utilizar esta función? En algunos casos (por ejemplo, wp_register_script ), parece una función "privada" que los terceros no deberían usar; sin embargo, en otros casos (por ejemplo, wp_plupload_default_settings ), parece una forma perfectamente razonable de inyectar JS arbitrarios antes de un script en cola.

No creo que haya una respuesta "correcta" a esto, pero me encantaría escuchar lo que piensan otros desarrolladores. También me imagino que hay piezas en este rompecabezas que he descuidado por completo y me encantaría escuchar lo que otros tienen que decir al respecto.