Cum să includem JavaScript și CSS în temele și pluginurile WordPress

Cunoașterea modului potrivit de a include fișiere JavaScript și CSS în temele și pluginurile WordPress este foarte importantă pentru designeri și dezvoltatori. Dacă nu respectați cele mai bune practici, riscați să vă confruntați cu alte teme și pluginuri și, eventual, să creați probleme care ar fi putut fi evitate cu ușurință. Acest articol este destinat ca o referință pentru a juca frumos cu alții.

Înainte de a începe, puteți naviga prin WordPress Themes și WordPress Plugin-uri, dacă aveți nevoie să începeți imediat următorul proiect profesional.

Și dacă, după ce ați citit acest tutorial, încă nu sunteți sigur cum să includeți fișierele JavaScript și CSS în mod corect, ar putea fi util să comandați unele dintre serviciile WordPress disponibile pe Envato Studio.

De la instalare la personalizare, sau chiar SEO și optimizarea vitezei, puteți obține un expert WordPress profesionist pentru a stabili lucrurile în direcția corectă de la început.

Cele mai bune practici fac toată lumea fericită

Dacă ați dezvoltat vreodată o temă sau un plugin pentru WordPress sau ați lucrat cu unul pe care altcineva l-ați creat, probabil că ați întâlnit mai multe metode diferite pentru includerea JavaScript și CSS. Deși există mai multe metode care pot apărea să funcționeze într-un anumit set de circumstanțe, există o metodă primară recomandată în Codul WordPress. Acest mod preferat va asigura că tema sau plugin-ul dvs. funcționează în toate cazurile, presupunând că alții codifică și modul corect.

Există, de asemenea, unele neînțelegeri cu privire la ceea ce spune Codex-ul în legătură cu acest lucru, pe care îl voi clarifica.

Ce e in cutie?

Când descărcați WordPress, există deja o selecție de biblioteci JavaScript comune pe care le puteți utiliza pentru dezvoltarea JavaScript. O listă de biblioteci incluse poate fi găsită în Codul WordPress wp_enqueue_script articol.

Toate aceste biblioteci sunt incluse, dar în mod implicit WordPress încarcă doar cele de care are nevoie și numai atunci când are nevoie de ele în admin. Dacă scrieți JavaScript care folosește una din aceste biblioteci, trebuie să-i spuneți WordPress că scriptul dvs. are nevoie de prima bibliotecă încărcată.

Spuneți WordPress despre scenariul dvs. și ce are nevoie

Unele lucruri de care să vă gândiți când codificați JavaScript pentru WordPress sunt:

Există o bibliotecă pe care o pot folosi?
Pot folosi versiunea inclusă?
Trebuie să-mi încarc script-ul în front-end și în admin?
Ce pagini de front-end și admin trebuie să-mi încarc scriptul?

Răspunsul la aceste întrebări vă ajută să aflați ce trebuie să faceți pentru a vă înregistra și a încărca scriptul. Acest lucru se face folosind o funcție WordPress numită wp_register_script, și aici este utilizarea sa în conformitate cu WordPress Codex:

wp_register_script ($ mâner, $ src, $ deps, $ ver, $ in_footer);

Deci, care sunt aceste variabile și de ce avem nevoie de ele de fiecare dată? (Aceasta este acoperită de pagina Codex, așa că voi fi scurtă și voi folosi engleza simplă)

$ mâner - ce veți utiliza pentru a face referire la acest script special ori de câte ori ar fi nevoie să-l enqueue, și trebuie să includeți această variabilă cel puțin
$ src - calea către fișierul sursă din plugin sau temă
$ dependențele - o matrice care conține $ mâner pentru orice alte script-uri pe care scriptul dvs. trebuie să le execute (adică o dependență)
$ ver - numărul de versiune pentru scriptul dvs., care poate fi folosit pentru cache-busting. Implicit, WordPress va utiliza numărul versiunii proprii ca număr de versiune pentru scriptul dvs.
$ in_footer - doriți să încărcați scriptul în subsolul dvs.? Setați acest lucru la Adevărat sau fals. Este fals în mod implicit, așa că se încarcă în antetul unde wp_head () este, și dacă specificați Adevărat se va încărca unde wp_footer () apare în temă

Ce este "Cache-Busting"?

Navigatorii îți amintesc ce scripturi și foi de stiluri le-au descărcat pentru un anumit site pe baza adresei URL a scriptului și a foii de stil. Dacă schimbați adresa URL, chiar dacă adăugați un querystring, browserul presupune că este un fișier nou și îl descarcă.

Ok, Asa ca sa incercam cateva exemple

Iată exemplul cel mai de bază pentru încărcarea unui script personalizat:

funcția wptuts_scripts_basic () // Înregistrează scriptul ca acesta pentru un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // sau // Înregistrați scriptul ca acesta pentru o temă: wp_register_script ('custom-script', get_template_directory_uri () ./js/custom-script.js '); // Fie pentru un plugin, fie pentru o temă, puteți enquege script-ul: wp_enqueue_script ('custom-script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic');

În primul rând, înregistrăm scenariul, astfel încât WordPress știe despre ce vorbim. Modalitatea de a găsi calea pentru fișierul nostru JavaScript este diferită dacă codificăm un plugin sau o temă, așa că am inclus exemple ale celor de mai sus. Apoi ne asteptam ca aceasta sa fie adaugata in HTML pentru pagina cand este generata, implicit in unde wp_head () este în temă.

Rezultatul pe care îl obținem din exemplul de bază este:

Acum, dacă scriptul dvs. se bazează pe una din bibliotecile incluse în WordPress, cum ar fi jQuery, puteți face o modificare foarte simplă a codului:

funcția wptuts_scripts_with_jquery () // Înregistrați scriptul ca acesta pentru un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // sau // Înregistrează scriptul ca acesta pentru o temă: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // Fie pentru un plugin, fie pentru o temă, puteți enquege script-ul: wp_enqueue_script ('custom-script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_jquery');

Notă: Implicit, jQuery este încărcat cu noConflict pentru a împiedica ciocnirile cu alte biblioteci (cum ar fi Prototype). Consultați secțiunea NoConflict a Codexului dacă nu știți cum să faceți acest lucru.

Vezi ce am făcut acolo? Doar adăugați o matrice cu mânerul "jquery" ca dependență. Utilizează o matrice aici, deoarece scriptul dvs. ar putea avea mai multe dependențe. Dacă scriptul dvs. utilizează interfața jQuery și jQuery UI, ați adăuga interfața jQuery UI în matricea de dependență, cum ar fi array ("jquery", "jquery-ui-core")

Deci, acum producția sa schimbat și putem vedea că jQuery a fost de asemenea adăugată în a paginii:

Să încercăm un exemplu cu toate clopotele și fluierele:

funcția wptuts_scripts_with_the_lot () // Înregistrați scriptul ca acesta pentru un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery' -core '),' 20120208 ', adevărat); // sau // Înregistrează scriptul ca acesta pentru o temă: wp_register_script ('custom-script', get_template_directory_uri ()) '/js/custom-script.js', array ('jquery', 'jquery-ui-core' ), '20120208', adevărat); // Fie pentru un plugin, fie pentru o temă, puteți enquege script-ul: wp_enqueue_script ('custom-script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_with_the_lot');

Ok, deci am adăugat acum o versiune și am specificat că acest script trebuie încărcat în subsol. Pentru numărul versiunii, am ales să utilizez data de astăzi pentru că este ușor de urmărit, dar puteți utiliza orice numerotare a versiunii doriți. De ieșire pentru acest lucru este puțin diferit, jQuery este ieșire în iar scriptul nostru împreună cu jQuery UI este afișat chiar înainte , asa:

... ...  ...

Obținerea priorităților dvs. drepte

Unii oameni preferă să nu folosească metodele adecvate de enqueuing deoarece simt că au un control mai redus asupra ordinii în care sunt încărcate scripturile. De exemplu, într-o temă care folosește modernizatorul, autorul temei ar putea dori să se asigure că modernizatorul este încărcat din timp.

Ceva pe care nu am menționat-o mai devreme este mai detaliat despre modul în care ADD_ACTION funcționează, pentru că aici putem exersa o mică influență asupra ordinii lucrurilor. Iată utilizarea funcției în conformitate cu pagina Codex WordPress:

add_action ($ tag, $ funcție_to_add, $ prioritate, $ accept_args);

Rețineți că de multe ori, și până în prezent în acest articol, numai $ tag-ul și $ function_to_add sunt utilizați parametrii. prioritate $ parametrul implicit la 10 și $ accepted_args parametrul implicit la 1. Dacă vrem ca scenariile sau stilurile noastre să fie enqueuate mai devreme, pur și simplu scădem valoarea pentru prioritate $ din implicit. De exemplu:

funcția wptuts_scripts_important () // Înregistrați scriptul ca acesta pentru un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__)); // sau // Înregistrați scriptul ca acesta pentru o temă: wp_register_script ('custom-script', get_template_directory_uri () ./js/custom-script.js '); // Fie pentru un plugin, fie pentru o temă, puteți enquege script-ul: wp_enqueue_script ('custom-script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_important', 5);

Rezultatul va fi același cu cel pe care l-am văzut anterior, dar va apărea mai devreme în documentul HTML.

Îndepărtarea bibliotecilor implicite și utilizarea rețelelor de difuzare a conținutului

Pot exista momente când doriți să utilizați o versiune diferită a unei biblioteci care este inclusă în WordPress. Poate că doriți să utilizați o versiune de ultimă oră sau nu doriți să așteptați următoarea versiune de WordPress înainte de a utiliza ultima versiune stabilă a jQuery. Un alt motiv ar fi că doriți să profitați de versiunea Google a unei biblioteci.

Este important să rețineți că acest lucru ar trebui făcut numai se face pe pluginuri sau teme utilizate pe site-urile pe care le veți fi menținerea personală. Toate pluginurile sau temele pe care le lansați pentru uz public ar trebui să utilizeze bibliotecile incluse în WordPress.

"De ce?!", Am auzit că te întrebi. Din simplul motiv că nu controlați aceste site-uri. Nu știți ce alte pluginuri și teme ar putea fi utilizate acolo și nu știți cât de des acestea vor actualiza plugin-ul sau tema. Utilizarea bibliotecilor ambalate cu WordPress este cea mai sigură opțiune.

Acestea fiind spuse, dacă doriți să faceți acest lucru pe un site pe care îl controlați, iată cum se face:

funcția wptuts_scripts_load_cdn () // Deregistrați biblioteca inclusă wp_deregister_script ('jquery'); // Înregistrați din nou biblioteca din CDN-ul Google wp_register_script ('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array (), null, false ); // Înregistrați scriptul ca acesta pentru un plugin: wp_register_script ('custom-script', plugins_url ('/js/custom-script.js', __FILE__), array ('jquery')); // sau // Înregistrează scriptul ca acesta pentru o temă: wp_register_script ('custom-script', get_template_directory_uri (). '/js/custom-script.js', array ('jquery')); // Fie pentru un plugin, fie pentru o temă, puteți enquege script-ul: wp_enqueue_script ('custom-script');  add_action ('wp_enqueue_scripts', 'wptuts_scripts_load_cdn');

Deci, în primul rând, am deregistrat versiunea inclusă a bibliotecii, altfel ar putea fi introduse conflicte între diferite versiuni. Apoi, înregistrați versiunea alternativă, utilizând același mâner și am ales să specificați null ca versiune (este deja în URL!) Și nu a fost specificată în subsol. Restul codului nostru este același, deoarece depindeau de orice script folosit de mânerul "jquery". Rezultatul pe care îl obținem acum arată astfel:

Notă: Unul dintre motivele pentru care aceasta este o idee proastă de făcut într-un plugin sau o temă pentru lansarea publică este că toate celelalte pluginuri și teme utilizate pe acest site vor trebui să utilizeze acum această versiune a jQuery. De asemenea, versiunea nou înregistrată a jQuery nu are setul noConflict, deci dacă orice alt plugin sau script-uri tematice utilizează Prototype, de exemplu, acest lucru va sparge lucrurile.

Nu fiți lacomi

Până în prezent nu am menționat nimic despre cum să facem toate astea în admin, doar în front-end. Principala diferență este ce acțiune trebuie utilizată. In loc de add_action ('wp_enqueue_scripts', 'wptuts_scripts_basic'); pe care le folosim pentru front-end, acțiunea pentru admin este add_action ('admin_enqueue_scripts', 'wptuts_scripts_basic');

Ceva important pentru a face atât pentru front-end, cât și pentru admin este selectiv în ce pagini încărcați script-urile dvs. Dacă pluginul sau tema dvs. are un script care face doar ceva pe o pagină de front sau pe o pagină de administrare, cum ar fi pagina de opțiuni a temei sau poate o pagină cu un anumit widget, este suficient să încărcați scriptul pe acea pagină. Nici un punct nu înfundă lucrurile și nu încarcă scripturi în paginile în care nu sunt folosite!

Există un exemplu excelent în Codul WordPress cu privire la modul de încărcare a scripturilor numai în paginile pluginului. Deoarece pluginurile și temele pot varia foarte mult în modul în care sunt scrise, nu voi intra în specificul de aici despre cum să fiți ales în privința paginilor pe care încărcați scripturi, dar a fost important să menționați, astfel încât să fiți conștient când codificați.

Acestea sunt scripturile, stilurile acum

Procesul pentru stiluri este aproape exact același proces ca și scenariile. Se face folosind o funcție WordPress numită wp_register_style, și aici este utilizarea sa în conformitate cu WordPress Codex:

wp_register_style ($ mâner, $ src, $ deps, $ ver, $ media);

Rețineți că singura diferență există între acestea wp_register_script și wp_register_style este că în loc de un $ in_footer parametru, avem a $ media parametru. Acest parametru poate fi setat la oricare dintre următoarele: 'toate', 'ecran', „Portabile“, și 'imprimare', sau orice alt tip de suport recunoscut de W3C.

Deci, un exemplu despre modul în care s-ar putea enquela un stil ar fi:

funcția wptuts_styles_with_the_lot () // Înregistrați stilul ca acesta pentru un plugin: wp_register_style ('custom style', plugins_url ('/css/custom-style.css', __FILE__), array (), '20120208' '); // sau // Înregistrați stilul ca acesta pentru o temă: wp_register_style ('stil personalizat', get_template_directory_uri () ./css/custom-style.css ', array (),' 20120208 ',' toate '); // Fie pentru un plugin, fie pentru o temă, puteți enqueue stilul: wp_enqueue_style ('stil personalizat');  add_action ('wp_enqueue_scripts', 'wptuts_styles_with_the_lot');

Acesta este un exemplu destul de cuprinzător, care utilizează majoritatea parametrilor, iar rezultatul pe care îl produce arată:

Deci, de ce nu face deja toată lumea acest lucru?

Întrebare bună, iar cealaltă întrebare pe care cred că ați putea să o întrebați este: "Ce te face să crezi că aceasta este calea" potrivită "și nu doar preferința ta?". În esență, răspunsul este că aceasta este abordarea recomandată de WordPress. Se asigură că orice combinație de pluginuri și teme ar trebui să poată lucra împreună și fără a se dubla.

Am văzut câteva teme și cadre în jurul locului care le utilizează și în etichetele lor header.php, și chiar footer.php, fișiere pentru a încărca scripturile și stilurile pentru tema însăși. Nu există niciun motiv pentru a face lucrurile în acest fel. După cum am demonstrat mai sus, este foarte posibil să acordați prioritate scenariilor și stilurilor și să desemnați dacă se încarcă în antet sau subsol din confortul și siguranța dvs. functions.php. Beneficiul este că tema / cadrul dvs. va funcționa cu o gamă mai largă de alte pluginuri / teme pentru copii.

Un exemplu a fost încărcarea jQuery folosind tag-uri, care ar putea părea să funcționeze frumos, dar acest lucru poate provoca de fapt jQuery să fie încărcate de două ori! Încărcarea jQuery în acest fel nu va opri WordPress de la încărcarea versiunii sale de jQuery pentru alte pluginuri, deoarece versiunea WordPress este în mod noconflict în mod implicit și un plugin îl poate specifica ca dependență. Deci, acum veți avea jQuery care lucrează atât pentru modul noConflict, cât și pentru $, și, probabil, sparge orice plugin care folosește biblioteca Prototype.

Concluzie

WordPress este un sistem fantastic, și a fost dezvoltat cu o mulțime de gândire. Dacă există un mecanism pus la dispoziție pentru a face ceva, este adesea o idee bună să o utilizați. Când vă dezvoltați pluginurile și temele, încercați să vă amintiți să codificați cu grijă și să jucați frumos cu ceilalți.

Ce credeți despre utilizarea lui wp_enqueue_script și funcțiile și acțiunile asociate acesteia? Știți despre exemple în care se face în mod incorect? Știți de orice motiv să nu urmați sfatul de mai sus?

Dacă aveți nevoie de o soluție gata, puteți naviga prin Wordpress Themes și Wordpress Plugins pe Envato Market.

Cod