Jedna dodatkowa opcja, w zależności od rodzaju parametrów, które należy przekazać. Nazwijmy to (2a). Możesz także tworzyć skrypty PHP, które generują dane generowane dynamicznie text/csslub text/javascriptraczej text/htmli dostarczać im danych, których potrzebują, używając parametrów GET zamiast ładować WordPress. Oczywiście działa to tylko wtedy, gdy trzeba przekazać stosunkowo niewielką liczbę stosunkowo zwartych parametrów. Powiedzmy na przykład, że musisz podać tylko adres URL wpisu lub katalog pliku lub podobny, możesz zrobić coś takiego:
W header.php:
<script type="text/javascript" src="<?php print get_stylesheet_directory_uri();
?>/fancy-js.php?foo=bar&url=<?php print urlencode(get_permalink($post->ID)); ?>"></script>
W fancy-js.php:
<?php
header("Content-type: text/javascript");
?>
foo = <?php print json_encode($_GET['foo']); ?>;
url = <?php print json_encode($_GET['url']); ?>;
itp.
Ale to pozwala tylko na dostęp do danych przekazywanych bezpośrednio w parametrach GET; i zadziała tylko wtedy, gdy liczba rzeczy, które musisz przekazać, jest stosunkowo niewielka, a reprezentacja tych rzeczy stosunkowo niewielka. (Zasadniczo garść wartości łańcuchowych lub liczbowych - nazwa użytkownika, powiedzmy lub katalog; nie lista wszystkich ostatnich postów użytkownika lub coś podobnego.)
Co do tego, która z tych opcji jest najlepsza - nie wiem; zależy to od przypadku użycia. Opcja (1) ma tę zaletę, że jest prosta i wyraźnie umożliwia dostęp do dowolnych danych WordPress, których możesz potrzebować, bez pogorszenia wydajności w przypadku dwukrotnego ładowania WordPress. Jest prawie na pewno to, co powinieneś zrobić, chyba że masz silny powód, aby tego nie robić (np. Ze względu na rozmiar arkusza stylów lub skryptu, którego musisz użyć).
Jeśli rozmiar staje się wystarczająco duży, aby spowodować problem z wagą jednej strony, możesz wypróbować (2) lub (2a).
Albo też - prawdopodobnie jest to lepszy pomysł - możesz spróbować oddzielić części skryptu lub arkusza stylów, które faktycznie wykorzystują dane dynamiczne od części, które można określić statycznie. Powiedzmy, że masz arkusz stylów, który należy przekazać do katalogu z WordPress, aby ustawić parametr tła dla elementu # my-fancy. Możesz to wszystko umieścić w elemencie head:
<style type="text/css">
#my-fancy-element {
background-image: url(<?php print get_stylesheet_directory_uri(); ?>images/fancy.png);
padding: 20px;
margin: 20px;
font-weight: bold;
text-transform: uppercase;
font-size: 12pt;
/* ... KB and KB of additional styles ... */
}
#another-fancy-element {
/* ... KB and KB of additional styles ... */
}
/* ... KB and KB of additional styles ... */
</style>
Ale dlaczego miałbyś to robić? Jest tylko jedna linia, która zależy od danych z WordPress. Lepiej rozdzielić tylko linie zależne od WordPressa:
<style type="text/css">
#my-fancy-element {
background-image: url(<?php print get_stylesheet_directory_uri(); ?>images/fancy.png);
}
</style>
Umieść wszystko inne w statycznym arkuszu stylów, który ładujesz za pomocą standardowego elementu łącza (style.css lub cokolwiek innego):
#my-fancy-element {
/* background-image provided dynamically */
padding: 20px;
margin: 20px;
font-weight: bold;
text-transform: uppercase;
font-size: 12pt;
/* ... KB and KB of additional styles ... */
}
#another-fancy-element {
/* ... KB and KB of additional styles ... */
}
/* ... KB and KB of additional styles ... */
I niech kaskada wykona pracę.
To samo dotyczy JavaScript: zamiast tego:
<script type="text/javascript">
// Here comes a huge function that uses WordPress data:
function my_huge_function () {
// Do a million things ...
jQuery('#my-fancy').append('<a href="'+<?php json_encode(get_permalink($GLOBALS['post']->ID)); ?>+'">foo</a>);
// Do a million more things ...
my_other_function(<?php print json_encode(get_userdata($GLOBALS['post']->post_author); ?>);
}
function my_other_function (user) {
// Do a million things ...
}
</script>
Zamiast tego umieść coś takiego w elemencie head:
<script type="text/javascript">
var WordPressPostData = {
url: <?php print json_encode(get_permalink($GLOBALS['post']->ID)); ?>,
author: <?php print json_encode(get_userdata($GLOBALS['post']->post_author)); ?>
}
</script>
A następnie upuść resztę do statycznego pliku JavaScript, przepisując my_huge_function () i my_other_function (), aby skorzystać z globalnych WordPressPostData.url i WordPressPostData.author.
40 KB CSS lub 40 KB JS można prawie zawsze podzielić na <1 KB, który faktycznie zależy od danych dynamicznych, a resztę można określić w statycznym pliku zewnętrznym, a następnie zrekombinować za pomocą kaskady (dla CSS) lub globalnie dostępnej zmienne (globalne, elementy DOM lub cokolwiek innego preferowanego przedziału dla JS).