👉 Hur du fixar '$ is not a function' i WordPress: 4 sätt
Du redigerar functions.php, lägger till ett par rader jQuery, och sajten kraschar med en vit skärm. Konsolen visar: Uncaught TypeError: $ is not a function. Låter det bekant?
Varje WordPress-utvecklare stöter på det här felet minst en gång. Du kopierar fungerande jQuery-kod från CodePen eller ett kodsnutt, klistrar in den på din sajt, och WordPress förstår den inte. Orsaken är inte trasig kod eller plugin-konflikter. Orsaken är hur WordPress hanterar jQuery.
Vi går igenom fyra beprövade metoder för att fixa felet "$ is not a function", från den säkra IIFE-wrappern till att helt inaktivera noConflict. Varje metod kommer med färdig kod som du kan kopiera och klistra in.
💡 Snabb översikt:
- Wrappa jQuery-kod i en anonym IIFE-funktion, den säkraste och mest universella metoden
- Använd jQuery document ready med en dollar-parameter för skript i head
- Tilldela ditt eget alias via noConflict, praktiskt när dollartecknet används av ett annat bibliotek
- Inaktivera noConflict globalt, endast när det inte finns några andra bibliotek på sajten
Varför felet "$ is not a function" uppstår i WordPress
WordPress laddar jQuery i noConflict-läge. Det innebär att variabeln $, jQuerys korta alias, inte är globalt tillgänglig. WordPress kärnutvecklare gjorde detta medvetet för att undvika konflikter: många JavaScript-bibliotek (Prototype, MooTools, äldre Bootstrap-versioner) använder också $ som sin huvudsakliga förkortning.
När du skriver i ditt skript:
1 $("#element").hide();
Vet WordPress inte att $ är jQuery. Det ser ett anrop till en okänd funktion och kastar TypeError: $ is not a function. Utanför WordPress, på en "ren" HTML-sida, skulle samma kod fungera utan problem, eftersom jQuery registrerar $ globalt där.
Tekniskt sett förstår WordPress bara det fullständiga namnet: jQuery("#element").hide(). Men att skriva jQuery istället för $ på varje rad i ett flerradigt skript är opraktiskt, koden blir större och förlorar läsbarhet. Lyckligtvis finns det fyra sätt att kringgå denna begränsning.
Innan du redigerar några temafiler, gör en säkerhetskopia av din sajt. Ett enda saknat semikolon i functions.php, och sajten går ner. Med en säkerhetskopia kan du återställa ändringarna på en minut.
Metod 1: IIFE-wrapper, säker och universell
Det mest pålitliga sättet att få tillbaka $ i WordPress-skript är en Immediately Invoked Function Expression (IIFE). Du skickar jQuery som ett argument, och inuti funktionen refererar du till det via det välbekanta $.
Kod för footer.php eller inkludering på låg nivå (sidfot):
1 (function($) { 2 // Your jQuery code here 3 $("#element").hide(); 4 })(jQuery);
Vad som händer här: en anonym funktion tar emot parametern $ och anropas omedelbart med argumentet jQuery. Inuti denna funktion gäller $ === jQuery, medan $ utanför förblir odefinierat. Konflikt med andra bibliotek är eliminerad.
Denna metod fungerar för skript i sidfoten. Om skriptet måste köras i <head>, använd metod 2.
Metod 2: jQuery(document).ready med $-parameter
När ett skript måste köras i sidhuvudet (innan DOM laddas), wrappa det i jQuery(document).ready. Notera: $ skickas till callback-parametern, detta är inte ett stavfel utan en central poäng.
Kod för header.php eller functions.php via wp_enqueue_script:
1 jQuery(document).ready(function($) { 2 // Your jQuery code here 3 console.log($); 4 });
Metoden .ready() väntar på fullständig DOM-inladdning, och jQuery skickar sig själv till callbacken som $. Inuti denna callback fungerar $ igen som i en normal JavaScript-miljö. Och, till skillnad från metod 1, startar skriptet från <head>, vilket är användbart för kritiska initialiseringsoperationer.
De flesta tema- och plugin-utvecklare känner till denna WordPress-egenhet, så i kvalitetsprodukter ser du nästan alltid jQuery istället för $, eller en av ovanstående wrappers.
Metod 3: skapa ditt eget alias via noConflict
jQuery låter dig inte bara ta tillbaka $, utan också tilldela vilket annat kort alias som helst, till exempel variablerna $j eller jq, eller vilken variabel du föredrar. Detta är praktiskt när sajten redan använder ett annat bibliotek som har tagit $.
1 var jq = jQuery.noConflict(); 2 jq("div p").hide(); 3 4 // Another library continues using its own $ 5 $("content").style.display = "none";
Metoden jQuery.noConflict() frigör $ för andra bibliotek och returnerar jQuery till din variabel (jq i exemplet). Efter detta görs anrop via jq(...), medan $ fungerar för det andra biblioteket, konflikten försvinner helt.
Detta tillvägagångssätt är särskilt användbart på sajter där ett WordPress-tema samexisterar med ett tredjeparts JavaScript-ramverk som använder $ för sina egna syften.
Metod 4: inaktivera noConflict helt (använd med försiktighet)
Om du med säkerhet vet att sajten inte har några andra bibliotek som gör anspråk på $, kan du inaktivera noConflict-läget globalt:
1 $ = jQuery.noConflict(true);
Efter denna rad fungerar $ igen som ett globalt jQuery-alias överallt, i alla skript, var som helst på sidan. Denna metod är dock den mest riskfyllda. Om du senare installerar ett plugin som också använder $, kommer sajten att gå sönder med en svårreproducerad bugg.
Vi rekommenderar metod 1 och 2 som primära, de är säkra, isolerade och täcker de allra flesta verkliga scenarier. Metod 4 är för situationer när du underhåller ett stort äldre skript och inte kan wrappa varje funktion separat.
I videon ovan visas en visuell demonstration av alla fyra metoder i praktiken. Se den om du föredrar visuell förklaring framför text.
⁉️🤔 Vanliga frågor
Varför inaktiverade WordPress $ för jQuery från början?
WordPress kärnutvecklare aktiverade
jQuery.noConflict()som standard för att skydda sajter från konflikter med andra JavaScript-bibliotek. Prototype.js, MooTools och vissa äldre ramverk registrerar också en global$-variabel. Om WordPress gav$till jQuery skulle varje tema eller plugin med ett sådant bibliotek förstöra adminpanelen eller frontend. WordPress har kört jQuery i noConflict-läge sedan version 3.6, detta är inte en bugg utan ett arkitektoniskt beslut. Variabeln$i det globala scopet förblir fri för tredjepartsbibliotek. Det är precis därför$("#id")utanför en wrapper alltid kommer att kastaTypeError.
Kan jag bara inkludera jQuery en andra gång, utanför WordPress?
Tekniskt sett, ja, du kan inkludera jQuery via en CDN-länk en andra gång, och det kommer att registrera
$globalt. Men detta är dålig praxis: två jQuery-versioner på en sida hamnar i konflikt, sidstorleken växer, och WordPress-plugins förväntar sig exakt den jQuery-version som registreras viawp_enqueue_script. Arbeta alltid med den jQuery-version WordPress tillhandahåller, den är testad för kompatibilitet med kärnan och adminpanelen. Att inkludera jQuery igen innebär att skapa nya problem istället för att lösa det ursprungliga.
Vad gör jag om felet bara visas på specifika sidor?
Kontrollera om den specifika sidan laddar ett tredjepartsskript via ett plugin eller en widget. Vissa caching- och minifieringsplugins ändrar aggressivt ordningen på skript, och jQuery kan laddas efter din kod. Inaktivera optimeringsplugins ett efter ett för att hitta den skyldige. I de flesta fall orsakas problemet "$ is not a function på en sida" av skriptens laddningsordning. Ett minifierings- eller caching-plugin placerar ditt skript före jQuery, och
$existerar ännu inte vid anropstillfället. Lösning: antingen exkludera skriptet från minifiering, eller wrappa det i IIFE från metod 1, som inte är beroende av global$.
Finns det ett färdigt plugin som fixar detta fel?
Det finns inget dedikerat plugin "för att fixa $ is not a function", och det behövs inte. Problemet löses med en enrads-wrapper, och att installera ett separat plugin för detta är överdrivet. Det finns dock plugins som Code Snippets som låter dig lägga till JavaScript- och PHP-kod utan att redigera temafiler, vilket är säkrare för nybörjare. Code Snippets lagrar din kod i databasen, inte i
functions.php. Om du gör ett syntaxfel återställer pluginet automatiskt ändringarna, och sajten kraschar inte. Vi rekommenderar nybörjare att lägga till all JS-kod via det, inte genom att redigera temafiler.
Felet "$ is not a function" är fixat, vad händer nu?
Huvudpoäng: problemet ligger inte i din kod och inte i WordPress. Detta är standardbeteende för CMS:et, och det fixas med en wrapper. I de allra flesta fall räcker metod 1 (IIFE) eller metod 2 (.ready() med $). De förstör inte andra skript och fungerar i alla WordPress-versioner, från 4.0 till den senaste.
Om du ofta arbetar med jQuery i WordPress, utveckla vanan att börja varje skript med (function($) { och avsluta med })(jQuery);, detta blir muskelminne inom en vecka och eliminerar felet för alltid.
Dela artikeln med kollegor som fortfarande redigerar functions.php genom trial and error, en färdig wrapper sparar dem en timmes felsökning.
Ett professionellt team av skribenter och redaktörer specialiserade på att skapa kvalitetsinnehåll.