Хуки инициализации в WordPress: преимущества и распространенные ошибки использования

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

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

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

В данной статье мы раскроем всю важность хуков инициализации в WordPress, а также покажем, как использовать их в различных ситуациях.

Введение в хуки инициализации

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

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

Таким образом, хуки инициализации в основном используются для того, чтобы, как вы могли догадаться, инициализировать процесс их работы в плагинах и темах. Давайте взглянем на доступные init-хуки в WordPress в порядке их выполнения:

• Init запускается после того, как WordPress закончит свою загрузку, но до того, как будут переданы какие-либо хэдеры. Вообще, этот хук используется плагинами для инициализации процесса их работы.
• widgets_init используется для регистрации виджетов приложения в сайдбаре. Функция register_widget выполняется в пределах данного хука.
• admin_init выполняется в качестве первого действия после того, как пользователь получил доступ к панели администрирования WordPress. В целом, он используется для того, чтобы инициализировать параметры, специфичные для области администратора.

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

Вы можете изучить полный процесс выполнения хуков действий в WordPress в кодексе.

WordPress выполняет каждый хук в определенном порядке (который описан в кодексе). Также важно рассмотреть порядок появления событий в каждом хуке действий. Давайте рассмотрим следующие ситуации, чтобы понять разницу.

Определяем admin_init внутри хука init

Если нам требуется, мы можем определить хуки WordPress в пределах других хуков. В типичном запросе хук init выполняется перед хуком admin_init. Давайте попробуем что-либо вывести на экран, разместив admin_init внутри хука init:

add_action( 'init', 'test_init');
function test_init(){
    add_action( 'admin_init', 'test_admin_init');
}
 
function test_admin_init() {
    echo "Admin Init Inside Init";
}

После выполнения этого кода мы получим желаемый вывод посредством оператора echo.

Определяем init внутри хука admin_init

Давайте посмотрим на код и вывод сценария, когда более ранний хук определен в хуке, который идет позже в порядке выполнения.

add_action( 'admin_init', 'test_admin_init');
function test_admin_init() {
    add_action( 'init', 'test_init');
}
 
function test_init() {
    echo "Init Inside Admin Init";
}

В данном случае мы не получим никакого вывода – как и ожидалось – поскольку хук init выполняется перед хуком admin_init, а это недопустимо после определения хука admin_init.

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

Исследуем хуки init и admin_init

Среди всех хуков инициализации очень важно обратить внимание именно на init и admin_init, поскольку эти два хука используются очень часто во многих плагинах. Использование всех остальных инициализационных хуков в разы проще по сравнению с этими двумя хуками.

Также мы посмотрим на функциональность хуков init и admin_init.

Хук init выполняется при каждом запросе как для фронтэнда, так и для бэкэнда сайта WordPress.

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

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

Как использовать init хуки

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

WordPress не указывает нам на то, что именно мы должны, а что не должны подключать; поэтому разработчики могут допускать незначительные ошибки, которые, в свою очередь, способны приводить к заметному снижению производительности. В данной секции мы покажем вам, как эффективно использовать хуки init и admin_init.

Давайте взглянем на самые лучшие практики использования инициализационных хуков:

Хук init

• Регистрация произвольных типов записей – разработчики WordPress рекомендуют использовать хук init для регистрации новых произвольных типов записей.
• Инициализация конфигурации и настроек плагина – параметры настройки и конфигурации плагина необходимо определить для каждого запроса, а значит, хорошая практика заключается в том, чтобы поместить их внутри этого хука.
• Доступ к отправленным пользовательским данным (используя $_GET и $_POST) – мы можем перехватить переданные пользовательские данные без использования любых действий, однако в этом случае рекомендуется использовать init хук, поскольку он гарантирует выполнение для каждого запроса.
• Добавление новых правил перезаписи – мы можем задавать новые правила перезаписи, используя хук init, однако они будут работать только после сброса.
• Добавление или удаление произвольных действий – плагины содержат в себе много произвольных действий для расширения функциональности. Могут возникнуть ситуации, когда нам понадобится добавить новые действия или удалить старые. В таких случаях важно применить эти действия в хуке init.
• Загрузка текстового домена плагина – WordPress поддерживает многочисленные языки, и таким образом, мы можем загружать файл, содержащий переведенные строки. Это должно делаться тоже в хуке init.

Хук admin_init

• Управление доступом – важно проверить права доступа вошедших в систему пользователей перед тем, как разрешить пользовательский доступ к определенному набору особенностей и функциональности. admin_init – первое действие, которое будет выполняться в области администратора, поэтому мы можем использовать его для управления доступом.
• Добавление новых параметров – мы можем использовать этот хук для добавления новых страниц настроек или параметров в существующую область параметров WordPress.

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

Общие ошибки использования хуков инициализации

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

Давайте определим частые ошибки, а также способы их обхода:

• Обновление правил перезаписи – это очень ресурсоемкая операция, в процессе которой все правила перезаписи обновляются и переупорядочиваются для добавления новых или удаления старых нетребуемых правил. Многие разработчики обновляют правила перезаписи внутри init-действий. Это приводит к тому, что возникают ненужные затраты в плане производительности в каждом запросе. Мы должны определить способ ручного обновления правил перезаписи с помощью кнопок или обновления правил для редких действий, как, к примеру, сохранение настроек плагина.

• Доступ к базе данных – для реализации различной функциональности должен иметься доступ к базе данных, однако важно также предотвратить ненужные обращения к базе данных внутри инициализационных хуков, поскольку они выполняются при каждом запросе. Для данной цели идеальным решением будет привязать хуки базы данных к хукам с определенной функциональностью, избежав массивных затрат производительности.

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

• Использование хуков инициализации вместо хуков для определенной функциональности – это самая распространенная ошибка, которая совершается многочисленными разработчиками. В WordPress существует широкий спектр хуков, связанных с уникальной функциональностью. Очень важно использовать функциональные хуки, чтобы обойти конфликты и сделать код расширяемым. Хуки, такие как init и admin_init, могут использоваться вместо специфичных хуков, поэтому многие разработчики склонны обращаться к ним, не понимая того, какой разрушительный эффект это несет.

Примеры распространенных сценариев использования хуков init и admin_init разработчиками вместо рекомендуемых хуков:

• admin_menu – мы можем добавлять страницы меню с помощью функции add_menu_page. Для создания страниц в меню администратора рекомендуют использовать хук admin_menu. Однако многие разработчики используют хук admin_init, поскольку он выполняется после хука admin_menu.
• wp_enqueue_scripts – рекомендуемый способ добавления стилей и скриптов состоит в использовании хука wp_enqueue_scripts. Однако многие разработчики используют wp_enqueue_script внутри хука init для загрузки скриптов и стилей.

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

Заключение

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

Теперь мы можем применить те же самые методики к хукам, используемым в плагинах. Многие разработчики плагинов используют свои собственные хуки действий, чтобы сделать плагины расширяемыми. Для таких плагинов мы можем определить специфичные для плагина хуки инициализации, чтобы позволить разработчикам «повесить» задачи инициализации на предопределенные хуки.