Share
Unul dintre cele mai bune lucruri despre WordPress este economia sa vibrantă. Pentru mulți utilizatori, este ușor să găsiți teme pentru a se potrivi designului pentru care vizează sau pentru a găsi pluginuri care oferă funcționalități pe care doresc să le introducă pe site-ul lor.
Dar câți dintre dvs. - ca dezvoltatori sau designeri - au primit acel telefon sau acel e-mail în care clientul susține că ceva nu este în regulă cu site-ul lor doar pentru a descoperi că consola browserului afișează ceva despre o eroare care are legătură cu JavaScript sau jQuery?
Exact. Cel mai probabil, oricine a construit și / sau a întreținut un site pentru cineva a întâmpinat această problemă mai ales dacă utilizatorul final primește permisiunea de a adăuga propriile pluginuri, permite actualizări proprii, etc.
În acest post, vom examina câteva concepte în jurul jQuery și WordPress pentru a ne asigura că noi, ca dezvoltatori, nu numai că lucrăm pentru a construi produsele noastre în mod corect, ci și că știm cum să diagnosticăm corect problemele pe măsură ce acestea apar site-urile clienților noștri.
Acest subiect special nu este nou pentru Wptuts +. De fapt, am scris un articol amplu despre el înainte de a fi completat cu un număr de exemple de cod, toate acestea ar trebui să vă ofere tot ce aveți nevoie pentru a înțelege cum să lucrați cu JavaScript în WordPress.
Dar, pe măsură ce continuăm să observăm anumite practici care se întâmplă în comunitate pe care ne-ar plăcea să le rezolvăm, nu ne deranjează să acoperim multiple aspecte ale aceluiași subiect.
Deci, înainte de a citi acest articol, asigurați-vă că sunteți familiarizat cu modul de includere a JavaScript și CSS în temele și pluginurile WordPress.
Când vine vorba de a construi produse în WordPress, unul dintre lucrurile pe care noi, ca dezvoltatori, trebuie să încercăm să le facem este să tratăm aplicația WordPress ca fundație.
În acest moment, API ne permite să oferim o mare flexibilitate atunci când vine vorba de construirea de teme, pluginuri și aplicații, iar acest lucru este un lucru bun.
Dar când începem să eliminăm bibliotecile livrate cu WordPress în favoarea noastră, este ca și cum am crea o "mini-furcă" a proiectului.
Aceasta nu este o practică bună de adoptat.
În ceea ce mă privește, WordPress livrează cu setul de funcții și biblioteci de bază care îi permit să funcționeze așa cum procedează. Schimbarea unor părți esențiale ale aplicației - cum ar fi jQuery - nu afectează numai WordPress, ci întregul ecosistem al produselor care sunt construite pe el.
Temele și pluginurile bune depind de prezența acelor biblioteci. Atunci când schimbăm această funcție, este posibil să rupem orice lucrare care depinde de ele.
Trebuie să oprim vizualizarea WordPress ca ceva pe care îl putem distra și reasambla în timp ce avem nevoie de ea și o considerăm o fundație din care să ne construim o lucrare unică.
În general, problema conflictelor de JavaScript există pentru unul din trei motive. Un dezvoltator are fie:
În primul rând, oricare dintre cele trei cazuri de mai sus ar putea fi realizate simultan, dar mai des decât unul din cele de mai sus. În al doilea rând, nu cred că dezvoltatorii de obicei fac acest lucru cu prost intenție.
Cred că este mai mult o lipsă de educație și / sau înțelegere a consecințelor.
Prin aceasta, vreau să spun că dezvoltatorul a obținut în mod necorespunzător accesul la biblioteca jQuery fie prin executare noConflict, nu întoarce în mod corespunzător variabila la starea inițială sau pur și simplu redenumirea funcției de scurtătură.
Mai târziu, în acest articol, vom examina cele mai bune practici pentru scrierea jQuery specifică WordPress, astfel încât să ne permită să profităm pe deplin de bibliotecă fără a intra în conflict cu alte pluginuri, teme sau proiecte.
Acesta este ceva care se face adesea cu bună intenție: Ideea este că dezvoltatorul furnizează o actualizare a versiunii jQuery care este inclusă în WordPress, astfel încât pot fi scrise noi caracteristici sau mai multe jQuery moderne.
Problema cu acest lucru este că proiectele dezvoltate anterior nu sunt scrise cu unele dintre noile caracteristici ale celei mai recente versiuni a jQuery. De asemenea, dacă jQuery a depreciat sau a eliminat complet o funcție în noua versiune care era prezentă în versiunea veche, atunci aceasta va împiedica funcționarea acestui cod.
Deși aceasta este o problemă mai puțin obișnuită, este ceva care se întâmplă ocazional: într-o încercare de a contribui la o încărcare mai rapidă a site-ului, dezvoltatorii vor muta ordinea în care jQuery este încărcat mai jos în pagină, de obicei în subsol.
În timp ce încărcarea JavaScript în subsolul paginii este încurajată de un număr de site-uri de profil înalt, acest lucru revine la gândirea WordPress, holistic, ca bază pentru dezvoltarea aplicațiilor.
Dacă WordPress, în mod implicit, încarcă jQuery într-o anumită locație, atunci trebuie să ne amintim să o lăsăm acolo, deoarece toate lucrările care sunt construite pe partea de sus a aplicației depind de faptul că este în acea locație și nicăieri altundeva.
Deși există o serie de moduri diferite în care puteți pregăti fișierele sursă JavaScript pentru a utiliza jQuery, există o modalitate pe care am tendința să o urmez deoarece protejează și încorporează complet $ funcţie.
(funcția ($) "utilizarea strictă"; $ (funcția () // Codul dvs. aici); (jQuery));
De asemenea, puteți vizualiza conținutul GitHub aici.
Pe scurt:
Aceasta oferă o versiune încărcată corect a jQuery care utilizează standardul
$funcția de referință pentru a ne permite să continuăm să ne desfășurăm activitatea.
Rețineți că "utilizați stricte"prevede următoarele:
Modul Strict este o funcție nouă în ECMAScript 5, care vă permite să plasați un program sau o funcție într-un context de operare "strict". Acest context strict împiedică luarea unor măsuri și aruncă mai multe excepții
Pentru cei interesați, puteți citi mai multe despre acest lucru pe acest site.
În cele din urmă, realitatea document.ready funcția este opțională. Aici este folosit doar pentru a arăta cum puteți începe să utilizați funcțiile jQuery standard în contextul codului.
Rețineți că următoarea versiune de WordPress intenționează să livreze cu un patch care va face această discuție particulară depășită, cel puțin până la tabloul de bord.
Mai exact, în prezent există un bilet în Trac în care WordPress nu ne va permite să eliminăm jQuery din Tabloul de bord. E un lucru bun.
Pe scurt, principalele jocuri pentru acest articol sunt după cum urmează:
Accentsconagua
$ funcția folosind facilitățile JavaScript adecvateAș spune că a face orice altceva este să te pregătești pentru rezultate potențial proaste.
