Du installerar ett tillägg och det drar in sin egen kopia av jQuery. Ditt tema har redan laddat jQuery via wp_enqueue_script. Tillägget laddar det, än en gång, direkt från ett CDN. På sidan: två eller till och med tre versioner av samma bibliotek. Konflikter, uppblåst storlek, oförutsägbart beteende.

Problemet är lika gammalt som WordPress självt, men det händer fortfarande: utvecklare kopierar in <script src="jquery.js"> i header.php "för att det går snabbare". Snabbare, fram till den första konflikten med ett tillägg som förväntar sig den inbyggda WP-versionen.

Från och med 2026 levereras WordPress med jQuery 3.6.0 ur lådan och erbjuder ett enkelt, deterministiskt sätt att inkludera det utan duplicering och utan att manuellt hålla reda på versioner. Nedan följer det enda korrekta tillvägagångssättet, från grundläggande wp_enqueue_script till att säkert ersätta det med en CDN-version och använda noConflict-läge.

💡 Snabb översikt:

• Hur WordPress redan laddar jQuery och varför du inte ska göra det manuellt
• wp_enqueue_script med beroendet jquery: en rad i functions.php
• När och hur du säkert ersätter den inbyggda jQuery med en CDN-version (Google / cdnjs)
• noConflict-läge: skydd mot kollisioner med andra bibliotek
• Tips för teman och tillägg: när du INTE ska skriva över den inbyggda jQuery

JQuery finns redan i core: vad WordPress gör åt dig

Från och med version 3.6 registrerar WordPress jQuery under handtaget jquery. Du behöver inte ladda ner jquery.min.js, placera den i din temamapp och inkludera den med en <script>-tagg. Core gör detta automatiskt så snart du anger jquery i ditt skripts beroenden.

Den aktuella jQuery-versionen i WordPress core är 3.6.0. Den levereras tillsammans med jQuery Migrate (för bakåtkompatibilitet med äldre kod) och laddas bara när något skript deklarerar jquery som ett beroende. Inga beroenden innebär att jQuery inte dyker upp på sidan, och webbplatsen laddar inga onödiga resurser.

Det är därför en direkt <script src="/wp-content/themes/mytime/jquery.js"> i header.php är ett misstag, inte en genväg. Du kringgår beroendesystemet, tar bort WP:s förmåga att hantera laddningsordning och får en dubblett när ett tillägg legitimt begär jquery via wp_enqueue_script.

Rätt sätt: wp_enqueue_script med ett beroende

Den grundläggande mekaniken ryms på en rad inuti wp_enqueue_scripts-hooken. Du skriver ditt skript, och WordPress listar ut när och i vilken ordning allt ska laddas.

Skapa (eller öppna) ditt temas functions.php och lägg till:

1
function mytheme_enqueue_scripts() {
2
    wp_enqueue_script(
3
        'mytheme-main',
4
        get_template_directory_uri() . '/js/main.js',
5
        array( 'jquery' ),
6
        '1.0.0',
7
        array(
8
            'strategy'  => 'defer',
9
            'in_footer' => true,
10
        )
11
    );
12
}
13
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_scripts' );

Vad som händer här:

• mytheme-main är det unika handtaget för ditt skript. Hitta på ett eget, med prefix från temanamnet.
• get_template_directory_uri() . '/js/main.js' är sökvägen till filen. Du kan också använda en extern CDN-URL.
• array( 'jquery' ) är nyckelpunkten: du talar om för WP "mitt skript är beroende av jQuery." Core ser detta och köar automatiskt jQuery före ditt skript. Inga <script>-taggar i mallen.
• '1.0.0' är versionen för cache-busting. Ändra den vid varje skriptuppdatering.
• array( 'strategy' => 'defer', 'in_footer' => true ): sedan WordPress 6.3 accepterar parametern $args en array. defer betyder "kör skriptet efter att DOM har byggts men före DOMContentLoaded." in_footer placerar skriptet i sidfoten.

Den gamla syntaxen med en boolesk femte parameter (true = i sidfot) fungerar fortfarande, men för nya projekt, använd array-syntaxen. Den är mer läsbar och ger dig kontroll över async/defer.

Kontrollera att ditt tema anropar wp_head() före avslutande </head> och wp_footer() före </body>. Utan dessa anrop kommer wp_enqueue_script helt enkelt inte att fungera. Detta är en vanlig fälla vid migrering från uråldriga teman.

Hur du ersätter den inbyggda jQuery med din egen version

Ibland räcker inte den inbyggda versionen till. Du vill ha jQuery 4.0.0 från ett CDN för de senaste fixarna, eller så behöver du en specifik version för kompatibilitet med ett äldre tillägg. Du kan ersätta den, men gör det försiktigt.

Misstaget: att helt enkelt anropa wp_enqueue_script('jquery', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js'). WordPress skriver INTE över ett redan registrerat handtag. Du får både den inbyggda versionen OCH CDN-versionen på samma sida.

Rätt sekvens: avregistrera först den inbyggda jquery, registrera sedan din egen:

1
function mytheme_use_cdn_jquery() {
2
    // Deregister the built-in jQuery
3
    wp_deregister_script( 'jquery' );
4
 
5
    // Register your own — from CDN
6
    wp_register_script(
7
        'jquery',
8
        'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js',
9
        array(),
10
        '4.0.0',
11
        true
12
    );
13
 
14
    // Enqueue it
15
    wp_enqueue_script( 'jquery' );
16
}
17
add_action( 'wp_enqueue_scripts', 'mytheme_use_cdn_jquery' );

Tre punkter som ofta förbises:

Google Hosted Libraries. Googles alternativa CDN lever fortfarande och hostar jQuery 3.7.1: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js. Fördelen: miljontals webbplatser har redan värmt webbläsarcachar för denna URL. Nackdelen: Google lägger till sina egna headers och uppdaterar inte versioner omedelbart efter release.

cdnjs. Om du behöver jQuery 4.0.0, hämta den från cdn.jsdelivr.net/npm/[email protected]/. cdnjs speglar npm-paketet och serverar det med korrekta CORS-headers.

Avregistrera inte jQuery i publika teman. Om ditt tema ska till WordPress.org-repositoriet, använd den inbyggda jQuery från core. Anledningen är enkel: när en webbplats har både ett tema (med CDN jQuery 4.0.0) och ett tillägg (som förväntar sig jQuery 3.6.0 från core), är det användaren som löser konflikten, inte utvecklaren. I kommersiella teman och anpassade projekt kan du känna dig fri att ersätta den.

NoConflict-läge: när det finns mer än ett bibliotek på sidan

Som standard ockuperar jQuery den globala variabeln $. Problemet är att $ är ett populärt namn: Prototype, MooTools och vissa äldre ramverk använder det också. Om ett tillägg eller ett annat skript också gör anspråk på $, vinner det som laddades sist, och de andra går sönder.

Skydd på en rad i början av ditt skript:

1
var $j = jQuery.noConflict();

Efter detta är $ frisläppt för andra bibliotek, och din kod fungerar genom $j. Fullständigt exempel: en sidopanel med hover-animation:

1
jQuery(document).ready( function( $ ) {
2
    // Here $ is jQuery, but only inside this function
3
    $( '#sidebar li a' ).hover(
4
        function() {
5
            $( this ).stop().animate( { paddingLeft: '20px' }, 400 );
6
        },
7
        function() {
8
            $( this ).stop().animate( { paddingLeft: '0' }, 400 );
9
        }
10
    );
11
} );

Här fungerar $ som jQuery inuti jQuery(document).ready()-closuren, och utanför är den fri för andra. Detta är renare än att skapa $j, $jq och $myJQ-variabler över hela din kod.

När noConflict inte behövs: om din webbplats körs helt på WordPress utan tredjeparts JS-ramverk och alla tillägg är skrivna för wp_enqueue_script, är $ säker. Men att inkludera noConflict i ditt temas standardboilerplate är en god vana som bara kostar en rad.

Vad tilläggsutvecklare bör göra

Om du skriver ett tillägg för offentlig distribution, använd endast wp_enqueue_script med ett beroende på jquery. Ingen wp_deregister_script('jquery') inuti tillägg: du vet inte vilken jQuery-version andra tillägg på samma webbplats förväntar sig.

Det korrekta mönstret för ett tillägg ser ut så här:

1
function myplugin_frontend_scripts() {
2
    wp_enqueue_script(
3
        'myplugin-frontend',
4
        plugins_url( '/js/frontend.js', __FILE__ ),
5
        array( 'jquery' ),
6
        MYPLUGIN_VERSION,
7
        true
8
    );
9
}
10
add_action( 'wp_enqueue_scripts', 'myplugin_frontend_scripts' );

MYPLUGIN_VERSION är tilläggets versionskonstant. Med varje tilläggsuppdatering får användarens webbläsare ett färskt skript istället för ett cachat gammalt.

För admin-skript (endast adminpanel), använd hooken admin_enqueue_scripts. jQuery i admin är också registrerat under samma handtag jquery.

⁉️🤔 Vanliga frågor

Varför fungerar inte min jQuery-kod trots att wp_enqueue_script anropas korrekt?

Den vanligaste orsaken: temat anropar inte wp_head() och wp_footer(). Utan dessa funktioner kan WordPress fysiskt inte infoga <script>-taggar i HTML:en. Öppna header.php. Där ska finnas <?php wp_head(); ?> före </head>. I footer.php ska det finnas <?php wp_footer(); ?> före </body>. Om temat är uråldrigt och dessa anrop saknas, lägg till dem. Detta är säkert. Alla moderna teman och tillägg förlitar sig på wp_head/wp_footer. Utan dem är inte bara skriptladdning trasig utan även SEO-tillägg, typsnitt och strukturerad data.

Kan jag använda jQuery 4.0.0 i WordPress om core levereras med 3.6.0?

Ja, via wp_deregister_script + wp_register_script (se avsnittet ovan). Men notera: jQuery 4.0.0 har släppt stödet för IE 11 och flera föråldrade metoder. Om din webbplats eller ditt tillägg förlitar sig på jQuery Migrate, håll dig till core-versionen eller inkludera Migrate explicit. WordPress rör sig gradvis mot native JavaScript och React för blockredigeraren, men jQuery kommer att finnas kvar i core under lång tid: för många teman och tillägg är beroende av det.

Ett tillägg laddar sin egen jQuery trots att jag redan inkluderat den via functions.php. Vad ska jag göra?

Tillägget har troligen hårdkodat <script src="jquery..."> och kringgår wp_enqueue_script. Detta är tilläggets misstag. Två lösningar: hitta det direkta anropet i tilläggskoden och ersätt det med wp_enqueue_script med ett beroende (om du är villig att patcha tillägget), eller kontakta tilläggsförfattaren och be dem fixa det. Som en tillfällig workaround kan du anropa wp_dequeue_script eller ta bort tilläggets hook, men detta behandlar symtom snarare än orsaken.

Vad är snabbast: jQuery från WordPress core eller från ett CDN?

Om användarens webbläsare redan har cachat jQuery från ett CDN (Google eller cdnjs), laddas CDN-versionen omedelbart med en 304 Not Modified-kod. Om inte, är skillnaden i laddningshastighet mellan core och CDN försumbar för jQuery (cirka 85 KB gzippat). För projekt med hög trafik sparar ett CDN din servers bandbredd; för en typisk WordPress-webbplats är det ingen skillnad.

Bör du överge jQuery till förmån för native JS

Kort svar: det beror på projektet. Komprimerad jQuery 4.0.0 väger cirka 85 KB. Det är inte noll, men det är inte heller anledning till panik. Modern native JS (querySelectorAll, fetch och classList) täcker 90% av vad folk behövde jQuery till 2015. Om du bygger ett nytt tema från grunden och inte är beroende av jQuery-tillägg, överväg vanilla JS. Det är renare och snabbare.

Men om projektet redan har jQuery-beroenden (sliders, gallerier, UI-komponenter för tillägg), komplicera inte saker i onödan. WordPress kommer att ladda jQuery ändå när ett tillägg begär det. Skriv rena wp_enqueue_script-anrop med beroenden, lägg dig inte i cores hantering av laddningsordning, så kommer jQuery att fungera snabbt och förutsägbart.

🔗 wp_enqueue_script-dokumentation | 🔗 wp_deregister_script-dokumentation