Du installerer en plugin, og den drar med seg sin egen kopi av jQuery. Temaet ditt lastet allerede jQuery via wp_enqueue_script. Pluginen laster det, nok en gang, direkte fra et CDN. På siden: to eller til og med tre versjoner av det samme biblioteket. Konflikter, oppblåst størrelse, uforutsigbar oppførsel.

Problemet er like gammelt som WordPress selv, men det skjer fortsatt: utviklere kopierer og limer inn <script src="jquery.js"> i header.php «fordi det er raskere». Raskere, helt til den første konflikten med en plugin som forventer den innebygde WP-versjonen.

Fra og med 2026 leverer WordPress jQuery 3.6.0 ut av boksen og gir en enkel, deterministisk måte å inkludere det på uten duplisering og uten å spore versjoner manuelt. Nedenfor finner du den eneste riktige tilnærmingen, fra grunnleggende wp_enqueue_script til trygg erstatning med en CDN-versjon og bruk av noConflict-modus.

💡 Rask oversikt:

• Hvordan WordPress allerede laster jQuery og hvorfor du ikke bør gjøre det manuelt
• wp_enqueue_script med jquery-avhengigheten: én linje i functions.php
• Når og hvordan du trygt erstatter den innebygde jQuery med en CDN-versjon (Google / cdnjs)
• noConflict-modus: beskyttelse mot kollisjoner med andre biblioteker
• Tips for temaer og plugins: når du IKKE bør overstyre den innebygde jQuery

JQuery er allerede i kjernen: hva WordPress gjør for deg

Fra og med versjon 3.6 registrerer WordPress jQuery under handtaket jquery. Du trenger ikke å laste ned jquery.min.js, plassere den i temamappen din og inkludere den med en <script>-tagg. Kjernen gjør dette automatisk så snart du spesifiserer jquery i skriptets avhengigheter.

Den gjeldende jQuery-versjonen i WordPress-kjernen er 3.6.0. Den leveres sammen med jQuery Migrate (for bakoverkompatibilitet med gammel kode) og lastes bare når et skript deklarerer jquery som en avhengighet. Ingen avhengigheter betyr at jQuery ikke vises på siden, og nettstedet laster ikke unødvendige ressurser.

Dette er grunnen til at en direkte <script src="/wp-content/themes/mytime/jquery.js"> i header.php er en feil, ikke en snarvei. Du omgår avhengighetssystemet, fjerner WPs evne til å administrere lastingsrekkefølge og får en duplikat når en plugin på legitimt vis ber om jquery via wp_enqueue_script.

Den riktige måten: wp_enqueue_script med en avhengighet

Den grunnleggende mekanikken får plass på én linje inne i wp_enqueue_scripts-hooken. Du skriver skriptet ditt, og WordPress finner ut når og i hvilken rekkefølge alt skal lastes.

Opprett (eller åpne) temaets functions.php og legg til:

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' );

Hva som skjer her:

• mytheme-main er det unike handtaket for skriptet ditt. Finn på ditt eget, med temanavnet som prefiks.
• get_template_directory_uri() . '/js/main.js' er banen til filen. Du kan også bruke en ekstern CDN-URL.
• array( 'jquery' ) er nøkkelpunktet: du forteller WP «skriptet mitt avhenger av jQuery». Kjernen ser dette og setter automatisk jQuery i kø før skriptet ditt. Ingen <script>-tagger i malen.
• '1.0.0' er versjonen for cache-busting. Endre den ved hver skriptoppdatering.
• array( 'strategy' => 'defer', 'in_footer' => true ): siden WordPress 6.3 aksepterer $args-parameteren en array. defer betyr «kjør skriptet etter at DOM-en er bygget, men før DOMContentLoaded». in_footer plasserer skriptet i footeren.

Den gamle syntaksen med en boolsk femteparameter (true = i footer) fungerer fortsatt, men for nye prosjekter bør du bruke array-syntaksen. Den er mer lesbar og gir deg kontroll over async/defer.

Bekreft at temaet ditt kaller wp_head() før avsluttende </head> og wp_footer() før </body>. Uten disse kallene vil wp_enqueue_script rett og slett ikke fungere. Dette er en vanlig felle når man migrerer fra eldgamle temaer.

Hvordan erstatte den innebygde jQuery med din egen versjon

Noen ganger er ikke den innebygde versjonen nok. Du vil ha jQuery 4.0.0 fra et CDN for de nyeste rettelsene, eller du trenger en spesifikk versjon for kompatibilitet med en gammel plugin. Du kan erstatte den, men vær forsiktig.

Feilen: å bare kalle wp_enqueue_script('jquery', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js'). WordPress overskriver IKKE et allerede registrert handtak. Du får både den innebygde versjonen OG CDN-versjonen på samme side.

Riktig rekkefølge: først avregistrer den innebygde jquery, og registrer deretter 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 ofte overses:

Google Hosted Libraries. Googles alternative CDN lever fortsatt og hoster jQuery 3.7.1: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js. Fordelen: millioner av nettsteder har allerede varmet opp nettlesercachen for denne URL-en. Ulempen: Google legger til sine egne headere og oppdaterer ikke versjoner umiddelbart etter lansering.

cdnjs. Hvis du trenger jQuery 4.0.0, hent den fra cdn.jsdelivr.net/npm/[email protected]/. cdnjs speiler npm-pakken og serverer den med korrekte CORS-headere.

Ikke avregistrer jQuery i offentlige temaer. Hvis temaet ditt skal til WordPress.org-repositoriet, bruk den innebygde jQuery fra kjernen. Grunnen er enkel: når et nettsted har både et tema (med CDN jQuery 4.0.0) og en plugin (som forventer jQuery 3.6.0 fra kjernen), er det brukeren som løser konflikten, ikke utvikleren. I kommersielle temaer og tilpassede prosjekter kan du gjerne erstatte den.

NoConflict-modus: når det er mer enn ett bibliotek på siden

Som standard okkuperer jQuery den globale variabelen $. Problemet er at $ er et populært navn: Prototype, MooTools og noen eldre rammeverk bruker det også. Hvis en plugin eller et annet skript også krever $, vinner det som ble lastet sist, og de andre slutter å fungere.

Beskyttelse på én linje i begynnelsen av skriptet ditt:

1
var $j = jQuery.noConflict();

Etter dette er $ frigitt for andre biblioteker, og koden din fungerer gjennom $j. Fullstendig eksempel: en sidebar med hover-animasjon:

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
} );

Her fungerer $ som jQuery inne i jQuery(document).ready()-lukkingen, og utenfor er den fri for andre. Dette er renere enn å spre $j-, $jq- og $myJQ-variabler gjennom hele koden.

Når noConflict ikke er nødvendig: hvis nettstedet ditt utelukkende kjører på WordPress uten tredjeparts JS-rammeverk og alle plugins er skrevet for wp_enqueue_script, er $ trygg. Men å inkludere noConflict i temaets standard boilerplate er en god vane som bare koster én linje.

Hva plugin-utviklere bør gjøre

Hvis du skriver en plugin for offentlig distribusjon, bruk kun wp_enqueue_script med en avhengighet til jquery. Ingen wp_deregister_script('jquery') inne i plugins: du vet ikke hvilken jQuery-versjon andre plugins på samme nettsted forventer.

Det korrekte mønsteret for en plugin ser slik ut:

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 er pluginens versjonskonstant. Ved hver pluginoppdatering får brukerens nettleser et ferskt skript i stedet for et bufret gammelt ett.

For admin-skript (kun adminpanelet), bruk admin_enqueue_scripts-hooken. jQuery i admin er også registrert under det samme handtaket jquery.

⁉️🤔 Ofte stilte spørsmål

Hvorfor fungerer ikke jQuery-koden min selv om wp_enqueue_script kalles riktig?

Den vanligste årsaken: temaet kaller ikke wp_head() og wp_footer(). Uten disse funksjonene kan WordPress fysisk ikke sette inn <script>-tagger i HTML-en. Åpne header.php. Det skal stå <?php wp_head(); ?> før </head>. I footer.php skal det stå <?php wp_footer(); ?> før </body>. Hvis temaet er eldgammelt og disse kallene mangler, legg dem til. Dette er trygt. Alle moderne temaer og plugins er avhengige av wp_head/wp_footer. Uten dem er ikke bare skriptlasting ødelagt, men også SEO-plugins, fonter og strukturert data.

Kan jeg bruke jQuery 4.0.0 i WordPress hvis kjernen leveres med 3.6.0?

Ja, via wp_deregister_script + wp_register_script (se avsnittet over). Men merk: jQuery 4.0.0 har droppet støtte for IE 11 og flere utdaterte metoder. Hvis nettstedet eller pluginen din er avhengig av jQuery Migrate, hold deg til kjerneversjonen eller inkluder Migrate eksplisitt. WordPress beveger seg gradvis mot native JavaScript og React for blokkredigereren, men jQuery vil forbli i kjernen i lang tid: for mange temaer og plugins er avhengige av det.

En plugin laster sin egen jQuery selv om jeg allerede inkluderte den via functions.php. Hva bør jeg gjøre?

Pluginen har sannsynligvis hardkodet <script src="jquery..."> og omgått wp_enqueue_script. Dette er pluginens feil. To løsninger: finn det direkte kallet i plugin-koden og erstatt det med wp_enqueue_script med en avhengighet (hvis du er villig til å patche pluginen), eller kontakt plugin-forfatteren og be dem fikse det. Som en midlertidig løsning kan du kalle wp_dequeue_script eller fjerne pluginens hook, men dette behandler symptomer snarere enn årsaken.

Hva er raskest: jQuery fra WordPress-kjernen eller fra et CDN?

Hvis brukerens nettleser allerede har bufret jQuery fra et CDN (Google eller cdnjs), lastes CDN-versjonen umiddelbart med en 304 Not Modified-kode. Hvis ikke, er forskjellen i lastehastighet mellom kjerne og CDN ubetydelig for jQuery (omtrent 85 KB gzippet). For prosjekter med høy trafikk sparer et CDN serverens båndbredde; for et typisk WordPress-nettsted er det ingen forskjell.

Bør du forlate jQuery til fordel for native JS

Kort svar: det avhenger av prosjektet. Komprimert jQuery 4.0.0 veier omtrent 85 KB. Det er ikke null, men det er heller ingen grunn til panikk. Moderne native JS (querySelectorAll, fetch og classList) dekker 90% av det folk trengte jQuery til i 2015. Hvis du bygger et nytt tema fra bunnen av og ikke er avhengig av jQuery-plugins, bør du vurdere vanilla JS. Det er renere og raskere.

Men hvis prosjektet allerede har jQuery-avhengigheter (slidere, gallerier, plugin UI-komponenter), ikke overkompliser ting. WordPress vil uansett laste jQuery når en plugin ber om det. Skriv rene wp_enqueue_script-kall med avhengigheter, ikke forstyrr kjernens administrasjon av lastingsrekkefølge, så vil jQuery fungere raskt og forutsigbart.

🔗 wp_enqueue_script-dokumentasjon | 🔗 wp_deregister_script-dokumentasjon