При разработке тем и плагинов для WordPress крайне важно правильно подключать стили и скрипты. Ошибки на этом этапе часто приводят к конфликтам между плагинами, проблемам с кэшированием, снижению производительности и нестабильной работе сайта.
WordPress предоставляет собственный механизм управления ресурсами, который позволяет централизованно контролировать загрузку CSS и JavaScript, учитывать зависимости и оптимизировать порядок подключения файлов.
В WordPress существует строго определенный стандарт подключения ресурсов. Использование прямых ссылок в header.php или footer.php считается грубой ошибкой, так как это лишает систему возможности управлять зависимостями и оптимизировать загрузку.
Правильный путь — использование системы очередей через функции wp_enqueue_style и wp_enqueue_script.
Основной хук: wp_enqueue_scripts
Все внешние файлы должны подключаться через специальное событие (хук) wp_enqueue_scripts. Это гарантирует, что ресурсы будут добавлены в нужный момент загрузки страницы.
// Код добавляется в functions.php вашей темы
add_action('wp_enqueue_scripts', 'my_theme_assets_registration');
function my_theme_assets_registration() {
// Здесь регистрируются и подключаются файлы
}
Подключение стилей (CSS) на WordPress
Для добавления CSS используется функция wp_enqueue_style().
Синтаксис:
wp_enqueue_style( $handle, $src, $deps, $ver, $media );
Пример использования:
function my_theme_assets_registration() {
// Основной файл стилей темы (style.css)
wp_enqueue_style('theme-main', get_stylesheet_uri());
// Дополнительный CSS-файл в папке темы
wp_enqueue_style(
'layout-grid',
get_template_directory_uri() . '/assets/css/grid.css',
array(),
'1.2.0',
'all'
);
}
- Handle ('layout-grid') — уникальное название, чтобы система не загрузила файл дважды.
- Deps (array()) — если вашему файлу нужен другой CSS (например, Bootstrap), укажите его handle в массиве.
- Ver ('1.2.0') — версия файла. Она добавляется в конец URL (например, ?ver=1.2.0), что заставляет браузер обновить кэш после изменений в коде.
Подключение скриптов (JavaScript)
Для JS используется функция wp_enqueue_script(). Её ключевое отличие — возможность перенести загрузку в футер сайта.
Синтаксис:
wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
Пример использования:
ffunction my_theme_assets_registration() {
wp_enqueue_script(
'custom-logic',
get_template_directory_uri() . '/assets/js/app.js',
array('jquery'), // Зависимость от jQuery
'2.0.1',
true // Загрузить перед закрывающим тегом </body>
);
}
Совет по производительности: Всегда устанавливайте последний параметр в true, если скрипт не критичен для рендеринга верхней части страницы. Это ускоряет визуальную загрузку сайта.
Использование встроенных библиотек WordPress
WordPress уже включает в себя десятки популярных библиотек (jQuery, Masonry, jQuery UI). Их не нужно загружать из внешних источников или хранить в папке темы. Достаточно вызвать их по имени:
function my_load_libraries() {
wp_enqueue_script('jquery');
wp_enqueue_script('masonry');
}
add_action('wp_enqueue_scripts', 'my_load_libraries');
Передача PHP-данных в JavaScript
Иногда нужно передать динамические данные (например, результат запроса к базе или настройки темы) в JS-файл. Для этого есть функция wp_localize_script().
wp_enqueue_script('api-handler', get_template_directory_uri() . '/js/api.js', array(), null, true);
// Создаем глобальный JS-объект 'themeSettings'
wp_localize_script('api-handler', 'themeSettings', array(
'ajaxUrl' => admin_url('admin-ajax.php'),
'nonce' => wp_create_nonce('theme_nonce'),
'isGuest' => !is_user_logged_in()
));
Условная загрузка (оптимизация)
Не стоит грузить тяжелые скрипты (например, слайдеры или скрипты корзины) на всех страницах. Используйте условные теги WordPress:
function my_optimized_assets() {
// Скрипт загрузится только на странице с ID 42 или на странице "Contact"
if ( is_page( array(42, 'contact') ) ) {
wp_enqueue_script('google-maps', 'https://maps.api.com/js', array(), null, false);
}
}
add_action('wp_enqueue_scripts', 'my_optimized_assets');
Использование функций wp_enqueue_* — это единственный способ гарантировать корректную работу темы. Это позволяет:
- Избегать конфликтов: Плагины и тема используют одну и ту же версию библиотеки.
- Сбрасывать кэш: Через параметр версии.
- Ускорять сайт: Перемещая скрипты в футер и подключая их только там, где они нужны.
Если у вас остались вопросы по теме, задавайте в комментариях!
Про wp_localize_script раздел немного поверхностный. Окей, мы передали данные в JS, а как потом обращаться к этим данным внутри скрипта? Это самое важное, и этого нет.
Справедливо. Объект, который вы передали вторым параметром в wp_localize_script, становится глобальной переменной в JS. Например, в статье создается объект themeSettings. Внутри своего скрипта вы обращаетесь к нему просто: themeSettings.ajaxUrl или themeSettings.nonce. Никаких импортов не нужно, объект уже доступен глобально, потому что WordPress вставляет его inline перед вашим файлом.
Теперь понятно, спасибо 😊
По встроенным библиотекам: список в статье неполный. В 2026 году WordPress тащит за собой еще wp-polyfill, regenerator-runtime и кучу Gutenberg-зависимостей. Как понять, что уже есть в ядре и не нужно подключать самому?
Полный список можно посмотреть прямо в исходниках WordPress, файл wp-includes/script-loader.php. Там все зарегистрированные скрипты с хэндлами. Второй вариант: в консоли браузера на любой WP-странице выполнить Object.keys(wp) и посмотреть, что уже загружено. Для тем удобнее первый способ, чтобы не делать лишних запросов.
Раздел про условную загрузку очень вовремя попался. На прошлом проекте слайдер таскался по всему сайту, хотя я ставила его только для главной. Чуть переписала через is_front_page(), и страницы стали открываться заметно быстрее. Жаль, что не встретила эту статью полгода назад 😢
А что будет, если два плагина зарегистрируют скрипт с одинаковым handle? WordPress просто загрузит его один раз или будет ошибка?
Загрузит один раз, тот, который зарегистрировали первым. Именно поэтому handle должен быть уникальным. Если второй плагин использует тот же handle, но другой файл, его версия файла просто не подключится. Хорошая практика: использовать префикс с именем темы или плагина. Например, не просто 'slider', а 'mytheme-slider'.
Написано, что подключать css и js через header.php это грубая ошибка. Но не объяснено, почему именно. Многие новички так и не поймут, в чем конкретно проблема, пока сами не столкнутся с конфликтом плагинов.
Если добавить или напрямую в header.php, WordPress не знает об этом файле. Значит: нет контроля зависимостей (jQuery может загрузиться дважды или в неправильном порядке), нет инвалидации кэша через параметр версии, плагины не могут деактивировать или заменить ваш скрипт, и условная загрузка невозможна. Всё это и есть практические последствия той самой "грубой ошибки".
Статья актуальная и в 2026 году, подход через wp_enqueue_* не поменялся. Один нюанс: если используете тему на основе блоков (FSE), некоторые стили подключаются через theme.json, а не через functions.php. Для классических тем всё, что описано, работает без изменений.
Хорошо объяснили про зависимости через массив deps. Всегда добавляла jQuery вручную, не знала, что это можно указать параметром и WordPress сам разберется с порядком загрузки. Сэкономит нервы👍
Давно работаю с вордпресс и все равно узнал новое про параметр версии. Никогда не задумывался, что ver в URL это еще и инвалидация кэша, думал просто информация.
Хороший материал. Скажите, а если установить последний параметр wp_enqueue_script в true, это точно не сломает скрипты, которые должны инициализироваться до рендера страницы? Например, что-то для шрифтов или критического CSS.
Да, именно поэтому в статье написано "если скрипт не критичен для рендеринга верхней части страницы". Шрифты и критический CSS подключают через wp_enqueue_style, а не через скрипты. Для JS, который реально нужен в (например, счетчики аналитики или A/B-тесты), оставляйте false или подключайте отдельным хуком. Остальное можно смело в футер.
Наконец-то нормальная статья про wp_enqueue без воды. Сохранил в закладки)