Share
Conoscere il modo corretto per includere i file JavaScript e CSS nei temi e nei plugin di WordPress è molto importante per i progettisti e gli sviluppatori. Se non aderisci alle migliori pratiche, corri il rischio di entrare in conflitto con altri temi e plug-in e potenzialmente creare problemi che potrebbero essere facilmente evitati. Questo articolo è inteso come riferimento per giocare bene con gli altri.
Prima di iniziare, puoi sfogliare i nostri temi WordPress e WordPress Plugin, se hai bisogno di avviare il tuo prossimo progetto professionalmente.
E se, dopo aver letto questo tutorial, non sei ancora sicuro di come includere i tuoi file JavaScript e CSS nel modo giusto, potrebbe valere la pena di ordinare alcuni dei servizi WordPress disponibili su Envato Studio.
Dall'installazione alla personalizzazione, o anche all'ottimizzazione SEO e velocità, puoi ottenere un esperto WordPress professionista per impostare le cose nel modo giusto dall'inizio.
Se hai mai sviluppato un tema o un plugin per WordPress, o hai lavorato con uno creato da qualcun altro, probabilmente hai trovato diversi metodi per includere JavaScript e CSS. Mentre ci sono diversi metodi che possono sembrare funzionare in una serie specifica di circostanze, c'è un metodo primario raccomandato nel codice WordPress. Questo metodo preferito assicurerà che il tuo tema o plugin funzioni in tutti i casi, assumendo che anche gli altri codifichino il modo corretto.
C'è anche qualche equivoco su cosa dice esattamente il Codex su questo, che aiuterò a chiarire.
Quando scarichi WordPress, è già inclusa una selezione di librerie JavaScript comuni che puoi utilizzare per lo sviluppo di JavaScript. Un elenco di librerie incluse può essere trovato nel codice WordPress wp_enqueue_script articolo.
Tutte queste librerie sono incluse, ma per default WordPress carica solo quelle di cui ha bisogno e solo quando ne ha bisogno nell'amministratore. Se scrivi JavaScript che utilizza una di queste librerie, devi dire a WordPress che lo script ha bisogno prima che la libreria sia caricata.
Alcune delle cose a cui pensare quando stai codificando JavaScript per WordPress sono:
Rispondere a queste domande ti aiuta a sapere cosa devi fare per registrare e caricare il tuo script. Questo viene fatto usando una funzione di WordPress chiamata wp_register_script, ed ecco il suo utilizzo secondo il Codice WordPress:
wp_register_script ($ handle, $ src, $ deps, $ ver, $ in_footer);
Quindi quali sono queste variabili e abbiamo bisogno di loro ogni volta? (Questo è coperto nella pagina del codice, quindi sarò breve e uso l'inglese semplice)
Accentsconagua
$ maniglia - cosa utilizzerai per riferirti a questo particolare script dovunque ti serva per accodarlo, e devi includere questa variabile almeno$ src - il percorso del file sorgente all'interno del tuo plugin o tema$ dipendenze - un array contenente il $ maniglia per ogni altro script che deve essere eseguito dallo script (ad esempio una dipendenza)$ ver - il numero di versione del tuo script, che può essere utilizzato per il busting della cache. Per impostazione predefinita, WordPress utilizzerà il proprio numero di versione come numero di versione per lo script$ in_footer - vuoi che il tuo script venga caricato nel footer? Imposta questo a vero o falso. È falso per impostazione predefinita, quindi carica nell'intestazione dove wp_head () è, e se si specifica vero caricherà dove wp_footer () appare nel temaI browser ricordano quali script e fogli di stile hanno scaricato per un determinato sito in base all'URL dello script e del foglio di stile. Se modifichi l'URL, anche solo aggiungendo una querystring, il browser presume che si tratta di un nuovo file e lo scarica.
Ecco l'esempio più semplice per caricare uno script personalizzato:
function wptuts_scripts_basic () // Registra lo script come questo per un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // or // Registra lo script come questo per un tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // Per un plugin o un tema, puoi accodare lo script: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); Innanzitutto, registriamo lo script, quindi WordPress sa di cosa stiamo parlando. Il modo per trovare il percorso per il nostro file JavaScript è diverso se stiamo codificando un plug-in o un tema, quindi ho incluso esempi di entrambi sopra. Quindi lo accodiamo per essere aggiunti all'HTML per la pagina quando viene generato, per impostazione predefinita in dove il wp_head () è nel tema.
L'output che otteniamo da quell'esempio di base è:
Ora se il tuo script si basa su una delle librerie incluse in WordPress, come jQuery, puoi fare una semplice modifica al codice:
function wptuts_scripts_with_jquery () // Registra lo script come questo per un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // o // Registra lo script come questo per un tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // Per un plugin o un tema, puoi accodare lo script: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_jquery'); Nota: Per impostazione predefinita, jQuery viene caricato con noConflict per evitare interferenze con altre librerie (come Prototype). Vedi la sezione noConflict del Codex se non sai come affrontarlo.
Vedi cosa ho fatto lì? Basta aggiungere una matrice con l'handle 'jquery' come dipendenza. Utilizza un array qui, perché lo script potrebbe avere più dipendenze. Se lo script utilizza l'interfaccia utente jQuery e jQuery, devi aggiungere l'interfaccia utente jQuery al tuo array di dipendenze, ad esempio array ('jquery', 'jquery-ui-core')
Così ora l'output è cambiato e possiamo vedere che jQuery è stato aggiunto anche a della pagina:
Proviamo un esempio con tutte le campane e i fischietti:
function wptuts_scripts_with_the_lot () // Registra lo script come questo per un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery', 'jquery-ui -core '),' 20120208 ', vero); // o // Registra lo script come questo per un tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery', 'jquery-ui-core' ), '20120208', vero); // Per un plugin o un tema, puoi accodare lo script: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_the_lot'); Ok, ora ho aggiunto una versione e specificato che questo script deve essere caricato nel footer. Per il numero di versione, ho scelto di utilizzare la data di oggi perché è facile tenerne traccia, ma puoi usare qualsiasi numerazione di versione che ti piace. Anche l'output per questo è leggermente diverso, jQuery viene emesso nel file e il nostro script insieme all'interfaccia utente di jQuery viene visualizzato poco prima , come questo:
... ... ...
Alcune persone potrebbero preferire di non utilizzare i metodi di accodamento appropriati perché ritengono di avere meno controllo sull'ordine in cui vengono caricati gli script. Ad esempio, in un tema che utilizza modernizr, l'autore del tema potrebbe voler assicurarsi che modernizr venga caricato in anticipo.
Qualcosa che non ho menzionato prima è più dettagliato su come add_action la funzione funziona, poiché è qui che possiamo esercitare un po 'di influenza sull'ordine delle cose. Ecco l'uso della funzione in base alla pagina del codice WordPress:
add_action ($ tag, $ function_to_add, $ priority, $ accepted_args);
Si noti che spesso, e fino ad ora in questo articolo, solo il $ tag e $ function_to_add i parametri sono usati Il $ priorità il parametro è impostato su 10 e il valore $ accepted_args il parametro è impostato su 1. Se vogliamo che i nostri script o stili siano accodati in precedenza, abbassiamo semplicemente il valore per $ priorità dal valore predefinito. Per esempio:
function wptuts_scripts_important () // Registra lo script come questo per un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // or // Registra lo script come questo per un tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js'); // Per un plugin o un tema, puoi accodare lo script: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_important', 5); L'output sarà lo stesso che abbiamo visto in precedenza, ma si verificherà prima nel documento HTML.
Ci possono essere momenti in cui si desidera utilizzare una versione diversa di una libreria inclusa in WordPress. Forse vuoi usare una versione all'avanguardia o non vuoi aspettare la prossima versione di WordPress prima di usare l'ultima versione stabile di jQuery. Un altro motivo potrebbe essere che desideri sfruttare la versione CDN di Google di una libreria.
È importante notare che questo dovrebbe solo essere fatto su plugin o temi utilizzati sui siti che sarete mantenendo personalmente. Eventuali plug-in o temi rilasciati per uso pubblico dovrebbero utilizzare le librerie incluse in WordPress.
"Perché?!", Ho sentito chiederlo. Per la semplice ragione che non controlli questi siti. Non sai quali altri plugin e temi potrebbero essere utilizzati lì e non sai quanto spesso aggiorneranno il tuo plugin o tema. L'utilizzo delle librerie fornite con WordPress è l'opzione più sicura.
Detto questo, se vuoi farlo su un sito che controlli, ecco come è fatto:
function wptuts_scripts_load_cdn () // Annulla la registrazione della libreria inclusa wp_deregister_script ('jquery'); // Registra nuovamente la libreria dal CDN di Google wp_register_script ('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array (), null, false ); // Registra lo script come questo per un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // o // Registra lo script come questo per un tema: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // Per un plugin o un tema, puoi accodare lo script: wp_enqueue_script ('custom-script'); add_action ('wp_enqueue_scripts', 'wptuts_scripts_load_cdn'); Quindi, prima di tutto, ho cancellato la versione inclusa della libreria, altrimenti potrebbero essere introdotti conflitti tra diverse versioni. Quindi registra la versione alternativa, usando lo stesso handle, e ho scelto di specificare null come versione (è già presente nell'URL!) E specificato non nel footer. Il resto del nostro codice è lo stesso, perché dipendevamo da qualunque script usato dall'handle 'jquery'. L'output che otteniamo ora sembra:
Nota: Uno dei motivi per cui questa è una cattiva idea da fare in un plugin o in un tema per la pubblicazione pubblica, è che tutti gli altri plugin e temi utilizzati su questo sito ora dovranno usare questa versione di jQuery. Inoltre, la versione appena registrata di jQuery non ha impostato noConflict, quindi se qualsiasi altro plug-in o script a tema usa Prototype per esempio, questo spezzerà le cose.
Finora non abbiamo menzionato nulla su come fare tutto questo nell'amministratore, solo sul front-end. La differenza principale è quale azione utilizzare. Invece di add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); che usiamo per il front-end, l'azione per l'amministratore è add_action ('admin_enqueue_scripts', 'wptuts_scripts_basic');
Qualcosa che è importante fare sia per il front-end che per l'amministratore è essere selettivi su quali pagine si caricano gli script. Se il tuo plugin o tema ha uno script che fa qualcosa solo su una pagina di front-end o di amministrazione, come la pagina delle opzioni del tema, o magari una pagina con un widget specifico, devi solo caricare il tuo script su quella pagina. Non è necessario bloccare le cose e caricare script nelle pagine in cui non vengono utilizzati!
C'è un ottimo esempio nel codice WordPress su come caricare gli script solo sulle pagine dei plugin. Poiché i plug-in e i temi possono variare molto nel modo in cui sono scritti, qui non andrò nei dettagli su come essere esigente riguardo a quali pagine vengono caricati gli script, ma era importante menzionarlo in modo che tu ne sia a conoscenza quando stai codificando.
Il processo per gli stili è quasi identico al processo per gli script. È fatto usando una funzione di WordPress chiamata wp_register_style, ed ecco il suo utilizzo secondo il Codice WordPress:
wp_register_style ($ handle, $ src, $ deps, $ ver, $ media);
Si noti che l'unica differenza tra wp_register_script e wp_register_style è quello invece di un $ in_footer parametro, abbiamo a $ supporti parametro. Questo parametro può essere impostato su uno dei seguenti: 'tutti', 'schermo', 'Tenuto in mano', e 'stampare', o qualsiasi altro tipo di supporto riconosciuto W3C.
Quindi un esempio di come si potrebbe accodare uno stile potrebbe essere:
function wptuts_styles_with_the_lot () // Registra lo stile come questo per un plugin: wp_register_style ('custom-style', plugins_url ('/css/custom-style.css', __FILE__), array (), '20120208', 'all '); // o // Registra lo stile come questo per un tema: wp_register_style ('custom-style', get_template_directory_uri (). '/css/custom-style.css', array (), '20120208', 'all'); // Per un plugin o un tema, puoi accodare lo stile: wp_enqueue_style ('custom-style'); add_action ('wp_enqueue_scripts', 'wptuts_styles_with_the_lot'); Questo è un esempio abbastanza completo, che utilizza la maggior parte dei parametri e l'output che produce è simile a:
Bella domanda, e l'altra domanda che potrei chiedere è: "Cosa ti fa pensare che questo sia il modo giusto e non solo le tue preferenze?". Essenzialmente la risposta è che questo è l'approccio raccomandato da WordPress. Assicura che qualsiasi combinazione di plugin e temi dovrebbe essere in grado di lavorare insieme felicemente e senza raddoppiare.
Ho visto alcuni temi e strutture intorno al luogo che uso e tag nei loro header.php, e persino footer.php, file per caricare script e stili per il tema stesso. Non c'è davvero nessuna ragione per fare le cose in questo modo. Come ho dimostrato sopra, è perfettamente possibile dare la priorità agli script e agli stili e nominare se caricano nell'intestazione o nel piè di pagina dal comfort e dalla sicurezza del tuo functions.php. Il vantaggio è che il tuo tema / framework funzionerà con una gamma più ampia di altri plugin / temi figlio.
Un esempio stava caricando jQuery usando il tag, che potrebbero sembrare funzionare bene, ma questo può effettivamente causare il caricamento di jQuery due volte! Caricare jQuery in questo modo non impedirà a WordPress di caricare la sua versione di jQuery per altri plugin, poiché la versione di WordPress è in modalità noConflict per impostazione predefinita e un plug-in potrebbe specificarlo come dipendenza. Quindi ora jQuery funzionerà sia per la modalità noConflict che per $, e probabilmente anche rompere qualsiasi plugin che usi la libreria Prototype.
WordPress è un sistema fantastico, ed è stato sviluppato con molto pensiero. Se c'è un meccanismo reso disponibile per fare qualcosa, è spesso una buona idea usarlo. Quando sviluppi i tuoi plug-in e temi, prova a ricordare di scrivere il codice in modo accurato e di giocare bene con gli altri.
Cosa ne pensi dell'uso di wp_enqueue_script e le sue funzioni e azioni associate? Conoscete qualche esempio in cui viene fatto in modo errato? Conosci qualche motivo per non seguire il consiglio di cui sopra?
Se hai bisogno di una soluzione già pronta, puoi navigare tra i nostri temi Wordpress e Wordpress Plugin su Envato Market.
