👉 Kuidas parandada „$ is not a function” WordPressis: 4 viisi
Muudad faili functions.php, lisad paar rida jQuery koodi ja sait jookseb kokku valge ekraaniga. Konsool näitab: Uncaught TypeError: $ is not a function. Tuttav olukord?
Iga WordPressi arendaja puutub selle veaga vähemalt korra kokku. Kopeerid CodePenist või mõnest koodinäitest töötava jQuery koodi, kleebid selle oma saidile ja WordPress ei mõista seda. Põhjus pole katkises koodis ega pistikprogrammide konfliktis. Põhjus on selles, kuidas WordPress jQueryt käsitleb.
Vaatame läbi neli tõestatud meetodit vea "$ is not a function" parandamiseks, alates turvalisest IIFE ümbrisest kuni noConflict'i täieliku keelamiseni. Iga meetodi juurde kuulub kasutusvalmis kood, mida saad kopeerida ja kleepida.
💡 Kiire ülevaade:
- Paki jQuery kood IIFE anonüümsesse funktsiooni, kõige turvalisem ja universaalsem meetod
- Kasuta jQuery document ready't koos dollari parameetriga skriptide puhul, mis on lehe päises
- Määra noConflict'i abil oma alias, mugav, kui dollarimärk on teise teegi poolt hõivatud
- Keela noConflict globaalselt, ainult siis, kui saidil pole muid teeke
Miks viga "$ is not a function" WordPressis tekib
WordPress laadib jQueryt noConflict režiimis. See tähendab, et $ muutuja, jQuery lühike alias, pole globaalselt saadaval. WordPressi tuumiku arendajad tegid seda teadlikult, et vältida konflikte: paljud JavaScripti teegid (Prototype, MooTools, vanemad Bootstrapi versioonid) kasutavad samuti $ oma peamise lühinimena.
Kui kirjutad oma skriptis:
1 $("#element").hide();
WordPress ei tea, et $ on jQuery. See näeb väljakutset tundmatule funktsioonile ja annab vea TypeError: $ is not a function. Väljaspool WordPressi, "paljal" HTML-lehel, töötaks see sama kood probleemideta, sest jQuery registreerib $ seal globaalselt.
Tehniliselt mõistab WordPress ainult täisnime: jQuery("#element").hide(). Kuid jQuery kirjutamine $ asemel igale reale mitmerealises skriptis on ebamugav, kood paisub ja kaotab loetavuse. Õnneks on neli võimalust sellest piirangust mööda hiilida.
Enne ühegi teemafaili muutmist tee oma saidist varukoopia. Üks puuduv semikoolon failis functions.php ja sait läheb maas. Varukoopiaga saad muudatused minuti jooksul tagasi võtta.
Meetod 1: IIFE ümbris, turvaline ja universaalne
Kõige usaldusväärsem viis $ WordPressi skriptides tagasi tuua on kohe käivituv funktsiooniavaldis (IIFE). Sa edastad jQuery argumendina ja funktsiooni sees viitad sellele tuttava $ kaudu.
Kood faili footer.php või madala taseme lisamise jaoks (saidijalus):
1 (function($) { 2 // Your jQuery code here 3 $("#element").hide(); 4 })(jQuery);
Mis siin toimub: anonüümne funktsioon võtab vastu $ parameetri ja käivitatakse kohe jQuery argumendiga. Selle funktsiooni sees $ === jQuery, samas kui väljaspool jääb $ määramata. Konflikt teiste teekidega on välistatud.
See meetod töötab jalusesse paigutatud skriptide puhul. Kui skript peab käivituma <head> sektsioonis, kasuta meetodit 2.
Meetod 2: jQuery(document).ready koos $ parameetriga
Kui skript peab käivituma lehe päises (enne DOM-i laadimist), paki see jQuery(document).ready sisse. Pane tähele: $ edastatakse callback'i parameetrile, see pole trükiviga, vaid oluline punkt.
Kood faili header.php või functions.php kaudu wp_enqueue_script abil:
1 jQuery(document).ready(function($) { 2 // Your jQuery code here 3 console.log($); 4 });
.ready() meetod ootab DOM-i täielikku laadimist ja jQuery edastab iseenda callback'ile kui $. Selle callback'i sees töötab $ taas nagu tavalises JavaScripti keskkonnas. Ja erinevalt meetodist 1, käivitub skript <head> sektsioonist, mis on kasulik kriitiliste lähtestamistoimingute puhul.
Enamik teema- ja pistikprogrammide arendajaid teab seda WordPressi eripära, nii et kvaliteetsetes toodetes näed peaaegu alati jQuery asemel $ või üht ülaltoodud ümbristest.
Meetod 3: loo enda alias noConflict'i abil
jQuery võimaldab sul mitte ainult $ tagasi tuua, vaid määrata ka mis tahes muu lühikese aliase, näiteks muutujad $j või jq või ükskõik millise enda eelistatud muutuja. See on mugav, kui sait kasutab juba mõnda teist teeki, mis on $ hõivanud.
1 var jq = jQuery.noConflict(); 2 jq("div p").hide(); 3 4 // Another library continues using its own $ 5 $("content").style.display = "none";
jQuery.noConflict() meetod vabastab $ teiste teekide jaoks ja tagastab jQuery sinu muutujale (näites jq). Pärast seda tehakse väljakutsed jq(...) kaudu, samas kui $ töötab naaberteegi jaoks, konflikt kaob täielikult.
See lähenemine on eriti kasulik saitidel, kus WordPressi teema eksisteerib koos kolmanda osapoole JavaScripti raamistikuga, mis kasutab $ oma eesmärkidel.
Meetod 4: keela noConflict täielikult (kasuta ettevaatusega)
Kui tead kindlalt, et saidil pole muid teeke, mis $ nõuaksid, saad noConflict režiimi globaalselt keelata:
1 $ = jQuery.noConflict(true);
Pärast seda rida töötab $ taas globaalse jQuery aliase'na kõikjal, igas skriptis, ükskõik kus lehel. Kuid see meetod on kõige riskantsem. Kui hiljem paigaldad pistikprogrammi, mis samuti $ kasutab, läheb sait katki raskesti taasesitatava veaga.
Soovitame meetodeid 1 ja 2 esmaste valikutena, need on turvalised, isoleeritud ja katavad valdava enamuse reaalsetest stsenaariumidest. Meetod 4 on olukordadeks, kui hooldad suurt pärandskripti ega saa iga funktsiooni eraldi pakkida.
Ülaltoodud videos on visuaalne demonstratsioon kõigist neljast meetodist töös. Vaata seda, kui eelistad visuaalset selgitust tekstile.
⁉️🤔 Korduma kippuvad küsimused
Miks WordPress üldse keelas $ kasutamise jQuery jaoks?
WordPressi tuumiku arendajad lubasid
jQuery.noConflict()vaikimisi, et kaitsta saite konfliktide eest teiste JavaScripti teekidega. Prototype.js, MooTools ja mõned vanemad raamistikud registreerivad samuti globaalse$muutuja. Kui WordPress annaks$jQueryle, lõhuks iga sellise teegiga teema või pistikprogramm halduspaneeli või esikülje. WordPress on käitanud jQueryt noConflict režiimis alates versioonist 3.6, see pole viga, vaid arhitektuuriline otsus.$muutuja globaalses skoobis jääb vabaks kolmandate osapoolte teekidele. Just seetõttu viskab$("#id")väljaspool ümbrist alatiTypeErrorvea.
Kas ma võin lihtsalt jQuery teist korda kaasata, väljaspool WordPressi?
Tehniliselt jah, saad jQuery CDN-lingi kaudu teist korda kaasata ja see registreerib
$globaalselt. Kuid see on halb praktika: kaks jQuery versiooni ühel lehel lähevad konflikti, lehe maht kasvab ja WordPressi pistikprogrammid eeldavad täpselt seda jQuery versiooni, mis on registreeritudwp_enqueue_scriptkaudu. Tööta alati selle jQuery versiooniga, mille WordPress pakub, see on testitud ühilduvuse osas tuumiku ja halduspaneeliga. jQuery uuesti kaasamine tähendab uute probleemide tekitamist, mitte algse lahendamist.
Mida teha, kui viga ilmneb ainult teatud lehtedel?
Kontrolli, kas konkreetne leht laadib pistikprogrammi või vidina kaudu kolmanda osapoole skripti. Mõned vahemällu salvestamise ja tihendamise pistikprogrammid korraldavad skripte agressiivselt ümber ja jQuery võib laadida pärast sinu koodi. Keela optimeerimispistikprogrammid ükshaaval, et süüdlast leida. Enamikul juhtudel on "$ is not a function ühel lehel" probleemi põhjuseks skriptide laadimise järjekord. Tihendamise või vahemällu salvestamise pistikprogramm asetab sinu skripti enne jQueryt ja
$pole väljakutse hetkel veel olemas. Lahendus: kas välista skript tihendamisest või paki see meetodi 1 IIFE-sse, mis ei sõltu globaalsest$-st.
Kas on olemas valmis pistikprogramm, mis selle vea parandab?
Pole olemas spetsiaalset pistikprogrammi "$ is not a function" parandamiseks ja seda pole ka vaja. Probleem lahendatakse üherealise ümbrisega ja eraldi pistikprogrammi paigaldamine selleks on üleliigne. Siiski on olemas pistikprogrammid nagu Code Snippets, mis võimaldavad JavaScripti ja PHP koodi lisada ilma teemafaile muutmata, mis on algajatele turvalisem. Code Snippets salvestab sinu koodi andmebaasi, mitte faili
functions.php. Kui teed süntaksivea, kerib pistikprogramm muudatused automaatselt tagasi ja sait ei jookse kokku. Soovitame algajatel lisada igasugust JS koodi selle kaudu, mitte teemafaile muutes.
Viga "$ is not a function" on parandatud, mis edasi?
Peamine järeldus: probleem pole sinu koodis ega WordPressis. See on standardne CMS-i käitumine ja see parandatakse ühe ümbrisega. Valdavas enamuses juhtudest piisab meetodist 1 (IIFE) või meetodist 2 (.ready() koos $-ga). Need ei lõhu teisi skripte ja töötavad igas WordPressi versioonis, alates 4.0 kuni uusimani.
Kui töötad sageli jQueryga WordPressis, kujunda harjumus alustada iga skripti reaga (function($) { ja lõpetada reaga })(jQuery);, see muutub nädalaga lihasmäluks ja kõrvaldab vea alatiseks.
Jaga artiklit kolleegidega, kes ikka veel katse-eksituse meetodil functions.php faili muudavad, üks valmis ümbris säästab neilt tunni jagu silumist.
Professionaalne kirjanike ja toimetajate meeskond, kes on spetsialiseerunud kvaliteetse sisu loomisele.