1 981 Дизайнерам и разработчикам очень важно знать, как правильно добавлять JavaScript и CSS файлы в свои темы и плагины WordPress. Если вы не будете придерживаться правильных методов, то вы рискуете помешать работе других продуктов.
Эта статья послужит вам руководством, в котором будут описаны лучшие методы, позволяющие добиться лучшего результата.
Лучшие методы для каждого
Если вы когда-либо разрабатывали тему или плагин WordPress, вы, вероятно, сталкивались с несколькими различными способами добавления JavaScript и CSS. Есть много методов, которые, казалось бы, работают в определённых обстоятельствах. Но есть один первичный метод, рекомендуемый в . Это предпочтительный способ, и он гарантирует, что ваша тема или плагин будет работать в любом случае, если, конечно, везде использован правильный код.
Однако в Кодексе, возможно, есть некоторые непонятные моменты. В них мы и постараемся внести ясность.
Что в комплекте?
Когда вы загружаете WordPress, набор общих библиотек JavaScript уже включён в комплект, и вы можете использовать их в своих JavaScript-разработках. Список включённых библиотек вы можете найти в статье Кодекса WordPress.
Все эти библиотеки установлены, но WordPress загружает только те из них, которые ему нужны, и которые указаны в разделе администрации. Если вы пишете JavaScript программу, которая использует одну из этих библиотек, вам нужно указать WordPress, что вашему скрипту нужна определённая библиотека.
Укажите WordPress свои скрипты и что им необходимо для работы
Когда вы пишете JavaScript-код для WordPress, стоит подумать о следующих вещах:
- Есть ли включённая библиотека, которую я могу использовать?
- Могу ли я использовать именно ту версию библиотеки, которая входит в комплект?
- Нужно ли мне загружать скрипт на страницах сайта или в разделе администрации?
- На каких страницах сайта и страницах администрации мне нужно загружать скрипт?
Ответы на эти вопросы помогут вам узнать, что нужно сделать для регистрации и загрузки вашего скрипта. Всё это реализуется при помощи функции , вот пример её использования согласно Кодексу WordPress:
|
1 |
wp_register_script( $handle, $src, $deps, $ver, $in_footer ); |
Итак, что за переменные мы здесь использовали, и всегда ли они нам нужны? (Это описывается в Кодексе, поэтому мы не будем вдаваться в подробности)
$handle– название скрипта, которое вам потребуется, чтобы обратиться к нему, когда вам нужно поставить его в очередь; это обязательная переменная$src– путь к исходному файлу скрипта$deps– массив, содержащий$handleвсех скриптов, от которых зависит ваш скрипт (т.е. «зависимость»)$ver– номер версии, используется для получения правильной версии скрипта, независимо от кэширования. По умолчанию устанавливается на номер версии WordPress$in_footer– используется для загрузки скрипта в футере. Возможные значения —trueилиfalse. По умолчанию установленоfalse, и скрипт загружается вместе с , а если значениеtrueскрипт будет загружен в футере, вместе с
Немного о кэшировании
Браузеры помнят, какие скрипты и таблицы стилей они загружали для определённого сайта на основе URL скрипта или таблицы стилей. Если вы изменяете URL, даже просто добавляя строку запроса, браузер предполагает, что это новый файл и заново загружает его. Это можно использовать, когда вы вносите изменения в свой скрипт. При этом следует изменить номер версии скрипта, чтобы браузер клиента загрузил его с сервера, а не из кэша.
Теперь несколько примеров
Вот самый простой пример загрузки пользовательского скрипта:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function wptuts_scripts_basic() { // Так скрипт регистрируется для плагина: wp_register_script( 'custom-script', plugins_url( '/js/custom-script.js', __FILE__ ) ); // или // Так скрипт регистрируется для темы: wp_register_script( 'custom-script', get_template_directory_uri() . '/js/custom-script.js' ); // Вы можете поставить скрипт в очередь как для плагина так и для темы: wp_enqueue_script( 'custom-script' ); } add_action( 'wp_enqueue_scripts', 'wptuts_scripts_basic' ); |
Во-первых, мы регистрируем скрипт, чтобы WordPress мог определить, о чём идёт речь. Есть разные способы указания пути для JavaScript файла в зависимости от того, создаёте ли вы плагин или тему, здесь указаны оба примера. Затем мы ставим скрипт в очередь на добавление его в HTML код страницы, когда он будет сгенерирован, по умолчанию скрипты добавляются в раздел <head>, где расположена функция wp_head().
Так мы должны получить следующий результат:
|
1 |
<script type="text/javascript" src="http://yourdomain.com/wp-content/plugins/yourplugin/js/custom-script.js?ver=3.3.1"></script> |
Теперь если наш скрипт полагается на одну из библиотек, включённых в WordPress, таких как jQuery, вы можете сделать достаточно простое изменение в коде:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function wptuts_scripts_with_jquery() { // Регистрируем скрипт для темы: wp_register_script( 'custom-script', plugins_url( '/js/custom-script.js', __FILE__ ), array( 'jquery' ) ); // или // Регистрируем скрипт для плагина: wp_register_script( 'custom-script', get_template_directory_uri() . '/js/custom-script.js', array( 'jquery' ) ); // Ставим скрипт в очередь как для темы, так и для плагина: wp_enqueue_script( 'custom-script' ); } add_action( 'wp_enqueue_scripts', 'wptuts_scripts_with_jquery' ); |
Примечание: По умолчанию, jQuery загружается в режиме noConflict для предотвращения конфликтов с другими библиотеками (такими как Prototype). , если вы раньше не имели с этим дело.
Теперь разберём, что мы здесь сделали. Сначала добавляем массив с дескриптором ‘jquery’ в качестве значения переменной $deps. Массив используется потому, что ваш скрипт может зависеть от нескольких библиотек. Если ваш скрипт использует jQuery и jQuery UI, то вы добавляете jQuery UI в массив вот так: array( 'jquery', 'jquery-ui-core' )
Изменения вступили в силу и вы можете видеть, что jQuery также был добавлен в раздел <head> страницы:
|
1 2 |
<script type='text/javascript' src='http://yourdomain.com/wp-includes/js/jquery/jquery.js?ver=1.7.1'></script> <script type='text/javascript' src='http://yourdomain.com/wp-content/plugins/yourplugin/js/custom-script.js?ver=3.3.1'></script> |
Давайте посмотрим на пример, в котором использованы все параметры:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function wptuts_scripts_with_the_lot() { // Регистрируем скрипт для плагина: wp_register_script( 'custom-script', plugins_url( '/js/custom-script.js', __FILE__ ), array( 'jquery', 'jquery-ui-core' ), '20120208', true ); // или // Регистрируем скрипт для темы: wp_register_script( 'custom-script', get_template_directory_uri() . '/js/custom-script.js', array( 'jquery', 'jquery-ui-core' ), '20120208', true ); // Ставим скрипт в очередь как для темы, так и для плагина: wp_enqueue_script( 'custom-script' ); } add_action( 'wp_enqueue_scripts', 'wptuts_scripts_with_the_lot' ); |
OK, так мы добавили версию и определили, что скрипт должен загружаться в футере. В качестве версии мы выбрали сегодняшнюю дату, потому что так легче следить за версиями, но вы можете использовать любую нумерацию. Теперь у нас немного другой результат: jQuery выведен в <head>, а наш скрипт наряду с jQuery UI подключается прямо перед закрывающимся тегом </body>:
|
1 2 3 4 5 6 7 8 9 10 |
<head> ... <script type='text/javascript' src='http://yourdomain.com/wp-includes/js/jquery/jquery.js?ver=1.7.1'></script> ... </head> <body> ... <script type='text/javascript' src='http://yourdomain.com/wp-includes/js/jquery/ui/jquery.ui.core.min.js?ver=1.8.16'></script> <script type='text/javascript' src='http://yourdomain.com/wp-content/plugins/yourplugin/js/custom-script.js?ver=20120208'></script> </body> |
Устанавливаем приоритеты
Некоторые люди предпочтут отказаться от использования таких методов, поскольку они чувствуют, что в таком случае у них гораздо меньше контроля над тем, в каком порядке загружаются их скрипты. К примеру, в теме, которую использует modernizr, автору нужно было убедиться, что modernizr загружается в первую очередь.
Ранее мы не упоминали многих деталей того, как работает функция , а с её помощью мы можем влиять на порядок выполнения. Вот использование этой функции согласно Кодексу WordPress:
|
1 |
add_action( $tag, $function_to_add, $priority, $accepted_args ); |
Обратите внимание, что очень часто используются только параметры $tag и $function_to_add. Параметр $priority по умолчанию установлен на 10, а параметр $accepted_args — на 1. Если мы хотим, чтобы наши скрипты ставились в очередь раньше, мы просто понижаем значение $priority. Например:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function wptuts_scripts_important() { // Регистрируем скрипт для плагина: wp_register_script( 'custom-script', plugins_url( '/js/custom-script.js', __FILE__ ) ); // или // Регистрируем скрипт для темы: wp_register_script( 'custom-script', get_template_directory_uri() . '/js/custom-script.js' ); // Вы можете поставить скрипт в очередь как для плагина, так и для темы: wp_enqueue_script( 'custom-script' ); } add_action( 'wp_enqueue_scripts', 'wptuts_scripts_important', 5 ); |
Вывод скрипта будет таким же, как и раньше, но в HTML коде он произойдёт раньше.
Отмена стандартных библиотек и использование CDN (сетей доставки контента)
Возможно когда-нибудь вы захотите использовать другую версию библиотеки, в отличие от той, что включена в WordPress. Возможно вы захотите использовать самую современную версию или не захотите ждать следующего выпуска WordPress, прежде чем использовать последнюю версию jQuery. Или же вы захотите воспользоваться Google CDN версией библиотеки.
Важно, чтобы это использовалось только в плагинах или темах для сайтов, которые вы будете лично поддерживать. Плагины или темы, которые вы выпускаете для общественного использования должны использовать библиотеки, включённые в WordPress.
Почему? По той простой причине, что вы не управляете этими сайтами. Вы не знаете, какие другие плагины или темы могут использовать ваши клиенты, и вы не знаете, как часто они будут обновлять ваш продукт. Использование библиотек, входящих в комплект WordPress — самый безопасный вариант.
Но если вы хотите сделать это на своём сайте, вот, как это возможно:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
function wptuts_scripts_load_cdn() { // Удаляем из списка включённую библиотеку wp_deregister_script( 'jquery' ); // Регистрируем библиотеку заново с Google CDN wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', array(), null, false ); // Регистрируем скрипт для плагина: wp_register_script( 'custom-script', plugins_url( '/js/custom-script.js', __FILE__ ), array( 'jquery' ) ); // или // Регистрируем скрипт для темы: wp_register_script( 'custom-script', get_template_directory_uri() . '/js/custom-script.js', array( 'jquery' ) ); // Вы можете поставить скрипт в очередь как для плагина, так и для темы: wp_enqueue_script( 'custom-script' ); } add_action( 'wp_enqueue_scripts', 'wptuts_scripts_load_cdn' ); |
Прежде всего мы удаляем из списка библиотек включённую версию библиотеки, иначе у нас были бы конфликты между различными версиями библиотек. Затем регистрируем свою версию, используя тот же самый дескриптор, определяем пустое значение в качестве версии (она уже в URL) и определяем, что она не в футере. Остальной код остаётся без изменений, потому что у нас есть зависимость от любого скрипта, использующего дескриптор ‘jquery’. Вот, что у нас должно получится:
|
1 2 |
<script type='text/javascript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js'></script> <script type='text/javascript' src='http://yourdomain.com/wp-content/plugins/yourplugin/js/custom-script.js?ver=3.3.1'></script> |
Примечание: Одна из причин, по которым лучше не использовать это в плагине или теме для публичного использования, заключается в том, что все плагины и темы используемые на этом сайте теперь должны будут использовать указанную здесь версию jQuery. Кроме того, у недавно зарегистрированной версии jQuery нет noConflict, поэтому, если другие темы или плагины используют, к примеру, Prototype, это всё испортит.
Не будьте жадными
Пока мы ничего не упоминали о том, как сделать всё это в панели администрирования, только на front-end-страницах сайта. Главное различие здесь — это какое действие использовать. Вместо add_action( 'wp_enqueue_scripts', 'wptuts_scripts_basic' );, которое мы использовали для внешней части сайта, для панели администрирования используется действие add_action( 'admin_enqueue_scripts', 'wptuts_scripts_basic' );
То, что важно сделать как для внешней части, так и для раздела администрирования — это определить, на каких страницах вы используете свои скрипты. Если в вашем плагине или теме есть скрипт, который делает что-то на внешней странице или на странице администрирования, например, на странице опций темы, или странице с определённым виджетом, вам нужно загрузить скрипт только на этой странице. Нет никакого смысла загружать скрипт там, где он не используется!
В Кодексе WordPress есть отличный пример того, как . Т.к. плагины и темы могут сильно отличатся тем, как они построены, мы не будем вдаваться в подробности, как правильно загрузить плагины только для одной страницы, но об этом нужно было упомянуть, чтобы вы это учитывали во время разработки.
Теперь о стилях
Процесс работы со стилями очень похож на работу со скриптами. Он осуществляется с помощью функции . Здесь представлено её использование согласно Кодексу WordPress:
|
1 |
wp_register_style( $handle, $src, $deps, $ver, $media ); |
Отметьте, что отличие между wp_register_script и wp_register_style состоит лишь в том, что вместо параметра $in_footer у нас параметр $media. Его можно установить следующим образом: 'all', 'screen', 'handheld', 'print', или любым другим типом медиа-контента, признанным W3C.
Т.е. мы можем добавить стили следующим образом:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
function wptuts_styles_with_the_lot() { // Регистрируем стили для плагина: wp_register_style( 'custom-style', plugins_url( '/css/custom-style.css', __FILE__ ), array(), '20120208', 'all' ); // или // Регистрируем стили для темы: wp_register_style( 'custom-style', get_template_directory_uri() . '/css/custom-style.css', array(), '20120208', 'all' ); // Ставим стили в очередь как для плагина, так и для темы: wp_enqueue_style( 'custom-style' ); } add_action( 'wp_enqueue_scripts', 'wptuts_styles_with_the_lot' ); |
Это довольно всесторонний пример, использующий большинство параметров, результат будет такой:
|
1 |
<link rel='stylesheet' id='custom-style-css' href='http://yourdomain.com/wp-content/plugins/yourplugin/css/custom-style.css?ver=20120208' type='text/css' media='all' /> |
Почему не все используют данный метод?
Вы, возможно задаётесь вопросом: “Почему этот метод ‘правильный’, а не просто ваше предпочтение?”. Если по существу — потому что этот метод рекомендуется WordPress. Это гарантирует, что любая комбинация плагинов и тем должна правильно функционировать без конфликтов.
В некоторых темах для загрузки скриптов используются теги <script></script> и <link /> в файлах header.php, и даже footer.php. Нет никакого смысла так поступать. Выше мы уже демонстрировали, что расположить скрипты и стили по приоритетам и определить, где они загружаются, вполне возможно в functions.php. Так ваша тема/фреймворк будет работать с гораздо большим количеством плагинов/тем.
К примеру, jQuery можно загрузить, используя теги <script></script>. На первый взгляд всё работает прекрасно, но так jQuery фактически может быть загружен дважды! Ведь подобная загрузка не помешает WordPress загрузить свою версию jQuery для других плагинов, поскольку версия от WordPress по умолчанию находится в режиме noConflict, а плагин может определить это как зависимость. Так у вас будет jQuery, как работающий в режиме noConflict, так и $, кроме того вы вероятно нарушите работу плагинов, использующих библиотеку Prototype.
Выводы
WordPress — фантастическая, очень продуманная система. Если есть механизм, позволяющий сделать что-либо, всегда стоит им воспользоваться. При разработке плагинов или тем старайтесь продумывать свой код, чтобы в дальнейшем у других не возникало с ним проблем.
А что вы думаете об использовании wp_enqueue_script и связанных с этим функциях и действиях? Знаете ли вы примеры, где это реализовано неправильно? Знаете ли вы какие-либо причины не следовать нашим советам? Поделитесь своими мыслями в комментариях.
Че то фигня какая-то получается... вернее совсем ничего не получается, даже фигни)) Эти коды где прописывать надо? В плагине? В том файле где происходит инициализация плагина? ... прописал... и ничего... ничего не появилось... щас буду экспериментировать))
Ура!)) заработало. Спасибо.
vse sdelano
возможно ли сделать так чтобы стиль шаблона не прикасался к плагину? Например чтобы сделанный мною чат имел свой стиль не взирая на смену шаблона