Ви встановлюєте плагін, а він тягне свою копію jQuery. Ваша тема вже завантажила jQuery через wp_enqueue_script. Плагін, ще раз, напряму з CDN. На сторінці, дві, а то й три версії однієї бібліотеки. Конфлікти, роздутий розмір, непередбачувана поведінка.

Проблема стара, як сам WordPress, але досі відтворюється: розробники копіпастять <script src="jquery.js"> у header.php, «бо так швидше». Швидше, до першого конфлікту з плагіном, який очікує рідну WP-версію.

З 2026 року WordPress постачає jQuery 3.6.0 з коробки та дає простий, детермінований спосіб підключення, без дублювання, без ручного відстежування версій. Нижче, єдино правильний шлях, від базового wp_enqueue_script до безпечної заміни на CDN-версію та режиму noConflict.

💡 Швидкий огляд:

• Як WordPress уже завантажує jQuery і чому не треба робити це вручну
• wp_enqueue_script із залежністю jquery, один рядок у functions.php
• Коли і як безпечно замінити вбудовану jQuery на CDN-версію (Google / cdnjs)
• Режим noConflict: захист від колізій з іншими бібліотеками
• Поради для тем і плагінів: коли скасовувати вбудовану jQuery НЕ треба

JQuery вже в ядрі: що WordPress робить за вас

Починаючи з версії 3.6, WordPress реєструє jQuery під handle-ом jquery. Вам не потрібно завантажувати jquery.min.js, класти в папку теми та підключати <script>-тегом, ядро зробить це само, щойно ви вкажете jquery у залежностях свого скрипту.

Поточна версія jQuery в ядрі WordPress, 3.6.0. Вона йде в комплекті з jQuery Migrate (для зворотної сумісності зі старим кодом) і завантажується, тільки якщо якийсь скрипт оголосив jquery залежністю. Немає залежностей, jQuery на сторінку не потрапляє, сайт не вантажить зайвого.

Ось чому прямий <script src="/wp-content/themes/mytime/jquery.js"> у header.php — це помилка, а не shortcut. Ви обходите систему залежностей, позбавляєте WP можливості керувати черговістю й отримуєте дублікат, коли плагін чесно попросить jquery через wp_enqueue_script.

Правильний спосіб: wp_enqueue_script із залежністю

Базова механіка вміщується в один рядок усередині хука wp_enqueue_scripts. Ви пишете свій скрипт, а WordPress сам розбирається, коли і в якому порядку все завантажити.

Створіть (або відкрийте) functions.php вашої теми та додайте:

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

Що тут відбувається:

• mytheme-main, унікальний handle вашого скрипту. Придумайте свій, із префіксом теми.
• get_template_directory_uri() . '/js/main.js', шлях до файлу. Можна й зовнішній CDN-URL.
• array( 'jquery' ), ключовий момент: ви кажете WP «мій скрипт залежить від jQuery». Ядро бачить це й автоматично ставить jQuery у чергу перед вашим скриптом. Жодних <script>-тегів у шаблоні.
• '1.0.0', версія для cache busting. Змінюйте за кожного оновлення скрипту.
• array( 'strategy' => 'defer', 'in_footer' => true ), з WordPress 6.3 параметр $args приймає масив. defer означає «виконати скрипт після побудови DOM, але до DOMContentLoaded». in_footer ставить скрипт у футер.

Старий синтаксис із булевим п’ятим параметром (true = у футер) усе ще працює, але для нових проєктів використовуйте масив, він читається зрозуміліше й дає контроль над async/defer.

Перевірте, що ваша тема викликає wp_head() перед закривним </head> і wp_footer() перед </body>. Без цих викликів wp_enqueue_script просто не спрацює — це часта пастка під час переходу з давніх тем.

Як замінити вбудовану jQuery своєю версією

Іноді рідної версії недостатньо. Ви хочете jQuery 4.0.0 з CDN заради найсвіжіших виправлень, або вам потрібна конкретна версія для сумісності з legacy-плагіном. Замінити, можна, але обережно.

Помилка: просто викликати wp_enqueue_script('jquery', 'https://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js'). WordPress НЕ перезаписує вже зареєстрований handle, ви отримаєте рідну версію І CDN-версію на одній сторінці.

Правильна послідовність: спочатку зняти рідний jquery з реєстрації, потім зареєструвати свій:

1
function mytheme_use_cdn_jquery() {
2
    // Снимаем встроенную jQuery
3
    wp_deregister_script( 'jquery' );
4
 
5
    // Регистрируем свою — из 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
    // Ставим в очередь
15
    wp_enqueue_script( 'jquery' );
16
}
17
add_action( 'wp_enqueue_scripts', 'mytheme_use_cdn_jquery' );

Три моменти, про які часто забувають:

Google Hosted Libraries. Альтернативний CDN від Google досі живий і тримає jQuery 3.7.1: https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js. Плюс, мільйони сайтів уже гріють кеш браузера під цей URL. Мінус, Google додає свої заголовки й оновлює версії не одразу після релізу.

cdnjs. Якщо потрібна jQuery 4.0.0, беріть із cdn.jsdelivr.net/npm/[email protected]/. cdnjs дзеркалює npm-пакет і віддає з правильними CORS-заголовками.

Не скасовуйте jQuery у публічних темах. Якщо ваша тема йде в репозиторій WordPress.org, використовуйте рідну jQuery з ядра. Причина проста: коли на одному сайті зустрічаються тема (з CDN jQuery 4.0.0) і плагін (що очікує jQuery 3.6.0 з ядра), конфлікт вирішує користувач, а не розробник. У комерційних темах і кастомних проєктах замінюйте сміливо.

Режим noConflict: коли на сторінці більше однієї бібліотеки

jQuery за замовчуванням займає глобальну змінну $. Проблема в тому, що $, популярне ім’я: його використовують Prototype, MooTools і деякі legacy-фреймворки. Якщо плагін або другий скрипт теж претендує на $, перемагає той, хто завантажився останнім, решта ламаються.

Захист, одним рядком на початку вашого скрипту:

1
var $j = jQuery.noConflict();

Після цього $ звільняється для інших бібліотек, а ваш код працює через $j. Повний приклад, бічна панель з анімацією під час наведення:

1
jQuery(document).ready( function( $ ) {
2
    // Здесь $ — это jQuery, но только внутри этой функции
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
} );

Тут $ працює як jQuery усередині замикання jQuery(document).ready(), а зовні, вільний для інших. Це чистіше, ніж плодити змінні $j, $jq і $myJQ по всьому коду.

Коли noConflict не потрібен: якщо ваш сайт повністю на WordPress, без сторонніх JS-фреймворків, і всі плагіни написані під wp_enqueue_script, $ безпечний. Але вмикати noConflict у стандартний boilerplate теми, хороша звичка, ціна якої, один рядок.

Що робити розробнику плагінів

Якщо ви пишете плагін для публічного розповсюдження, використовуйте тільки wp_enqueue_script із залежністю від jquery. Жодних wp_deregister_script('jquery') усередині плагінів: ви не знаєте, яку версію jQuery очікують інші плагіни на тому самому сайті.

Правильний патерн для плагіна виглядає так:

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, константа версії плагіна. За кожного оновлення плагіна браузер користувача отримає свіжий скрипт, а не закешований старий.

Адміністративні скрипти (тільки в адмінці) вішайте на хук admin_enqueue_scripts, jQuery в адмінці теж зареєстрована під тим самим handle jquery.

⁉️🤔 Часті запитання

Чому мій jQuery-код не працює, хоча wp_enqueue_script викликано правильно?

Найчастіша причина, тема не викликає wp_head() і wp_footer(). Без цих функцій WordPress фізично не може вставити <script>-теги в HTML. Відкрийте header.php, там має бути <?php wp_head(); ?> перед </head>. У footer.php, <?php wp_footer(); ?> перед </body>. Якщо тема давня і цих викликів немає, додайте — це безпечно. Усі сучасні теми й плагіни покладаються на wp_head/wp_footer, без них зламане не тільки підключення скриптів, а й SEO-плагіни, шрифти та мікророзмітка.

Чи можна використовувати jQuery 4.0.0 у WordPress, якщо ядро йде з 3.6.0?

Так, через wp_deregister_script + wp_register_script (див. розділ вище). Але врахуйте: jQuery 4.0.0 прибрала підтримку IE 11 і низку застарілих методів. Якщо ваш сайт або плагін покладається на jQuery Migrate, залишайтеся на версії з ядра або підключіть Migrate явно. WordPress поступово рухається в бік нативного JavaScript і React для редактора блоків, але jQuery залишиться в ядрі ще довго: надто багато тем і плагінів від неї залежать.

Плагін тягне свою jQuery, хоча я вже підключив через functions.php, що робити?

Плагін, найімовірніше, жорстко вставив <script src="jquery..."> в обхід wp_enqueue_script. Це помилка плагіна. Рішень два: знайти в коді плагіна прямий виклик і замінити на wp_enqueue_script із залежністю (якщо ви готові патчити плагін), або написати автору плагіна з проханням виправити. Як тимчасовий милицю можна викликати wp_dequeue_script або видалити хук плагіна, але це лікує симптоми, а не причину.

Що швидше: jQuery з ядра WordPress чи з CDN?

Якщо браузер користувача вже закешував jQuery з CDN (Google або cdnjs), CDN-версія завантажиться миттєво, з кодом 304 Not Modified. Якщо ні, різниця в швидкості завантаження між ядром і CDN є зневажливо малою для jQuery (файл близько 85 КБ у gzip). Для високонавантажених проєктів CDN економить трафік вашого сервера; для типового сайту на WordPress різниці немає.

Чи варто відмовлятися від jQuery на користь нативного JS

Коротка відповідь: залежить від проєкту. jQuery 4.0.0 у стисненому вигляді важить близько 85 КБ — це не нуль, але й не привід для паніки. Сучасний нативний JS: querySelectorAll, fetch і classList покривають 90% того, заради чого брали jQuery у 2015-му. Якщо ви пишете нову тему з нуля й не залежите від jQuery-плагінів, розгляньте vanilla JS, він чистіший і швидший.

Але якщо в проєкті вже є jQuery-залежності (слайдери, галереї, UI-компоненти плагінів), не ускладнюйте. WordPress однаково завантажить jQuery, коли плагін її запросить. Пишіть акуратні wp_enqueue_script із залежностями, не заважайте ядру керувати черговістю, і jQuery працюватиме швидко й передбачувано.

🔗 Документація wp_enqueue_script | 🔗 Документація wp_deregister_script