Dentro de la WP_Dependenciesclase 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 que están dirigidas a diferentes versiones de IE. Por ejemplo, para apuntar a IE8 y versiones inferiores:
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 representará 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 estilo en línea después de la hoja de estilo referenciada (hecho a través deWP_Styles->print_inline_style())WP_Scripts->localize(): agrega un objeto codificado json (envuelto por la función más "pública"wp_localize_script())wp_plupload_default_settings(): agrega el 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 secuencias de comandos y estilos Agregar datos para secuencias de comandos predeterminadas (
wp-includes/script-loader.php)
Al leer los usos del método, no parece tener un caso de uso específico. En wp_plupload_default_settings, parece permitir la inyección arbitraria de datos. En wp_register_script, parece ser utilizado para diferenciar entre scripts de encabezado y pie de página. En add_inline_style, se usa para denotar el estilo en línea que se debe agregar después de que se encola una hoja de estilo especificada.
Un uso excelente para esta función sería algo como el siguiente código en el que está poniendo en cola un script externo pero necesita enviarle algunos valores de configuración, algunos de los cuales provienen del DB:
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 wp_localize_scriptporque el addthis_shareobjeto tiene propiedades dentro de las propiedades ( antes escribí sobre una forma un tanto extraña ).
EDITAR: Me equivoqué al afirmar esto. wp_localize_scriptmaneja arreglos multidimensionales muy bien.
Este método parece funcionar realmente bien por las siguientes razones:
- Le permite adjuntar los datos al identificador del script para que siempre se coloque correctamente en cola con el script. Además, será inteligente acerca de la desconexión del guión, el orden del guión y la colocación del guión.
- Le permite usar PHP para enviar vars a JS.
- Parece más organizado que usar
wp_print_stylespara imprimir un guión arbitrario sobre el que actúa un guión en cola.
Hay algunas cosas que no funcionan como se esperaba que me preocupa sobre este método. Uno de esos problemas es que si usa wp_localize_scriptjunto 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>
Mientras que 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 dataclave establecida por wp_localize_scriptfinalmente se sobrescribe con la llamada a $wp_scripts->add_data, mientras que si llama wp_localize_scriptdos veces para el mismo script, la cadena se concatenará correctamente.
Si bien todo esto es una forma realmente práctica de imprimir guiones arbitrarios para usar con un guión en cola, me hace pensar que no debería usarse ampliamente debido a la posibilidad de 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é a Core Trac para ver si había alguna pista sobre el propósito de la función. Encontré un boleto (http://core.trac.wordpress.org/ticket/11520) (uno épico) que exploró otras formas de agregar JS arbitrario. Por lo tanto, parece que hay interés en crear una mejor manera de agregar JS arbitrario, pero no estoy seguro exactamente si add_datadebería ser parte del proceso.
Mi pregunta principal es: ¿deberían los desarrolladores usar esta función? En algunos casos (p. Ej. wp_register_script), Parece una función "privada" que terceros no deberían usar; sin embargo, en otros casos (p. ej. wp_plupload_default_settings), parece una forma perfectamente razonable de inyectar JS arbitrario antes de un script en cola.
No me imagino que haya una respuesta "correcta" a esto, pero me encantaría escuchar lo que piensan otros desarrolladores. También 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.