Основы хуков действий в WordPress

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

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

Показательный пример: я писал о шаблоне проектирования, управляемом событиями (или публикации-подписке или Pub/Sub, как некоторые любят его называть) в других сообщениях.

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

Фото Клауса Грюнштойдля на Unsplash

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

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

Это достаточно легко понять, но что, если вы хотите открыть области своего кода, которые позволяют другим подключаться к вашему коду?

Хуки действия в WordPress

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

Итак, как лучше всего представить шаблон Pub/Sub? Википедия определяет это как:

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

Понимание шаблона

Это может быть много, чтобы принять в первую очередь. Не знаю, но давайте разберем:

1. Существует сервис, в нашем случае это WordPress, который отвечает за публикацию сообщений всем, кто подписывается (он не обязательно знает, кто слушает).
2. Когда подписчик слушает, он будет предпринимать действия всякий раз, когда слышит это действие.
3. После завершения выполнения кода подписчика программа вернется к исходной точке выполнения (куда издатель отправил сообщение).

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

Асинхронная функциональность может попасть в потоки или Ajax через эти важные темы, это не та статья.

Как это выглядит в WordPress?

Возможно, самый простой способ описать этот конкретный шаблон в WordPress — использовать вызовы функций:

• do_action
• add_action

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

do_action указывает WordPress выполнять любые добавленные действия.

Иногда полезно иметь простые фразы, чтобы запомнить, как все работает. Я не знаю, является ли приведенная выше фраза самой запоминающейся или самой запоминающейся, но это что-то, верно?

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

Для do_action :

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

Или еще проще говоря:

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

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

Что касается add_action :

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

И аналогично, проще говоря:

Привязывает функцию к определенному действию.

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

Практический пример

Например, возможно, вы написали что-то вроде этого:

<?php
add_action('wp_insert_post_data', __NAMESPACE__. 'processPermalink');
/**
 * Processes the permalink so we can remove any characters that may cause a problem when communicating
 * with the API.
 *
 * @param  array $data The array of information about the post.
 * @return array $data The data without the malformed information in the post name for the URL.
 */
public function processPermalink($data)
{
    if (!in_array($data['post_status'], array('draft', 'pending', 'auto-draft'))) {
        $data['post_name'] =
            preg_replace(
                '/(%ef%b8%8f|™|®|©|™|®|©|™|®|©)/',
                '',
                $data['post_name']
            );
    }
    return $data;
}

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

Добавление собственных хуков

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

На мой взгляд, на самом деле это намного проще, чем работать с add_action, потому что add_action обеспечивает не только подключение к существующему издателю, но и добавление собственной пользовательской логики.

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

Это оно?

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

А пока, если вы не знакомы с основами:

• паб/саб шаблон,
• сделать_действие,
• и add_action

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

В настоящее время я пишу электронную книгу (наряду с другим премиальным контентом). Если вам интересно, посмотрите, что вы получите.