W WP_Dependenciesklasie istnieje metoda o nazwie add_data. Ta funkcja dodaje dane do skryptów / stylów, które zostały umieszczone w kolejce podczas ładowania WordPress. Często cytowanym zastosowaniem tej funkcji jest dodanie warunkowego przy dodawaniu arkuszy stylów, które są skierowane do różnych wersji IE. Na przykład, aby kierować na IE8 i niższe:
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' );
Będzie to renderowane jako:
<!--[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]-->
Kiedy przeglądam Core, widzę garść miejsc, w których ta metoda jest używana:
WP_Styles->add_inline_style(): dodaje styl wbudowany po arkuszu stylów, do którego się odwołuje (wykonane przezWP_Styles->print_inline_style())WP_Scripts->localize(): dodaje obiekt zakodowany w formacie json (zawinięty przez bardziej „publiczną”wp_localize_script()funkcję)wp_plupload_default_settings(): dodaje obiekt zakodowany w formacie json (utworzony z tablicy wielowymiarowej) dla skryptu „wp-plupload” (zauważ, że będzie to dostępne w 3.4)Podczas rejestrowania / kolejkowania skryptów i stylów Dodawanie danych dla domyślnych skryptów (
wp-includes/script-loader.php)
Po przeczytaniu zastosowania tej metody nie wydaje się, aby miała określony przypadek użycia. W wp_plupload_default_settings, wydaje się, aby umożliwić wstrzyknięcie dowolnego danych. W wp_register_scriptwydaje się być wykorzystywane do rozróżniania skrypty nagłówka i stopki. W add_inline_stylesłuży do oznaczenia stylu wbudowanego, który należy dodać po kolejkowaniu określonego arkusza stylów.
Doskonałym zastosowaniem tej funkcji byłby coś w rodzaju następującego kodu, w którym kolejkujesz zewnętrzny skrypt, ale musisz wysłać mu kilka zmiennych konfiguracyjnych, z których niektóre pochodzą z bazy danych:
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' );
Spowoduje to:
<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>
Zauważ, że nie można tego osiągnąć, wp_localize_scriptponieważ addthis_shareobiekt ma właściwości we właściwościach ( wcześniej pisałem o tym nieco pospiesznym obejściu ).
EDYCJA: Myliłem się, stwierdzając to. wp_localize_scriptdobrze sobie radzi z tablicami wielowymiarowymi.
Ta metoda wydaje się działać naprawdę dobrze z następujących powodów:
- Pozwala na dołączenie danych do uchwytu skryptu, dzięki czemu jest zawsze odpowiednio kolejkowane w skrypcie. Co więcej, będzie inteligentna w zakresie usuwania kolejki skryptu, kolejności i umiejscowienia skryptu.
- Pozwala używać PHP do wysyłania varsów do JS.
- Wydaje się, że jest to bardziej zorganizowane niż używanie
wp_print_stylesdo drukowania dowolnego skryptu, na który działa później skrypt w kolejce.
Są pewne rzeczy, które nie działają zgodnie z oczekiwaniami, co martwi mnie o tę metodę. Jednym z takich problemów jest to, że jeśli używasz wp_localize_scriptrazem $wp_scripts->add_data, możesz uzyskać nieoczekiwane wyniki. Na przykład:
// 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' ) );
Produkuje:
<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>
Podczas gdy ten skrypt:
// 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 );
Produkuje:
<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>
dataKluczem, który jest ustalany przez wp_localize_scriptostatecznie zastępowane przez wywołanie $wp_scripts->add_data, natomiast jeśli zadzwonić wp_localize_scriptdwa razy w tym samym skrypcie, ciąg będzie prawidłowo łączone.
Chociaż wszystko to jest naprawdę przydatnym sposobem drukowania dowolnego skryptu do użycia z kolejkowanym skryptem, sprawia, że myślę, że nie powinien być szeroko stosowany ze względu na potencjał konfliktów. Z pewnością widzę argument za użyciem tego w projektach osobistych, w których kod nie będzie używany we wtyczkach / motywach społeczności.
Spojrzałem również na Core Trac, aby sprawdzić, czy istnieją jakieś wskazówki co do celu tej funkcji. Znalazłem jeden bilet (http://core.trac.wordpress.org/ticket/11520) (epicki jeden), który badał inne sposoby dodawania dowolnego JS. Wydaje się więc, że istnieje interes w stworzeniu lepszego sposobu dodawania dowolnego JS, ale nie jestem pewien, czy add_datapowinien być częścią tego procesu.
Moje główne pytanie brzmi: czy programiści powinni korzystać z tej funkcji? W niektórych przypadkach (np. wp_register_script) Wydaje się, że jest to funkcja „prywatna”, z której nie powinny korzystać osoby trzecie; jednak w innych przypadkach (np. wp_plupload_default_settings) wydaje się to całkowicie rozsądnym sposobem wstrzyknięcia dowolnego JS przed kolejkowanym skryptem.
Nie sądzę, że istnieje „poprawna” odpowiedź na to pytanie, ale chciałbym usłyszeć, co myślą inni twórcy. Wyobrażam sobie również, że w tej układance są elementy, które całkowicie zaniedbałem i chciałbym usłyszeć, co mają do powiedzenia inni.