All'interno della WP_Dependenciesclasse esiste un metodo chiamato add_data. Questa funzione aggiunge dati a script / stili accodati durante il caricamento di WordPress. Un uso comunemente citato per questa funzione è quello di aggiungere un condizionale quando si aggiungono fogli di stile destinati a diverse versioni di IE. Ad esempio, per scegliere come target IE8 e versioni precedenti:
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' );Questo renderà come:
<!--[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]--> Quando guardo attraverso Core, vedo una manciata di luoghi in cui viene utilizzato questo metodo:
WP_Styles->add_inline_style(): aggiunge lo stile in linea dopo il foglio di stile di riferimento (fatto tramiteWP_Styles->print_inline_style())WP_Scripts->localize(): aggiunge un oggetto codificato JSON (racchiuso dalla funzione più "pubblica"wp_localize_script())wp_plupload_default_settings(): aggiunge un oggetto con codifica json (creato da un array multidimensionale) per lo script 'wp-plupload' (si noti che questo è in arrivo in 3.4)Quando si registrano / accodano script e stili Aggiunta di dati per script predefiniti (
wp-includes/script-loader.php)
Dalla lettura agli usi del metodo, non sembra avere un caso d'uso specifico. In wp_plupload_default_settings, sembra consentire l'inserimento di dati arbitrari. In wp_register_script, sembra essere usato per distinguere tra script di intestazione e piè di pagina. In add_inline_style, viene utilizzato per indicare lo stile in linea che deve essere aggiunto dopo l'accodamento di un foglio di stile specificato.
Un uso eccellente di questa funzione sarebbe qualcosa di simile al seguente codice in cui si sta accodando uno script esterno ma è necessario inviargli alcune configurazioni, alcune delle quali provengono dal 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' );Ciò comporterà:
<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>Si noti che ciò non può essere realizzato wp_localize_scriptperché l' addthis_shareoggetto ha proprietà all'interno delle proprietà (in precedenza ho già scritto un modo un po 'confuso ).
EDIT: ho sbagliato a dichiararlo. wp_localize_scriptgestisce bene le matrici multidimensionali.
Questo metodo sembra funzionare davvero bene per i seguenti motivi:
- Ti consente di allegare i dati all'handle dello script in modo che siano sempre correttamente corretti con lo script. Inoltre, sarà intelligente deenqueueing dello script, ordine degli script e posizionamento degli script.
- Ti permette di usare PHP per inviare vars a JS.
- Sembra più organizzato che usare
wp_print_stylesper stampare qualche sceneggiatura arbitraria che viene successivamente interpretata da una sceneggiatura accodata.
Ci sono alcune cose che non funzionano come previsto e che mi preoccupano per questo metodo. Uno di questi problemi è che se lo usi wp_localize_scriptinsieme $wp_scripts->add_data, puoi ottenere risultati inaspettati. Per esempio:
// 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 che questo 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 datachiave impostata da wp_localize_scriptviene infine sovrascritta dalla chiamata a $wp_scripts->add_data, mentre se si chiama wp_localize_scriptdue volte per lo stesso script, la stringa verrà concatenata correttamente.
Sebbene tutto ciò sia un modo davvero utile per stampare script arbitrari da usare con uno script accodato, mi fa pensare che non dovrebbe essere ampiamente usato a causa del potenziale di conflitti. Sicuramente vedo un argomento per usarlo in progetti personali in cui il codice non verrà utilizzato nei plugin / temi della community.
Ho anche guardato Core Trac per vedere se c'erano indizi sullo scopo della funzione. Ho trovato un biglietto (http://core.trac.wordpress.org/ticket/11520) (uno epico in quello) che ha esplorato altri modi per aggiungere JS arbitrario. Quindi sembra che ci sia interesse a creare un modo migliore per aggiungere JS arbitrari, ma non sono sicuro esattamente se add_datadovrebbe far parte del processo.
La mia domanda principale è: gli sviluppatori dovrebbero usare questa funzione? In alcuni casi (ad es. wp_register_script), Sembra una funzione "privata" che terze parti non dovrebbero usare; tuttavia, in altri casi (ad es. wp_plupload_default_settings), sembra un modo perfettamente ragionevole per iniettare JS arbitrario prima di uno script accodato.
Non immagino che ci sia una risposta "corretta" a questo, ma mi piacerebbe sentire cosa pensano gli altri sviluppatori. Immagino anche che ci siano pezzi di questo puzzle che ho completamente ignorato e mi piacerebbe sentire ciò che gli altri hanno da dire al riguardo.