Vous installez une extension et elle embarque sa propre copie de jQuery. Votre thème a déjà chargé jQuery via wp_enqueue_script. L’extension, de son côté, le charge directement depuis un CDN. Résultat sur la page: deux, voire trois versions de la même bibliothèque. Conflits, poids excessif, comportement imprévisible.

Le problème est aussi vieux que WordPress lui-même, et pourtant il persiste: des développeurs copient-collent <script src="jquery.js"> dans header.php «parce que c’est plus rapide». Plus rapide, jusqu’au premier conflit avec une extension qui attend la version native de WP.

En 2026, WordPress livre jQuery 3.6.0 en standard et propose une méthode simple et déterministe pour l’inclure sans duplication et sans gérer les versions manuellement. Voici la seule approche correcte, depuis l’appel de base wp_enqueue_script jusqu’au remplacement sécurisé par une version CDN en passant par le mode noConflict.

💡 Aperçu rapide:

• Comment WordPress charge déjà jQuery et pourquoi vous ne devriez pas le faire manuellement
• wp_enqueue_script avec la dépendance jquery: une ligne dans functions.php
• Quand et comment remplacer en toute sécurité le jQuery intégré par une version CDN (Google / cdnjs)
• Le mode noConflict: une protection contre les collisions avec d’autres bibliothèques
• Conseils pour les thèmes et les extensions: quand vous ne devez PAS surcharger le jQuery intégré

JQuery est déjà dans le cœur: ce que WordPress fait pour vous

À partir de la version 3.6, WordPress enregistre jQuery sous le handle jquery. Vous n’avez pas besoin de télécharger jquery.min.js, de le placer dans le dossier de votre thème et de l’inclure avec une balise <script>. Le cœur le fait automatiquement dès que vous spécifiez jquery dans les dépendances de votre script.

La version actuelle de jQuery dans le cœur de WordPress est la 3.6.0. Elle est livrée avec jQuery Migrate (pour la rétrocompatibilité avec le code ancien) et ne se charge que lorsqu’un script déclare jquery comme dépendance. Pas de dépendance signifie que jQuery n’apparaît pas sur la page et que le site ne charge pas de ressources inutiles.

C’est pourquoi un <script src="/wp-content/themes/mytime/jquery.js"> écrit en dur dans header.php est une erreur, pas un raccourci. Vous contournez le système de dépendances, vous retirez à WP sa capacité à gérer l’ordre de chargement et vous obtenez un doublon quand une extension demande légitimement jquery via wp_enqueue_script.

La bonne méthode: wp_enqueue_script avec une dépendance

Le mécanisme de base tient en une ligne à l’intérieur du hook wp_enqueue_scripts. Vous écrivez votre script et WordPress détermine quand et dans quel ordre tout charger.

Créez (ou ouvrez) le fichier functions.php de votre thème et ajoutez:

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

Ce qui se passe ici:

• mytheme-main est le handle unique de votre script. Inventez le vôtre, préfixé par le nom du thème.
• get_template_directory_uri() . '/js/main.js' est le chemin vers le fichier. Vous pouvez aussi utiliser une URL de CDN externe.
• array( 'jquery' ) est le point clé: vous indiquez à WP «mon script dépend de jQuery». Le cœur le voit et met automatiquement jQuery en file d’attente avant votre script. Aucune balise <script> dans le template.
• '1.0.0' est la version pour l’invalidation du cache. Changez-la à chaque mise à jour du script.
• array( 'strategy' => 'defer', 'in_footer' => true ): depuis WordPress 6.3, le paramètre $args accepte un tableau. defer signifie «exécuter le script une fois le DOM construit mais avant DOMContentLoaded». in_footer place le script dans le pied de page.

L’ancienne syntaxe avec un cinquième paramètre booléen (true = dans le footer) fonctionne encore, mais pour les nouveaux projets, utilisez la syntaxe en tableau. Elle est plus lisible et vous donne le contrôle sur async/defer.

Vérifiez que votre thème appelle wp_head() avant la balise fermante </head> et wp_footer() avant </body>. Sans ces appels, wp_enqueue_script ne fonctionnera tout simplement pas. C’est un piège fréquent lors de la migration depuis des thèmes anciens.

Comment remplacer le jQuery intégré par votre propre version

Parfois, la version native ne suffit pas. Vous voulez jQuery 4.0.0 depuis un CDN pour bénéficier des derniers correctifs, ou vous avez besoin d’une version spécifique pour la compatibilité avec une extension ancienne. Vous pouvez la remplacer, mais avec précaution.

L’erreur: se contenter d’appeler wp_enqueue_script('jquery', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js'). WordPress ne remplace PAS un handle déjà enregistré. Vous obtiendrez à la fois la version native ET la version CDN sur la même page.

La séquence correcte: d’abord désenregistrer le jquery natif, puis enregistrer le vôtre:

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

Trois points souvent négligés:

Google Hosted Libraries. Le CDN alternatif de Google est toujours actif et héberge jQuery 3.7.1: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js. L’avantage: des millions de sites ont déjà réchauffé les caches des navigateurs pour cette URL. L’inconvénient: Google ajoute ses propres en-têtes et ne met pas à jour les versions immédiatement après leur sortie.

cdnjs. Si vous avez besoin de jQuery 4.0.0, récupérez-le depuis cdn.jsdelivr.net/npm/[email protected]/. cdnjs est un miroir du paquet npm et le sert avec les en-têtes CORS appropriés.

Ne désenregistrez pas jQuery dans les thèmes publics. Si votre thème est destiné au dépôt WordPress.org, utilisez le jQuery natif du cœur. La raison est simple: quand un site a à la fois un thème (avec jQuery 4.0.0 depuis un CDN) et une extension (qui attend jQuery 3.6.0 du cœur), c’est l’utilisateur qui résout le conflit, pas le développeur. Dans les thèmes commerciaux et les projets sur mesure, n’hésitez pas à le remplacer.

Le mode noConflict: quand il y a plus d’une bibliothèque sur la page

Par défaut, jQuery occupe la variable globale $. Le problème, c’est que $ est un nom populaire: Prototype, MooTools et certains frameworks anciens l’utilisent aussi. Si une extension ou un autre script revendique également $, le dernier chargé l’emporte et les autres cassent.

La protection tient en une ligne au début de votre script:

1
var $j = jQuery.noConflict();

Après cela, $ est libéré pour les autres bibliothèques et votre code fonctionne via $j. Exemple complet: une barre latérale avec une animation au survol:

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

Ici, $ fonctionne comme jQuery à l’intérieur de la fermeture jQuery(document).ready(), et à l’extérieur il est libre pour les autres. C’est plus propre que de disséminer des variables $j, $jq et $myJQ dans tout votre code.

Quand noConflict n’est pas nécessaire: si votre site tourne entièrement sous WordPress sans frameworks JS tiers et que toutes les extensions sont écrites pour wp_enqueue_script, $ est sûr. Mais inclure noConflict dans le code standard de votre thème est une bonne habitude qui ne coûte qu’une ligne.

Ce que les développeurs d’extensions doivent faire

Si vous écrivez une extension destinée à la distribution publique, utilisez uniquement wp_enqueue_script avec une dépendance à jquery. Pas de wp_deregister_script('jquery') dans les extensions: vous ne savez pas quelle version de jQuery les autres extensions sur le même site attendent.

Le modèle correct pour une extension ressemble à ceci:

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 est la constante de version de l’extension. À chaque mise à jour de l’extension, le navigateur de l’utilisateur reçoit un script frais au lieu d’un ancien en cache.

Pour les scripts d’administration (panneau d’administration uniquement), utilisez le hook admin_enqueue_scripts. jQuery dans l’administration est également enregistré sous le même handle jquery.

⁉️🤔 Questions fréquentes

Pourquoi mon code jQuery ne fonctionne-t-il pas alors que wp_enqueue_script est appelé correctement?

La cause la plus fréquente: le thème n’appelle pas wp_head() et wp_footer(). Sans ces fonctions, WordPress ne peut physiquement pas insérer les balises <script> dans le HTML. Ouvrez header.php. Il doit y avoir <?php wp_head(); ?> avant </head>. Dans footer.php, il doit y avoir <?php wp_footer(); ?> avant </body>. Si le thème est ancien et que ces appels sont absents, ajoutez-les. C’est sans risque. Tous les thèmes et extensions modernes reposent sur wp_head/wp_footer. Sans eux, non seulement le chargement des scripts est cassé, mais aussi les extensions SEO, les polices et les données structurées.

Puis-je utiliser jQuery 4.0.0 dans WordPress si le cœur est livré avec la 3.6.0?

Oui, via wp_deregister_script + wp_register_script (voir la section ci-dessus). Mais notez: jQuery 4.0.0 a abandonné la prise en charge d’IE 11 et plusieurs méthodes obsolètes. Si votre site ou votre extension dépend de jQuery Migrate, restez sur la version du cœur ou incluez Migrate explicitement. WordPress évolue progressivement vers le JavaScript natif et React pour l’éditeur de blocs, mais jQuery restera dans le cœur pour longtemps: trop de thèmes et d’extensions en dépendent.

Une extension charge son propre jQuery alors que je l’ai déjà inclus via functions.php. Que dois-je faire?

L’extension a probablement écrit en dur <script src="jquery..."> en contournant wp_enqueue_script. C’est une erreur de l’extension. Deux solutions: trouvez l’appel direct dans le code de l’extension et remplacez-le par wp_enqueue_script avec une dépendance (si vous êtes prêt à patcher l’extension), ou contactez l’auteur de l’extension pour lui demander de corriger cela. Comme solution de contournement temporaire, vous pouvez appeler wp_dequeue_script ou supprimer le hook de l’extension, mais cela traite les symptômes plutôt que la cause.

Qu’est-ce qui est le plus rapide: jQuery depuis le cœur de WordPress ou depuis un CDN?

Si le navigateur de l’utilisateur a déjà mis en cache jQuery depuis un CDN (Google ou cdnjs), la version CDN se charge instantanément avec un code 304 Not Modified. Sinon, la différence de vitesse de chargement entre le cœur et un CDN est négligeable pour jQuery (environ 85 Ko compressés). Pour les projets à fort trafic, un CDN économise la bande passante de votre serveur; pour un site WordPress classique, il n’y a pas de différence.

Faut-il abandonner jQuery au profit du JS natif

En bref: cela dépend du projet. jQuery 4.0.0 compressé pèse environ 85 Ko. Ce n’est pas zéro, mais ce n’est pas non plus une raison de paniquer. Le JS natif moderne (querySelectorAll, fetch et classList) couvre 90% de ce pour quoi on avait besoin de jQuery en 2015. Si vous construisez un nouveau thème from scratch et que vous ne dépendez pas d’extensions jQuery, envisagez le JavaScript vanilla. C’est plus propre et plus rapide.

Mais si le projet a déjà des dépendances jQuery (sliders, galeries, composants d’interface d’extensions), ne compliquez pas les choses. WordPress chargera de toute façon jQuery quand une extension le demandera. Écrivez des appels wp_enqueue_script propres avec des dépendances, n’interférez pas avec la gestion de l’ordre de chargement du cœur, et jQuery fonctionnera de manière rapide et prévisible.

🔗 Documentation wp_enqueue_script | 🔗 Documentation wp_deregister_script