jQuery come sai è una libreria javascript molto potente che ti consente di poter creare effetti e non solo sul tuo template quasi scrivendo “due righe” di codice proprio come decanta lo slogan: ” Write less do more” (scrivi poco fai molto), anche se in realtà quando ti fai prendere la mano ne scrivi anche più di due :-P, vediamo comunque come usarlo correttamente con WordPress:
Come richiamare jQuery correttamente in un nuovo progetto
Il modo classico per caricare gli script js in un documento HTML è quello di inserire il tag <script type='text/javascript'></script> con la url di dove è situato il file:
<script type='text/javascript' src='miosito.com/js/jquery.js'></script>
WordPress però ci mette a disposizione alcuni strumenti molto utili e potenti allo stesso tempo che ci consentono di poter implementare jQuery nel nostro template o plugin non nel modo tradizionale inserendo il tag script all’interno del codice html ma utilizzando alcune funzioni dedicate che avranno il compito di effettuare un controllo su eventuali dipendenze di jQuery e poter quindi caricare nel giusto ordine tutti i vari file js all’interno del nostro template.
Devi sapere prima di procedere che WordPress ha una versione di jQuery inserita nel core già pronta per essere utilizzata (di solito è abbastanza aggiornata all’ultima versione stabile di jquery, ma non sempre 😉 ), e per caricarla correttamente dovremo inserire questa funzione nel file functions.php del template che stiamo utilizzando:
function italystrap_add_jquery() {
wp_enqueue_script('jquery');
}
add_action('wp_enqueue_scripts', 'italystrap_add_jquery');
Vediamo però come caricare il file dalla CDN di google.
Per usare la CDN di Google ci sono tre procedure da eseguire in cascata, la prima sarà deregistrare la versione utilizzata da WordPress, la seconda registrare quella presente sulla CDN di Google e la terza includere il la versione appena registrata, il tutto con questa funzione:
function italystrap_add_jquery_googlecdn(){
wp_deregister_script('jquery');
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js', false, null, true);
wp_enqueue_script('jquery');
}
add_action( 'wp_enqueue_scripts', 'italystrap_add_jquery_googlecdn' );
Come hai potuto notare ho utilizzato l’ hook wp_enqueue_scripts che provvederà a caricare jQuery solo nel front-end del sito.
Più avanti parlerò meglio dei tag condizionali per una migliore ottimizzazione di caricamento degli script.
Breve spiegazione su wp_enqueue_script e wp_register_script
wp_enqueue_script() e wp_register_script() sono molto simili come funzionamento, entrambe le funzioni accettano gli stessi 5 parametri, anche se ad un primo impatto possono sembrare quasi uguali svolgono invece ruoli differenti, wp_register_script() ha il compito di “registrare” il file js “in memoria” in modo da poterlo richiamare in ogni momento con la funzione wp_enqueue_script('$handle') passandogli solo il parametro con il nome ($handle) del file da caricare, senza di essa nel file HTML non verrebbe inserito nulla.
Al contrario la funzione wp_enqueue_script() può svolgere il compito di caricare il file js anche senza registrarlo precedentemente (a patto che sia sullo stesso server del sito), passandogli anche il parametro $src ovvero la posizione di dov’è ubicato il file.
wp_enqueue_script( $handle, $src );
wp_enqueue_script(), inoltre, se dichiarata la dipendenza esso farà caricare nell’HTML della pagina anche i file js forniti nel core di WordPress già preregistrati al caricamento del core:
wp_enqueue_script( 'mio-script', $src, array('jquery','scriptaculous'), $ver, $in_footer );
In questo caso verrebbe caricato sia jquey che scriptaculous con wp_head() (ovviamente questi devono già essere stati preregistrati altrimenti dovrai registrarli tu con la funzione apposita, qui trovi la lista di tutti quelli presenti con WordPress)
Ora ti starai chiedendo: “Ma allora, quale delle due devo usare?”
Non c’è un modo migliore di un altro, dipende dallo sviluppatore com’è abituato, io per esempio se devo caricare file esterni al server (cdn o altro) uso la funzione wp_register_script() e quindi wp_enqueue_script() come spiegato sopra (solo con l’ultima ho visto che i file esterni non vengono caricati) e invece per caricare i file già presenti sul mio sul server uso solo wp_enqueue_script() (come puoi vedere qui).
Vediamo in dettaglio i vari parametri che è possibile utilizzare:
wp_register_script( $handle, $src, $deps, $ver, $in_footer ); wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
$handle= Nome da associare allo script (può essere una stringa – richiesto)$src= URL dello script (può essere una stringa – opzionale)$deps= Se il file non dipende da nessuno allora inserirefalsealtrimenti inserire il nome dello script da caricare prima (vedi$handle) (Può essere unarray( '$handle01' , '$handle02')– opzionale )$ver= La versione del file (io solitamente mettonullper evitare problemi di cache) (può essere una stringa – opzionale)$in_footer= Questa è la mia preferita ;-), inserendotruecaricherà lo script nel footer prima della chiusura di body (Chicca per velocizzare il rendering della pagina – opzionale).
Come risolvere il problema in caso non sia disponibile la CDN di google
Mettiamo il caso (molto remoto direi) che la CDN di google sia momentaneamente non accessibile nel momento in cui venga richiesta la risorsa (sembra strano ma può succedere ;-)), come possiamo fare?
La soluzione potrebbe essere inserire questo snippet nel nostro codice HTML (ovviamente nel footer ;-)) dove indicheremo al browser di caricare jQuery da un cartella nel nostro server in caso la CDN non sia ragiungibile:
<script>window.jQuery || document.write('<script src="mia url della cartella di jQuery/js/jquery-1.10.2.min.js"></script>')</script>
Ma ovviamente noi lavoriamo con WordPress e come tutti i vari script questi hanno bisogno di essere caricati in sequenza rispettando le varie dipendenze per evitare il mancato funzionamento di qualche plugin che utilizza jQuery, grazie a questa funzione lo snippet precedente verrà caricato proprio dopo la CDN e prima degli altri script-“figli”:
function italystrap_jquery_local_fallback($src, $handle = null){
static $add_jquery_fallback = false;
if ($add_jquery_fallback) {
echo '<script>window.jQuery || document.write('<script src="' . get_template_directory_uri() . '/js/jquery-1.10.2.min.js"></script>')</script>' . "n";
$add_jquery_fallback = false;
}
if ($handle === 'jquery') {
$add_jquery_fallback = true;
}
return $src;
}
add_action( 'wp_footer', 'italystrap_jquery_local_fallback' );
(Qui trovi il file con la funzione)
(Soluzione adottata anche dal template Roots)
Caricare gli script solo dove necessario
Mettiamo il caso in cui stiamo utilizzando uno script per creare una slide solo in home page, come puoi ben immaginare sarà inutile caricarlo in tutte le altre pagine poiché potrebbe inficiare sulle performance del resto del sito, meno files facciamo caricare per le varie pagine più veloce sarà il download della risorsa e di conseguenza sarà più veloce anche il rendering e il painting della risorsa stessa, per evitare questo utilizzeremo i tag condizionali di WordPress.
I tag condizionali ci consentono di effettuare operazioni in determinate circostanze e non in altre, per esempio appunto evitare di caricare script in pagine dove effettivamente non ci servono (ovviamene ci consentono di fare molto di più, ad ogni modo ti rimando alla pagina dedicata sul codex per avere maggiori informazioni).
Ora vediamo come risolvere il problema posto prima, evitare che lo script della slide in home page venga caricato in tutte le altre pagine, per fare questo semplicemente creiamo una if in cui diciamo appunto di caricarlo solo in home:
if ( is_home() || is_front_page() ){
//Registra il mio script
}
Oppure possiamo caricarlo ovunque ma non in home page:
if ( !is_home() || !is_front_page() ){
//Registra il mio script
}
Ovviamente possiamo anche decidere di caricare script solo negli articoli (is_single()), solo nelle pagine (is_page()), nelle categorie, tag ecc (per conoscere meglio i tag condizionali vai alla pagina dedicata sul codex), insomma, il limite è solo la fantasia 😉
Caricare gli script anche nel back-end
Come hai potuto vedere nei vari snippets precedenti le funzioni create sono state “agganciate”, grazie alla funzione add_action(), al rispettivo hook wp_enqueue_script, questo ci consente di poter caricare i file nel front-end del sito, ma nel caso tu abbia bisogno di caricare qualche file nel pannello admin o nel login del sito ecco qui una piccola lista con rispettivo link al codex:
- Front-End: wp_enqueue_scripts
- Admin: admin_enqueue_scripts
- Login: login_enqueue_scripts
Come scrivere codice jquery funzionante
Ora che abbiamo caricato correttamente la libreria jquery vediamo come scrivere il codice che andremo ad utilizzare nel nostro progetto.
Ti consiglio di creare un file js dove inserire il tuo codice personale che potresti chiamare per esempio custom.js e caricarlo nel template come hai appena letto precedentemente ricordandoti di inserire la dipendenza per jQuery, jQuery essendo un file abbastanza corposo preferisco sempre lasciarlo da solo e accoppiarlo con un secondo file ove inserisco il mio codice personalizzato, anche se questo comporta una richiesta HTTP aggiuntiva rende più veloce il download dei file poiché entrambi sono di dimensioni “accettabili”, molto meglio caricare due file di 100K (che verranno scaricati in parallelo o quasi) che uno unico da 200K (essendo più grande impiegherebbe il doppio del tempo rispetto al file da 100K).
La pratica più comune per chi ha già utilizzato jQuery su qualsiasi file html sarebbe quella di inserire il codice in questo modo:
$(document).ready(function() {
jQuery(#somefunction) ...
});
Purtroppo però questo non funzionerà poiché la funzione $() è già utilizzata e quindi andrà in conflitto restituendo questo errore:
Per fortuna però che il simbolo del dollaro è solo l’alias di jQuery e quindi in pratica basta cambiare lo snippet in questo modo per farlo funzionare:
jQuery(document).ready(function(){
jQuery(#somefunction) ...
});
L’unica pecca è che dovremo scrivere sempre jQuery per esteso anche all’interno di document.ready:
jQuery(document).ready( function() {
jQuery(".site-description").hide("slow");
});
Procedura un po’ scomoda (per quelli pigri come me :-P) specialmente quando abbiamo funzioni complesse e dobbiamo scrivere molto codice, quindi se volessimo continuare ad usare il simobolo $ questo snippet fa al caso nostro:
jQuery(document).ready(function($) {
$(".site-description").hide("slow");
});
L’unica pecca è che $ funzionerà si come alias di jQuery() ma non funzionerà più come alias per le altre librerie.
Nel caso in cui abbiamo bisogno di eseguire il codice prima che il DOM sia interamente costruito (document.ready) allora possiamo usare questo snippet:
(function($) {
$(".site-description").hide("slow");
})(jQuery);
Come nello snippet precedente anche in questo caso $ sarà utilizzabile all’interno della funzione ma non sarà più disponibile per le altre librerie.
Questo esempio invece assegna alla variabile $j la funzione jQuery():
var $j = jQuery;
$j(document).ready(function(){
$j('.wrapper').hide();
});
Così possiamo mantenere libero $ per altre librerie e scrivere codice più pulito
Possiamo fare ancora meglio, vediamo lo snippet precedente con l’itroduzione della funzione noConflict() ideata apposta per evitare conflitti con altre librerie:
var $j = jQuery.noConflict();
$j(document).ready(function(){
$j(".site-description").hide("slow");
});
E se volessimo usare l’alias nativo $ insieme a noConflict()? Ecco uno snippet che risolve questo problema:
jQuery.noConflict();
jQuery(document).ready(function($){
$(".site-description").hide("slow");
});
Ora ottimizziamo ancora lo snippet facendo un mix delle tecniche viste fin’ora:
jQuery.noConflict()(function($){
"use strict";
$(document).ready(function() {
alert('alert');
});
});
Quest’ultimo è anche il metodo che utilizzo io nei miei progetti ed è quello secondo me più pratico e veloce da scrivere (con un bel copia ed incolla ovviamente :-P).
Prima di concludere, hai visto che ho inserito "use strict"; all’interno della mia funzione? Se ti stai chiedendo a cosa serva questa stringa posso dirti che il suo utilizzo è quello di poter scovare errori che solitamente non verrebbero rilevati dal debugger del browser, insomma, una buona scusa per scrivere codice migliore :-).
Ad ogni modo se vuoi approfondire qui un articolo in inglese e qui una guida più completa con tanto di esempi.
Per il momento è tutto e se hai dubbi di qualunque genere oppure sei uno sviluppatore e conosci modi migliori di fare le cose spiegate in questa guida il tuo commento è il benvenuto :-).
Lascia un commento