Статьи

Руководство для начинающих по постановке jQuery

Одна из лучших вещей в WordPress — это ее динамичная экономика. Для многих пользователей тривиально легко найти темы, соответствующие дизайну, для которого они предназначены, или найти плагины, которые предоставляют функциональность, которую они хотят внедрить на своем сайте.

Но сколько из вас — как разработчики или дизайнеры — получили этот телефонный звонок или электронное письмо, в котором клиент заявляет, что с их сайтом что-то не так, только чтобы обнаружить, что консоль браузера отображает что-то об ошибке, связанной с JavaScript или JQuery?

Точно. Скорее всего, любой, кто создал и / или обслуживал сайт для кого-то, сталкивался с этой проблемой, особенно если конечный пользователь получил разрешение на добавление своих собственных плагинов, разрешение на свои собственные обновления и т. Д.

В этой статье мы рассмотрим несколько концепций, связанных с jQuery и WordPress, чтобы убедиться, что мы, как разработчики, не только работаем над правильным построением наших продуктов, но и знаем, как правильно диагностировать проблемы по мере их возникновения в сайты наших клиентов.


Эта конкретная тема не нова для Wptuts +. На самом деле, мы написали обширную статью об этом, прежде чем завершить с несколькими примерами кода, каждый из которых должен предоставить вам все, что вам нужно, чтобы понять, как работать с JavaScript в WordPress.

Но так как мы продолжаем наблюдать определенные практики в сообществе, которые мы хотели бы помочь решить, мы не против охватить несколько аспектов одной и той же темы.

Поэтому, прежде чем читать эту статью, убедитесь, что вы знакомы с тем, как включить JavaScript и CSS в свои темы и плагины WordPress .


Когда речь идет о создании продуктов в WordPress, одна из вещей, которую мы, как разработчики, должны пытаться сделать, — это рассматривать приложение WordPress как основу.

Прямо сейчас API предоставляет нам огромную гибкость, когда речь идет о создании тем, плагинов и приложений, и это хорошо.

Но когда мы начинаем удалять библиотеки, которые поставляются с WordPress в пользу наших собственных, это почти как если бы мы создавали «мини-форк» проекта.

Это не очень хорошая практика для принятия.

Насколько мне известно, WordPress поставляется с базовым набором функций и библиотек, которые позволяют ему работать так же, как и он. Изменение важных частей приложения, таких как jQuery, влияет не только на сам WordPress, но и на всю экосистему продуктов, построенных на его основе.

Хорошие темы и плагины зависят от наличия этих библиотек. Когда мы меняем эту функциональность, мы потенциально нарушаем каждую часть работы, которая зависит от них.

Нам нужно перестать рассматривать WordPress как нечто, что мы можем разобрать, собрать заново, как нам нужно, и рассматривать его как основу, на которой мы можем построить свою уникальную работу.


Вообще говоря, проблема конфликтов JavaScript существует по одной из трех причин. Разработчик имеет либо:

  1. Неправильно управляемый jQuery в их коде
  2. Поменял версию jQuery на другую
  3. Изменен порядок загрузки jQuery

Во-первых, любой из трех вышеперечисленных случаев может быть выполнен одновременно, но чаще всего один из перечисленных выше. Во-вторых, я не думаю, что разработчики обычно делают это с злым умыслом.

Я думаю, что это скорее недостаток образования и / или понимания последствий.

Под этим я подразумеваю, что разработчик неправильно получил доступ к библиотеке jQuery, либо выполнив noConflict , неправильно вернув переменную в исходное состояние, либо просто переименовав функцию noConflict .

Позже в этой статье мы рассмотрим лучшие практики написания jQuery для WordPress, чтобы он мог в полной мере использовать библиотеку, не конфликтуя с другими плагинами, темами или проектами.

Это то, что часто делается с добрыми намерениями: идея заключается в том, что разработчик предоставляет обновление для версии jQuery, включенной в WordPress, чтобы можно было писать новые функции или более современные jQuery.

Проблема заключается в том, что ранее разработанные проекты не написаны с некоторыми более новыми функциями последней версии jQuery. Кроме того, если jQuery устарел или полностью удалил функцию в новой версии, которая присутствовала в старой версии, то этот код не будет работать.

Хотя эта проблема встречается не так часто, иногда она возникает: пытаясь ускорить загрузку сайта, разработчики будут перемещать порядок загрузки jQuery вниз по странице, обычно в нижний колонтитул.

Хотя загрузку JavaScript в нижнем колонтитуле страницы поощряют многие высокопрофильные сайты , это возвращает нас к целостному восприятию WordPress как основы для разработки приложений.

Если WordPress по умолчанию загружает jQuery в определенном месте, то мы должны не забыть оставить его там, поскольку все работы, построенные поверх приложения, зависят от того, находится ли он в этом месте и больше нигде.


Несмотря на то, что вы можете подготовить исходные файлы JavaScript к использованию jQuery несколькими способами, я стараюсь придерживаться одного способа, поскольку он полностью защищает и инкапсулирует функцию $ .

01
02
03
04
05
06
07
08
09
10
(function( $ ) {
    «use strict»;
 
    $(function() {
 
        // Your code here
 
    });
 
}(jQuery));

Вы также можете посмотреть GitHub Gist здесь .

Короче говоря:

Это обеспечивает правильно загруженную версию jQuery, которая использует стандартную ссылку на $ function, чтобы позволить нам продолжать нашу работу.

Обратите внимание, что выражение « use strict » обеспечивает следующее:

Строгий режим — это новая функция в ECMAScript 5, которая позволяет вам поместить программу или функцию в «строгий» рабочий контекст. Этот строгий контекст предотвращает выполнение определенных действий и создает больше исключений.

Для тех, кто заинтересован, вы можете прочитать больше об этом на этом сайте .

Наконец, фактическая функция document.ready является необязательной. Здесь он используется только для того, чтобы показать, как вы можете начать использовать стандартные функции jQuery в контексте кода.


Обратите внимание, что в следующей версии WordPress планируется поставка патча, который сделает данное обсуждение устаревшим, по крайней мере, до уровня Dashboard.

В частности, в настоящее время в Trac есть тикет, в котором WordPress не позволяет нам удалять jQuery с панели инструментов. Это хорошая вещь.

Короче говоря, основные выводы для этой статьи следующие:

  • Используйте версию, которая поставляется с WordPress
  • Получите доступ к функции $ используя надлежащие средства JavaScript

Я бы сказал, что делать что-то еще — значит настраивать себя на потенциально плохие результаты.