Полезные советы по работе с хуками WordPress


Оглавление (нажмите, чтобы открыть):

Хуки WordPress: примеры, как использовать

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

Отсюда вытекает, что понимание хуков должно составлять обязательную часть «репертуара» разработчиков. Присоединяйтесь к нам – сегодня мы рассмотрим скрытые стороны этой простой, но в то же время мощной системы. О чем пойдет речь: мы пробежимся по концепции хуков, их применению и, естественно, покажем примеры их использования.

Концепция: что такое хуки WordPress и почему они используются?

За любым качественно написанным программным обеспечением кроется мощная концепция, которая отвечает на вопросы «что такое?» и «почему?». Хуки – не исключение. Говоря простыми словами, хук – это заполнитель для действия. Когда происходит определенное событие, такое как публикация записи, хук активируется, позволяя реализовать соответствующую реакцию. В терминах разработчиков хуки представляют собой пример системы, управляемой событиями.

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

Как применить хуки?

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

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

Работа с документацией

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

  • add_action( $hook, $function [, $priority [, $numArgs ] ] ) – задает обработчик функции $function, который вызывается в том случае, если определенный хук $hook активирован в результате возникновения события. $priority определяет, будет ли данный обработчик функции вызван до или после других обработчиков функций (по умолчанию переменная равна 10). Чем меньше этот показатель, тем раньше будет вызвана функция. $numArgs – количество аргументов, принимаемых обработчиком функции (по умолчанию 1).
  • do_action( $hook [, $arg1 [, $arg2 [, $arg3 [, … ] ] ] ] ) – активирует определенный хук $hook путем вызова всех обрабатываемых функций с необязательными аргументами $arg1, $arg2, $arg3 и т.д.

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

Применяем полученные знания на практике

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

Перед тем как начать, давайте создадим план действий:

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

Код будет выглядеть следующим образом:

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

Быстро перемещаться по коду можно с помощью разных инструментов – таких как, к примеру, Yoast’s PHP Cross Reference of the WordPress Source.

Поиск по «add_action» выдает следующий код:

add_action вызывает add_filter, который, в свою очередь, добавляет заданную функцию в массив, связанный с хуком $tag. Несмотря на то, чтобы здесь мы также используем параметры $priority и $accepted_args, данная функция полностью отвечает нашим предположениям. do_action будет чуть длиннее и сложнее:

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

Примеры

Обладая пониманием работы хуков, давайте взглянем на два следующих примера. Первый пример – работа с RSS; вместо того чтобы рассылать уведомления через синдикацию, почему бы не использовать для этого электронную почту?

Система почтовых уведомлений

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

Все, что нам осталось сделать, – это отправить уведомление по электронной почте в обработчике функции notify_via_email. Обратите внимание, что хук publish_post передает ID записи как аргумент в нашу функцию. Это позволит нам получить информацию о записи с помощью функции get_post:

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

Плагин Google Analytics

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

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

Но как добавить код в футер сайта? Все так же – с помощью хуков. Если вы работали с WordPress темами раньше, вы, вероятно, вызывали функции wp_head и wp_footer в хэдере и футере вашего сайта соответственно. Обе эти функции просто активируют хуки, чтобы плагины могли легко добавлять свой код в эти жизненно важные области страницы. Следовательно, мы просто добавим действие к хуку wp_footer:

Наша функция add_google_analytics_code, как и предполагает ее название, печатает код Google Analytics:

Обязательно измените UA-XXXXX-X на ваш личный ID, зависящий от сайта. В итоге все заработает. Просто добавьте указанный код в файл и загрузите его в вашу папку с плагинами. Убедитесь в том, что плагин содержит заголовок — к примеру, такой:

Поменяйте имя автора, URI, ну и не забудьте активировать плагин!

Хуки в WordPress: взгляд изнутри

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

Концепция: что такое хуки и почему они используются?

За любым качественно написанным программным обеспечением кроется мощная концепция, которая отвечает на вопросы «что такое?» и «почему?». Хуки – не исключение. Говоря простыми словами, хук – это заполнитель для действия. Когда происходит определенное событие, такое как публикация записи, хук активируется, позволяя реализовать соответствующую реакцию. В терминах разработчиков хуки представляют собой пример системы, управляемой событиями.

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

Как применить хуки?

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

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

Работа с документацией

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

  • add_action( $hook, $function [, $priority [, $numArgs ] ] ) – задает обработчик функции $function, который вызывается в том случае, если определенный хук $hook активирован в результате возникновения события. $priority определяет, будет ли данный обработчик функции вызван до или после других обработчиков функций (по умолчанию переменная равна 10). Чем меньше этот показатель, тем раньше будет вызвана функция. $numArgs – количество аргументов, принимаемых обработчиком функции (по умолчанию 1).
  • do_action( $hook [, $arg1 [, $arg2 [, $arg3 [, … ] ] ] ] ) – активирует определенный хук $hook путем вызова всех обрабатываемых функций с необязательными аргументами $arg1, $arg2, $arg3 и т.д.

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

Применяем полученные знания на практике

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

Перед тем как начать, давайте создадим план действий:

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

Код будет выглядеть следующим образом:

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

Быстро перемещаться по коду можно с помощью разных инструментов – таких как, к примеру, Yoast’s PHP Cross Reference of the WordPress Source.

Поиск по «add_action» выдает следующий код:

add_action вызывает add_filter, который, в свою очередь, добавляет заданную функцию в массив, связанный с хуком $tag. Несмотря на то, чтобы здесь мы также используем параметры $priority и $accepted_args, данная функция полностью отвечает нашим предположениям. do_action будет чуть длиннее и сложнее:

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

Примеры

Обладая пониманием работы хуков, давайте взглянем на два следующих примера. Первый пример – работа с RSS; вместо того чтобы рассылать уведомления через синдикацию, почему бы не использовать для этого электронную почту?

Система почтовых уведомлений

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

Все, что нам осталось сделать, – это отправить уведомление по электронной почте в обработчике функции notify_via_email. Обратите внимание, что хук publish_post передает ID записи как аргумент в нашу функцию. Это позволит нам получить информацию о записи с помощью функции get_post:

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

Плагин Google Analytics

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

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

Но как добавить код в футер сайта? Все так же – с помощью хуков. Если вы работали с WordPress темами раньше, вы, вероятно, вызывали функции wp_head и wp_footer в хэдере и футере вашего сайта соответственно. Обе эти функции просто активируют хуки, чтобы плагины могли легко добавлять свой код в эти жизненно важные области страницы. Следовательно, мы просто добавим действие к хуку wp_footer:

Наша функция add_google_analytics_code, как и предполагает ее название, печатает код Google Analytics:

Обязательно измените UA-XXXXX-X на ваш личный ID, зависящий от сайта. В итоге все заработает. Просто добавьте указанный код в файл и загрузите его в вашу папку с плагинами. Убедитесь в том, что плагин содержит заголовок – к примеру, такой:

Поменяйте имя автора, URI, ну и не забудьте активировать плагин!

Что такое хуки в WordPress?

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

Что такое хуки и зачем они нужны?

Генерация страницы в WordPress – это целый набор функций и запросов к базе данных. При этом сам “движок” и тема работают вместе для вывода контента. Браузер интерпретирует все эти данные и объединяет их в одну веб-страницу, которую в итоге увидит посетитель сайта.

Во всем коде WordPress разработчики включили так называемые “крючки”, чтобы разработчики могли “повесить” на них свой собственный код. Эти крючки и есть хуками.

Хуки в WordPress бывают двух видов:


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

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

Работу хуков можно рассмотреть на примере. Представьте себе, что система WordPress является большим предприятием, которое приглашает внешних подрядчиков для выполнения тех или иных задач. Такими подрядчиками являются хуки, которые не имеют постоянного места работы на предприятии. Они будут приглашены лишь в случае необходимости. Таким местами обитания подрядчиков (хуков) могут быть:

  • плагины;
  • файл functions.php внутри родительской или дочерней темы.

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

Каждый крючок помечен определенным именем (например, wp_head ), что соответствует определенной части процесса предприятия WordPress (в случае wp_head – процесс создания раздела в HTML-структуре конечной страницы). Получается, что крючки выезжают в вестибюль офиса предприятия, чтобы подрядчики могли ездить на них, и они делают это в определенном порядке. Например, хук wp_head выезжает и возвращается обратно до завершения , а крюк wp_footer возвращается прямо перед завершением и т.д. Таким образом, подрядчик всегда направляется на свой крючок, на определенную часть работы на предприятии.

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

Подытоживая все вышесказанное получается, что крючки – это то, что “приглашает” внешний код (от functions.php и плагинов и т.д.) в определенные области обработки PHP WordPress. Они могут делать что угодно: добавлять что-либо на страницу или делать совсем другие вещи, например, регистрировать ошибку или даже отправлять электронную почту.

Рассмотрим каждый из видов хуков более подробно.

Экшены

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

Функция wpschool_action_example() означает, что это экшен (или действие) и не содержит никаких аргументов. В функции присутствует один единственный оператор – echo “Текст в шапке сайта.” Это то, что делает функция. echo – это команда PHP, которая выводит что-либо на экран.

В строке add_action( ‘wp_head’, ‘wpschool_action_example’ ) содержится служебная команда add_action(), которая “подвешивает” функцию wpschool_action_example() на крючок экшена wp_footer. В итоге текст “Текст в шапке сайта.” будет напечатан в самом начале пашки (или хедера), там, где автор темы разместил крючок действия wp_head.

На реальном сайте это будет выглядеть следующим образом:

Также этот пример можно переделать для футера сайта,изменив лишь название крючка:

Фильтры

Работу фильтров рассмотрим на примере, в котором к названию публикации добавим строку “Фильтр:”.

Мастер Йода рекомендует:  Уровни сжатия JPEG в Photoshop и Lightroom

wpschool_filter_example() – это имя функции для фильтра the_title . Видно, что она имеет аргумент $title. Это служебная переменная WordPress, в которой содержится название публикации. В итоге строка return ‘Фильтр: ‘ . $title добавляет к названию текст “Фильтр:”. Служебная директива return возвращает конечный результат WordPress-обработчику, который продолжает свою работу. Эта строка буквально означает следующее: “Взять название публикации, добавить к нему текст, а затем передать его обратно ядру WordPress”.

Результат на сайте выглядит следующим образом:

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

В качестве заключения

В WordPress хуки используются для расширения стандартных возможностей “движка”. Это могут быть как простое добавление текста где-либо на сайте, так и сложные выборки, например, для плагина интернет-магазина WooCommerce .

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

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

Добавление кастомных хуков в WordPress: Custom Actions

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

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

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

Перед тем, как начать, убедитесь, что вы имеете всё необходимое для работы, и у вас установлена последняя версия WordPress.

Что такое хуки?

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

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

Вот его определение в Wikipedia:

Архитектура, управляемая событиями (англ. event-driven architecture, EDA) является шаблоном архитектуры программного обеспечения, позволяющим создание, определение, потребление и реакцию на события.

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

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

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

Использование JavaScript

Представьте, что вы работаете в сфере фронтенд разработки. У вас есть кнопка с >command-button , и когда пользователь нажимает на неё, то должно открыться диалоговое окно.

С помощью jQuery вы можете реализовать этот функционал вот так:

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

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

Использование WordPress

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

В WordPress регистрация собственного кода, запускающего события, немного отличается. К примеру, давайте представим, что вы работаете с административной страницей в WordPress и хотите добавить новый элемент подменю в меню Настройки . Назовём его Tuts+ Options .

Для этого мы добавляем следующий код в файл functions.php , или в плагин, или в любой тип проекта, с которым мы работаем:

Вы можете зайти на Codex, чтобы больше узнать о хуках admin_menu и функции add_submenu_page .

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

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

Понимание WordPress Actions

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

Настройка нашего файла

Для кода в этом руководстве мы будем использовать тему Twenty Sixteen , предоставляемую WordPress.

Создайте файл с названием tutsplus-actions.php в корне директории темы. Потом в functions.php добавьте следующие строки кода:

Это даёт теме команду загружать файл, который мы определили. Мы это делаем для того, чтобы не внедрять код в ядро темы и с легкостью удалить код, убрав include_once .

Краткое определение Actions

В WordPress хуки могут быть двух видов: хуки действий (actions) и хуки фильтров (filters). Хуки действий позволяют вам добавлять, удалять или менять определённые функции. А хуки фильтров отвечают за добавление, удаление и изменение информации.

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

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

Хотя технически всё правильно, но лучше определить тип хука, над которым вы работаете.

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

Работа с Actions

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

WordPress предлагает два вида записей: Записи (для регулярных записей блога) и Страницы (для постоянного контента, или контента, который будет меняться нечасто). Для обычной платформы блогов этого достаточно. Но WordPress уже давно превратился в CMS.

А одной из особенностей, которая делает WordPress расширяемым, является возможность представлять собственные типы записей (custom post types). WordPress называет их пользовательскими типами записей, и они пригодятся, если вам нужно создать тип контента, которому нужен собственный тип атрибутов, и которому не подходят названия «запись» или «страница».

Для того, чтобы создать собственный пользовательский тип записи, нам нужно выполнить две вещи:

  1. Определить функцию, которая цепляется за хук init , как указано на WordPress
  2. Зарегистрировать наш тип записи с помощью одной из доступных функций API

Регистрация Action

Чтобы зарегистрировать наш хук действия, мы используем функцию add_action , предоставляемую WordPress API. Это сообщит WordPress, что мы представляем хук действия и что нужно запустить функцию, определённую названием, которое мы указали в вызове функции.

Наш код должен выглядеть так:

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

Теперь нужно определить функцию.

Ключ к пониманию названия функции прост: Мы назвали ее tutsplus_register_post_type , поскольку это второй аргумент, который мы переместили в вызов add_action .

Он буквально говорит WordPress делать следующее: во время init вызвать функцию tutsplus_register_post_type .

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

Давайте это исправим.

Создание пользовательского типа записи


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

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

Мы выбрали следующие:

Мы надеемся, что остальные функции WordPress предоставляет автоматически. Аргументы будут выглядеть так:

И наконец, полная версия кода для регистрации типа записи:

После обновления Консоли должен появиться новый пункт прямо под Комментариями с названием Time Travelers.

Когда вы нажмёте Добавить новую , вы увидите место для заголовка (или имени путешественника), редактор (для информации путешественника) и цитату (наверное, для заметок о путешественнике). Вы также увидите мета-поле для публикации информации.

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

Определение Custom Actions

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

  1. определить хук
  2. наделить хук функцией
  3. разрешить разработчикам вызывать хук

Самый простой пример:

Не бойтесь добавлять этот код в tutsplus-actions.php , вы сможете изучить его подробнее после прочтения нашей статьи.

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

После обновления консоли, вы увидите надпись « This is a custom action hook » вверху консоли.

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

К вопросу о нашем типе записи

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

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

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

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

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

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

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

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

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

Итоги

Не тяжело понять, что такое хуки. Они добавляют разработчикам мощности и гибкости. Возможно, наиболее пугающей вещью в коде является определение хука в контексте другого хука (определение tutsplus_register_custom_post_type в init ).

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

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

Источник: code.tutsplus.com

Насколько полезным был этот пост?

Нажмите на звезду, чтобы оценить этот пост!

Средний рейтинг: 4.2 / 5. Количество голосов: 5

Что такое хуки wordpress. Полезные советы по работе с хуками WordPress. Введение в инициализационные хуки

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

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

Что такое хуки?

Хук «do» называется «действием». В любом месте, где определено действие, можно выполнить собственный код. Вот некоторые примеры:

  • отправить электронное письмо автору после публикации записи;
  • загрузить пользовательский скрипт в футере страницы;
  • добавить инструкции над формой входа.

Хук «customize» называется «фильтром». Фильтр позволяет изменять или настраивать значение и возвращать его в новой форме. Вот некоторые примеры:

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

Для фильтра важна не только позиция, но и возвращаемые значения. WordPress имеет фильтр почти для каждого значения, которое обрабатывает.

Элементы процедуры хука

Используем в качестве примера действия хук wp_head , а в качестве примера фильтра хук the_content .

Хук (существительное)

Сам хук — это указание того, когда и где происходит магия. Представьте себе, что это крюк, который альпинист вбил в поверхность скалы. Крюк имеет определенную позицию. Если другие альпинисты захотят двигаться в этом направлении, они могут использовать его.
Хуки действий вызываются с помощью функции do_action:

Хуки вызываются с помощью apply_filters() :

Как видите, нам нужно перехватить данные из фильтра.

Действия и фильтры

Следующий элемент в процедуре хука — это действие или фильтр. Это функция, которую вы определяете, чтобы сделать или отфильтровать что-то. Это альпинист, который готов использовать любой крюк, чтобы взобраться немного выше.
Действие, которое запускается в wp_head — это noindex() .

Хук проверяет, отключена ли настройка видимости для поисковых систем. Если это так, wp_no_robots() добавляет мета тег robots , указывающий поисковым системам не индексировать сайт.
Примером фильтра для the_content является wpautop() . Он отвечает за перенос абзацев в теге

И использование тега
для разрывов строк.

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

Хук (глагол)

В процедуре хука WordPress нужно указать, для чего именно предназначен хук. Это означает, что мы должны привязать функцию (глагол) к крюку (существительному). Это делается с помощью функции, которая часто неправильно называется «хуком».
Для хука wp_head и действия noindex() связь устанавливается с помощью этой строки кода:

Третий параметр является приоритетом. Мы рассмотрим его ниже.
Включение wpautop() в the_contentо осуществляется с помощью этой строки:

Это основные принципы процедуры хука. В следующих разделах мы рассмотрим их более подробно.

Вы уже используете эти хуки

Даже если вы «просто» изменяете тему или добавляете код в файл functions.php , вы уже используете действия и фильтры.

WP_HEAD

Рассмотрим раздел заголовка темы Twenty Fifteen, который можно найти в файле wp-content/themes/twentyfifteen/header.php .

Между открывающимся и закрывающимся тегами размещается не так уж много кода, но просмотрите исходный код страницы в браузере. Вы увидите там различные мета элементы, включая тег .
Элементы, которые могут отсутствовать в файле header.php , добавляются функцией wp_head() . Если вы используете среду разработки, просмотрите ее содержимое.

Единственное, что делает функция wp_head() , это выводит хук wp_head . Это означает, что тема может использовать do_action(‘wp_head’) , вместо wp_head () .
Этот хук уже используется ядром. Вот некоторые действия, которые WordPress подключает к этому хуку по умолчанию:

add_action(«wp_head»,»_wp_render_title_tag»,1); add_action(«wp_head»,»wp_enqueue_scripts»,1); add_action(«wp_head»,»feed_links»,2); add_action(«wp_head»,»feed_links_extra»,3); add_action(«wp_head»,»rsd_link»); add_action(«wp_head»,»wlwmanifest_link»); add_action(«wp_head»,»adjacent_posts_rel_link_wp_head»,10,0); add_action(«wp_head»,»locale_stylesheet»); add_action(«wp_head»,»noindex»,1); add_action(«wp_head»,»print_emoji_detection_script»,7); add_action(«wp_head»,»wp_print_styles»,8); add_action(«wp_head»,»wp_print_head_scripts»,9); add_action(«wp_head»,»wp_generator»); add_action(«wp_head»,»rel_canonical»); add_action(«wp_head»,»wp_shortlink_wp_head»,10,0); add_action(«wp_head»,»wp_site_icon»,99);

Среди них — действие noindex() , а также (начиная с версии WordPress 4.1) вызов _wp_render_title_tag() , который генерирует тег title .

Контент

Пример хука фильтра, который вы использовали, даже не зная об этом — the_content .
Он скрыт за функцией the_content() , которая используется для вывода содержимого записи или страницы. Она содержит вызов хука the_content .

По умолчанию к функции the_content уже подключено несколько фильтров.

add_filter(«the_content»,»wptexturize»); add_filter(«the_content»,»convert_smilies»); add_filter(«the_content»,»convert_chars»); add_filter(«the_content»,»wpautop»); add_filter(«the_content»,»shortcode_unautop»); add_filter(«the_content»,»prepend_attachment»);

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

Уроки использования the_content

Вот два примера того, как неправильное использование хука приводит к сбою в работе функции.
Тело функции the_content() также содержит вызов get_the_content() . Я видел, как второй использовался вместо первого в нескольких темах. Но таким образом сам хук отключается, и многие функции не будут работать.
Если вы подключаетесь к the_content , то имейте в виду, что он используется не только на страницах контента, но и на страницах списков. Например, в архивах, а также на главной странице.

Параметры в процедуре хука

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

Имена хуков ($teg)

Вы не сможете ничего сделать с именами хуков, которые используются в ядре WordPress, плагинах или темах оформления. Но при задании собственных имен нужно придерживаться нескольких принципов.
Имя действия должно включать в себя место, а фильтр-место и значение, которое будет изменено.
В качестве примеров действий можно привести wp_head и wp_footer , которые называются в соответствии с местом их расположения. Также часто используются префиксы или суффиксы. Например: before , pre , begin , after и end .


Функция wp_delete_post() , которая отвечает за удаление записи, включает в себя следующие хуки:

  • before_delete_post;
  • delete_post;
  • deleted_post;
  • after_delete_post.

Префиксы имен хуков

Помимо позиции и значения нужно задать префикс хука префикса. Например:

  • wpseo_ от Yoast SEO;
  • genesis_ от фреймворка Genesis;
  • advanced_ads_ от моего плагина Advanced Ads.

Это предотвращает конфликты с хуками в других плагинах или темах оформления.

Динамические имена хуков

Предположим, что в плагине есть много параметров, и вы хотите, чтобы другие разработчики могли использовать фильтр для каждого из них. Для этого нужно вызывать apply_filters() для каждого параметра. Также можно использовать динамическое имя хука, как это делает ​​WordPress в функции get_options() .

Данная функция включает в себя следующие хуки:

  • ‘pre_option_’ . $option;
  • ‘default_option_’ . $option;
  • ‘option_’ . $option.

Зная это, вы сможете подключиться к option_blogname или option_blogdescription , чтобы динамически изменять название или описание блога.

Магический «all»

При вызове add_action() и add_filter() в качестве имени хука можно использовать специальный тег. Благодаря чему связанная функция будет использоваться для каждого хука.

Имена функций

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

Также возможно подключение статичной функции в классе:

Ее вызов в экземпляре этого класса будет выглядеть следующим образом:

Также можно вызвать метод в экземпляре того же класса, например:

Также убедитесь, что функции являются public .

Использование PHP функций по умолчанию

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

Поскольку ucwords() является стандартной функцией PHP, которая принимает и возвращает значение, ее можно сократить до одной строки:

Приоритеты

Третий параметр в add_action() и add_filter() — это приоритет. Он устанавливает порядок, в котором вызываются функции, связанные с хуком.
Этот параметр является необязательным и по умолчанию равен 10, если не определен явно. Несколько функций с одинаковым приоритетом будут вызываться в том порядке, в котором они были зарегистрированы в хуке.
Плагин Advanced Ads использует the_content при вставке рекламных объявлений до или после контента. Ее третий параметр определяет, вставляется ли сначала рекламное объявление или другой контент. Чтобы избежать обращений за поддержкой относительно «неправильного» порядка элементов, я предоставил пользователям возможность выбирать приоритет фильтра в качестве опции.

Проверка выполнения действия

Чтобы проверить, выполнено ли конкретное действие, можно использовать did_action() .
Функция _wp_render_title_tag была подключена к wp_head . Это пример того, как ядро ​​Wordpress проверяет, что тег title действительно создан только тут.

did_action($hook) возвращает информацию о том, сколько раз было выполнено действие, включая текущий вызов. Функция вернет 1, если _wp_render_title_tag() запускается в wp_head . do_action(‘wp_head’) проверяет, находимся ли мы сейчас в действии wp_head . Фактически, приведенный выше код — это двойная проверка. Из-за этого он будет удален из WordPress 4.4.0.
Функция do_action() проверяет, действительно ли происходит действие.

Проверка использования фильтра

Для фильтров did_action() и do_action() нет псевдонимов. Вместо них нужно использовать has_filter($hook, $function) . Когда указан только $hook, будет возвращено значение true , если какая-либо функция зарегистрирована для hook. Значение false — в противном случае.
Если также передана функция $function , то будет возвращен приоритет этой функции, или значение false , если эта функция не подключена к хуку.
При добавлении рекламных объявлений после определенного абзаца плагин Advanced Ads должен убедиться, что wpautop() вызывается до того, как будет применена пользовательская функция фильтра.

Сложности с количеством аргументов

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

Удаление действий и фильтров

Удаление из хука действия или фильтра не является чем-то необычным. Популярным примером было удаление emojis из WordPress 4.2.
Весь плагин Disable Emojis можно свести к приведенному ниже коду:

Также существуют плагины, которые отключают функцию wpautop(). А ведь этоможно сделать с помощью всего одной строкикода в файле functions.php .

Функции remove_action() и remove_filter() принимают три аргумента:

Все они должны соответствовать значениям из add_action() и add_filter() . Сложность заключается в том, что хук будет удален только в том случае, если он уже добавлен.

Как найти хук?

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

Отладка хуков

Чтобы отлаживать хуки, создайте список всех подключенных действий и фильтров.

Использование error_log()

Для отладки фильтров я предпочитаю использовать error_log() в сочетании с DEBUG_LOG. При этом вывод записывается в файл debug.log , но не отображается через front-end.

В приведенном выше сценарии я добавляю к контенту строку HAHA . Но только если параметр возвращает значение true . Если это не работает, можно использовать error_log($ option) .

Использование HOOK API

Другой способ отладки хуков — использование функций, упомянутых выше. Например, doing_action() или did_action() .
В этот перечень также можно добавить current_filter() . Вы можете использовать ее для отображения имени текущего хука:

Если вы хотите увидеть, где это используется в ядре, посмотрите capital_P_dangit()

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

ЧТО ТАКОЕ ХУК?

КАК ИСПОЛЬЗОВАТЬ ХУКИ В ВАШЕМ БЛОГЕ

В этом примере мы подключили пользовательскую функцию myCustomFunction() к функции ядра publish_post() . Функция myCustomFunction() будет выполняться при каждом выполнении функции publish_post() .
Конечно, мы можем также удалить хук, используя функцию remove_action() :

1. ОТКЛЮЧАЕМ АВТОМАТИЧСКОЕ ФОРМАТИРОВАНИЕ В WORDPRESS

Проблема.
Решение.
  1. function my_formatter($content ) <
  2. $new_content = «» ;
  3. $pattern_full = «<(\.*?\)>is» ;
  4. $pattern_contents = «<\(.*?)\>is» ;
  5. $pieces = preg_split ($pattern_full , $content , — 1 , PREG_SPLIT_DELIM_CAPTURE) ;
  6. foreach ($pieces as $piece ) <
  7. if (preg_match ($pattern_contents , $piece , $matches ) ) <
  8. $new_content .= $matches [ 1 ] ;
  9. > else <
  10. $new_content .= wptexturize(wpautop($piece ) ) ;
  11. return $new_content ;
  12. remove_filter(«the_content» , «wpautop» ) ;
  13. remove_filter(«the_content» , «wptexturize» ) ;
  14. add_filter(«the_content» , «my_formatter» , 99 ) ;

После того, как Вы это сделали, можете использовать тэг для того, чтобы текст поста был не отформатирован автоматически:

This text will not be automatically formatted.

Объяснение кода.

2. ОПРЕДЕЛЯЕМ БРАУЗЕР ПОСЕТИТЕЛЯ ПРИ ПОМОЩИ ХУКОВ

Проблема.
Решение.

После того, как Вы сохраните файл, функция автоматически будет добавлять CSS-класс, соответствующий пользовательскому браузеру, для тэга body :

Объяснение кода.

3. ОПРЕДЕЛЕНИЕ ТЕКСТА ПО УМОЛЧАНИЮ В РЕДАКТОРЕ TinyMCE

Проблема.
Решение.
  1. add_filter(«default_content» , «my_editor_content» ) ;
  2. function my_editor_content( $content ) <
  3. $content = «If you enjoyed this post, make sure to subscribe to my rss feed.» ;
  4. return $content ;
Объяснение кода.

4. ВСТАВЛЯЕМ КОНТЕНТ АВТОМАТИЧЕСКИ ПОСЛЕ КАЖДОГО ПОСТА

Проблема.
Решение.

Enjoyed this article?

Subscribe to our RSS feed and never miss a recipe!

» ;

  • return $content ;
  • add_filter («the_content» , «insertFootNote» ) ;

  • Объяснение кода.

    Если Вам нужно, чтобы текст попадал в RSS-ленту, то замените предыдущий код на этот:

    5. ОТКЛЮЧАЕМ СООБЩЕНИЕ С ПРОСЬБОЙ ОБНОВИТЬСЯ В ПАНЕЛИ УПРАВЛЕНИЯ WORDPRESS

    Проблема.
    Решение.
    1. if (! current_user_can(«edit_users» ) ) <
    2. add_action( «init» , create_function ( «$a» , «remove_action(«init», «wp_version_check»);» ) , 2 ) ;
    3. add_filter( «pre_option_update_core» , create_function ( «$a» , «return null;» ) ) ;

    После того, как Вы сохраните файл functions.php , сообщения Вы больше не увидите.

    Объяснение кода.

    6. ОТКЛЮЧАЕМ АВТОСОХРАНЕНИЕ ПОСТОВ

    Проблема.
    Решение.
    1. function disableAutoSave() <
    2. wp_deregister_script(«autosave» ) ;
    3. add_action( «wp_print_scripts» , «disableAutoSave» ) ;
    Объяснение кода.

    7. ИЗБАВЛЯЕМСЯ ОТ ПОВТОРЯЮЩЕГОСЯ КОНТЕНТА НА СТРАНИЦАХ С КОММЕНТАРИЯМИ

    Проблема.
    Решение.
    1. function canonical_for_comments() <
    2. global $cpage , $post ;
    3. if ( $cpage > 1 ) :
    4. echo » \n » ;
    5. echo «
    6. echo get_permalink( $post -> ID ) ;
    7. echo «» /> \n » ;
    8. endif ;
    9. add_action( «wp_head» , «canonical_for_comments» ) ;
    Объяснение кода.

    8. ПОЛУЧЕНИЕ ПОСТА ИЛИ СТРАНИЦЫ В КАЧЕСТВЕ PHP-ПЕРЕМЕННОЙ

    Проблема.
    Решение.
    1. function callback($buffer ) <
    2. // modify buffer here, and then return the updated code
    3. return $buffer ;
    4. function buffer_start() <
    5. ob_start («callback» ) ;
    6. function buffer_end() <
    7. ob_end_flush () ;
    8. add_action(«wp_head» , «buffer_start» ) ;
    9. add_action(«wp_footer» , «buffer_end» ) ;
    Объяснение кода.

    9. ИСПОЛЬЗУЕМ ХУКИ И CRON ДЛЯ СОБЫТИЙ ПО РАСПИСАНИЮ

    Проблема.
    Решение.
    1. if (! wp_next_scheduled(«my_task_hook» ) ) <
    2. wp_schedule_event( time () , «hourly» , «my_task_hook» ) ;
    3. add_action( «my_task_hook» , «my_task_function» ) ;
    4. function my_task_function() <
    5. wp_mail(«[email protected]» , «Automatic email» , «Hello, this is an automatically scheduled email from WordPress.» ) ;
    Объяснение кода.

    10. СПИСОК ВСЕХ «ХУКНУТЫХ» ФУНКЦИЙ

    Проблема.
    Решение.
    1. function list_hooked_functions($tag = false ) <
    2. global $wp_filter ;
    3. if ($tag ) <
    4. $hook [ $tag ] = $wp_filter [ $tag ] ;
    5. if (! is_array ($hook [ $tag ] ) ) <
    6. trigger_error ( «Nothing found for «$tag » hook» , E_USER_WARNING ) ;
    7. return ;
    8. else <
    9. $hook = $wp_filter ;
    10. ksort ($hook ) ;
    11. echo «» ;
    12. return ;

    После того, как Вы вставите этот код в файл functions.php , вызовите функцию list_hooked_functions() . Она и покажет Вам список всех «хукнутых» функций.

    Объяснение кода.

    Срабатывает перед подключением подобранного файла шаблона темы, например: single.php , page.php , search.php , 404.php и т.д. Этот фильтр используется для изменения пути до такого файла.

    Фильтр срабатывает после события template_redirect и после того, как WordPress подберет файл, который будет использоваться в качестве файла шаблона. Для каждого типа страницы, файл разный: см. Иерархию файлов темы . Например, мы зашли на постоянную страницу, WordPress подбирает какой файл шаблона должен быть показан — это файл page.php: home/site.ru/wp-content/themes/mytheme/page.php . С помощью этого фильтра можно изменить путь такого файла.

    Во время этого фильтра уже можно использовать условные теги и переменная $post уже определена.

    Использование

    Примеры

    #1 Файл в каталоге темы

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

    Заголовок

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

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

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

    Перед тем, как начать, убедитесь, что вы имеете всё необходимое для работы, и у вас установлена последняя версия WordPress.

    Что такое хуки?

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

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

    Архитектура, управляемая событиями (англ. event-driven architecture, EDA) является шаблоном архитектуры программного обеспечения, позволяющим создание, определение, потребление и реакцию на события.

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

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

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

    Использование JavaScript

    Представьте, что вы работаете в сфере фронтенд разработки. У вас есть кнопка с ID атрибутом command-button , и когда пользователь нажимает на неё, то должно открыться диалоговое окно.

    С помощью jQuery вы можете реализовать этот функционал вот так:

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

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

    Использование WordPress

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

    В WordPress регистрация собственного кода, запускающего события, немного отличается. К примеру, давайте представим, что вы работаете с административной страницей в WordPress и хотите добавить новый элемент подменю в меню Настройки . Назовём его Tuts+ Options .

    Для этого мы добавляем следующий код в файл functions.php , или в плагин, или в любой тип проекта, с которым мы работаем:

    «Time Travelers», «labels» => array(«name» => «Time Travelers», «singular_name» => «Time Traveler», «add_new_item» => «Add New Traveler», «edit_item» => «Edit Traveler», «new_item» => «New Traveler», «view_item» => «View Traveler», «search_items» => «Search Travelers», «not_found» => «No Travelers»,), «description» => «A post type used to provide information on Time Travelers.», «public» => true, «show_ui» => true, «supports» => array(«title», «editor», «excerpt»,),);

    И наконец, полная версия кода для регистрации типа записи:

    «Time Travelers», «labels» => array(«name» => «Time Travelers», «singular_name» => «Time Traveler», «add_new_item» => «Add New Traveler», «edit_item» => «Edit Traveler», «new_item» => «New Traveler», «view_item» => «View Traveler», «search_items» => «Search Travelers», «not_found» => «No Travelers»,), «description» => «A post type used to provide information on Time Travelers.», «public» => true, «show_ui» => true, «supports» =>

    После обновления Консоли должен появиться новый пункт прямо под Комментариями с названием Time Travelers.

    Когда вы нажмёте Добавить новую , вы увидите место для заголовка (или имени путешественника), редактор (для информации путешественника) и цитату (наверное, для заметок о путешественнике). Вы также увидите мета-поле для публикации информации.

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

    Определение Custom Actions

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

    1. определить хук
    2. наделить хук функцией
    3. разрешить разработчикам вызывать хук


    Самый простой пример:

    $plural, «labels» => array(«name» => $plural, «singular_name» => $singular, «add_new_item» => «Add New Traveler», «edit_item» => «Edit Traveler», «new_item» => «New Traveler», «view_item» => «View Traveler», «search_items» => «Search Travelers», «not_found» => «No Travelers»,), «description» => «A post type used to provide information on Time Travelers.», «public» => true, «show_ui» => true, «supports» => array(«title», «editor», «excerpt»,),); register_post_type(«time_traveler», $args); >

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

    tutsplus_register_custom_post_type в init ).

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

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

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

    Концепция: что такое хуки и почему они используются?

    За любым качественно написанным программным обеспечением кроется мощная концепция, которая отвечает на вопросы «что такое?» и «почему?». Хуки – не исключение. Говоря простыми словами, хук – это заполнитель для действия. Когда происходит определенное событие, такое как публикация записи, хук активируется, позволяя реализовать соответствующую реакцию. В терминах разработчиков хуки представляют собой пример системы, управляемой событиями.

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

    Как применить хуки?

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

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

    Работа с документацией

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

    • add_action($hook, $function [, $priority [, $numArgs ] ]) – задает обработчик функции $function, который вызывается в том случае, если определенный хук $hook активирован в результате возникновения события. $priority определяет, будет ли данный обработчик функции вызван до или после других обработчиков функций (по умолчанию переменная равна 10). Чем меньше этот показатель, тем раньше будет вызвана функция. $numArgs – количество аргументов, принимаемых обработчиком функции (по умолчанию 1).
    • do_action($hook [, $arg1 [, $arg2 [, $arg3 [, … ] ] ] ]) – активирует определенный хук $hook путем вызова всех обрабатываемых функций с необязательными аргументами $arg1, $arg2, $arg3 и т.д.

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

    Применяем полученные знания на практике

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

    Перед тем как начать, давайте создадим план действий:

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

    Код будет выглядеть следующим образом:

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

    Быстро перемещаться по коду можно с помощью разных инструментов – таких как, к примеру, Yoast’s PHP Cross Reference of the WordPress Source.

    Поиск по «add_action» выдает следующий код:

    Function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) < return add_filter($tag, $function_to_add, $priority, $accepted_args); >function add_filter($tag, $function_to_add, $priority = 10, $accepted_args = 1) < global $wp_filter, $merged_filters; $ =>$function_to_add, «accepted_args» => $accepted_args); unset($merged_filters[ $tag ]); return true; >

    add_action вызывает add_filter, который, в свою очередь, добавляет заданную функцию в массив, связанный с хуком $tag. Несмотря на то, чтобы здесь мы также используем параметры $priority и $accepted_args, данная функция полностью отвечает нашим предположениям. do_action будет чуть длиннее и сложнее:

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

    Примеры

    Обладая пониманием работы хуков, давайте взглянем на два следующих примера. Первый пример – работа с RSS; вместо того чтобы рассылать уведомления через синдикацию, почему бы не использовать для этого электронную почту?

    Система почтовых уведомлений

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

    Все, что нам осталось сделать, – это отправить уведомление по электронной почте в обработчике функции notify_via_email. Обратите внимание, что хук publish_post передает ID записи как аргумент в нашу функцию. Это позволит нам получить информацию о записи с помощью функции get_post:

    Function notify_via_email($post_ ); $message = $post->post_title . » was published on » . get_bloginfo(«name») . » as of » . $post->post_date . «. You may view it at » . get_permalink($post_id) . «.»; wp_mail($to, $subject, $message); >

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

    Плагин Google Analytics

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

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

    Но как добавить код в футер сайта? Все так же – с помощью хуков. Если вы работали с WordPress темами раньше, вы, вероятно, вызывали функции wp_head и wp_footer в хэдере и футере вашего сайта соответственно. Обе эти функции просто активируют хуки, чтобы плагины могли легко добавлять свой код в эти жизненно важные области страницы. Следовательно, мы просто добавим действие к хуку wp_footer:

    Наша функция add_google_analytics_code, как и предполагает ее название, печатает код Google Analytics:

    Обязательно измените UA-XXXXX-X на ваш личный ID, зависящий от сайта. В итоге все заработает. Просто добавьте указанный код в файл и загрузите его в вашу папку с плагинами. Убедитесь в том, что плагин содержит заголовок — к примеру, такой:

    Добавление пользовательских хуков в WordPress: пользовательские действия

    Russian (Pусский) translation by Sergey Zhuk (you can also view the original English article)

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

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

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

    Начинаем

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

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

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

    Но в этом уроке мы концентрируемся на хуках и действиях. Итак, как только вы все настроили, давайте начнем.

    Что такое хуки?

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

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

    Независимо от того, как он определен в Википедии:

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

    Если вы только сейчас начинаете разрабатывать шаблоны проектирования или разработки, это определение может показаться сложным, можно немного перефразировать так:

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

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

    Использование JavaScript

    Во-первых, представьте, что вы работаете в интерфейсе разработки. У вас есть кнопка с атрибутом >command-button , и когда пользователь нажимает на нее, вы хотите отобразить диалоговое окно предупреждений.

    Используя jQuery, вы можете реализовать эту функцию следующим образом:

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

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

    Использование WordPress

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

    В WordPress регистрация собственного кода с помощью события, которое срабатывает, немного отличается. Например, предположим, что вы работаете с страницами администрирования в WordPress, и вы хотите добавить новый элемент подменю в меню «Настройки». Мы назовем его Tuts + Options.

    Для этого мы добавим следующий код в наш файл functions.php или в наш плагин или в любой тип проекта, на котором мы сосредоточены:

    Вы можете посетить Codex, чтобы узнать больше о hook-файле admin_menu , а также о функции add_submenu_page .

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

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

    Понимание действий WordPress

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

    Настройка нашего файла

    В этом уроке мы будем использовать стандартную тему twentysixteen, которая поставляется с WordPress.

    В корне каталога темы создайте файл с именем tutsplus-actions.php . Затем в functions.php добавьте следующую строку кода:


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

    Краткое определение действий

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

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

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

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

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

    Работа с действиями

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

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

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

    Чтобы создать свой собственный тип сообщения, нам нужно сделать две вещи:

    1. Определить функцию init , которая перехватывает хук, как это предусмотрено в WordPress
    2. Зарегистрируйте наш тип сообщения с одной из предоставленных функций API

    Регистрация нашего действия

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

    Наш код должен выглядеть так:

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

    Далее нам нужно определить функцию.

    Ключ к пониманию сигнатуры этой функции прост: мы назвали ее tutsplus_register_post_type , так как это второй аргумент, который мы передали в вызов add_action .

    Она буквально инструктирует WordPress сделать следующее: Во время init вызовите функцию tutsplus_register_post_type .

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

    Давайте изменим это.

    Создание пользовательского типа сообщения

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

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

    В частности, мы собираемся использовать следующее:

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

    И окончательная полная версия кода для регистрации типа сообщения будет выглядеть так:

    Когда вы обновляете область администрирования своей WordPress-установки, в пункте Comments, должен появиться новый пункт меню Time Travellers.

    Когда вы нажимаете «Добавить новое», вы должны увидеть место для названия (или имени путешественника), редактора (для информации путешественника) и выдержки (возможно, для некоторых заметок о путешественнике). Вы также должны увидеть один мета-бокс для публикации информации.

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

    Определение пользовательских действий

    Когда дело доходит до создания наших собственных действий, мы должны сделать три вещи. На самом фундаментальном уровне, мы должны сделать следующее:

    1. определить хук
    2. Передать функциональность хуку
    3. Разрешить разработчикам вызвать хук

    Самый простой пример, который я могу дать для этого, следующий:

    Спокойно добавьте этот код примера в файл tutsplus-actions.php .

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

    Если вы обновите панель управления, в верхней части панели управления отобразится «Это настраиваемый хук действий».

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

    Пересмотр типа нашего сообщения

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

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

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

    Чтобы сделать это, мы перехватываем наш пользовательский хук с init hook:

    Обратите внимание, что в коде выше мы указываем два дополнительных параметра для do_action . Первый параметр — 10, указывающий приоритет, в котором этот крючок будет срабатывать.

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

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

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

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

    Заключение

    Определение пользовательских перехватов не сложно, и это также придает нам большую силу и гибкость как разработчикам. Пожалуй, самая запутанная вещь в коде выше — это то, как мы определяем хук в контексте другого хука (то есть мы определяем tutsplus_register_custom_post_type внутри init ).

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

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

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

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

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

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

    Что такое WordPress хуки и как их использовать?

    Что такое хуки? Простыми словами хуки это функции wordpress, к которым можно привязать свои функции. В переводе с английского hook это крюк, таким образом вы как бы привязываетесь к стандартной функции. Например, на функцию удаления записи, привязываем свою функцию, которая будет срабатывать только при удалении поста. С помощью грамотного использования хуков, можно значительно расширить базовый функционал WordPress.

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

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

    Хуки используются либо в плагинах, или в functions.php. Чтобы вызвать хук нужно прописать:

    publish_post – название хука, все хуки можно посмотреть на официальном сайте WordPress Codex.

    add_point – Название функции, которую вы создаете.

    Пример функции с хуком

    В моем случае функция работает таким образом:

    Пользователь добавляет запись, срабатывает хук который вызывает функцию, в которой происходит вся магия �� В функции я работаю с классом $wpdb->update, где обновляю таблицу с балами конкретного пользователя. В уроке insert» href=»https://wp-query.ru/chto-takoe-wpdb-insert-ili-sozdaem-obratnuyu-svyaz-na-primere-chast-1/» target=»_blank»>что такое $wpdb->insert, я рассказывал о классе $wpdb->insert на основе которого вы можете сделать свою функцию с использованием $wpdb->update, данный класс работает аналогичным образом.

    Вот как примерно выглядит конструкция с использованием хука:

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

    Вот функция с обновлением баллов:

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

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

    Подробное руководство по работе с хуками WooCommerce

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

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

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

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

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


    WooCommerce Global Hooks

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

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

    Позволяет отобразить информацию над ссылками breadcrumbs.

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

    WooCommmerce Cart Hooks

    В целом страница корзины в WooCommerce очень хорошо размечена. Для удобства мы разделили на три группы все хуки, которые используются на странице Cart.

    Хуки, которые отображаются перед списком товаров в корзине

    К ним относятся следующие:

    • woocommerce_before_cart
    • woocommerce_before_cart_table
    • woocommerce_before_cart_contents
    • woocommerce_cart_contents
    • woocommerce_after_cart_contents

    Хуки, которые отображаются после списка товаров в корзине

    К ним относятся следующие хуки:

    • woocommerce_cart_coupon
    • woocommerce_cart_actions
    • woocommerce_after_cart_table
    • woocommerce_cart_collaterals
    • woocommerce_before_cart_totals

    Хуки, которые отражаются в итоге заказа

    К ним относятся следующие хуки:

    • woocommerce_cart_totals_before_shipping
    • woocommerce_cart_totals_after_shipping
    • woocommerce_cart_totals_before_order_total
    • woocommerce_cart_totals_after_order_total
    • woocommerce_after_shipping_rate
    • woocommerce_before_shipping_calculator
    • woocommerce_proceed_to_checkout
    • woocommerce_after_cart_totals
    • woocommerce_after_cart

    В случае, если в корзине нет товаров

    В этом случае вы можете использовать следующий хук:

    WooCommerce Checkout Hooks

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

    Хуки, которые используются перед формой контактных данных

    К ним относятся следующие хуки:

    • woocommerce_before_checkout_form
    • woocommerce_checkout_before_customer_details
    • woocommerce_checkout_billing
    • woocommerce_before_checkout_billing_form

    Хуки, которые используются для разметки Billing details

    К ним относятся следующие хуки:

    • woocommerce_after_checkout_billing_form
    • woocommerce_checkout_shipping
    • woocommerce_before_order_notes
    • woocommerce_after_order_notes
    • woocommerce_checkout_after_order_review

    Хуки, которые используются перед итогом товаров в заказе

    К ним относятся следующие хуки:

    • woocommerce_checkout_after_customer_details
    • woocommerce_checkout_before_order_review
    • woocommerce_review_order_before_cart_contents
    • woocommerce_review_order_after_cart_contents
    • woocommerce_review_order_before_shipping
    • woocommerce_review_order_after_shipping
    • woocommerce_review_order_before_order_total
    • woocommerce_review_order_after_order_total

    Хуки, которые отображаются в конце формы заказа

    К ним относятся следующие хуки:

    • woocommerce_checkout_order_review
    • woocommerce_review_order_before_payment
    • woocommerce_review_order_before_submit
    • woocommerce_review_order_after_submit
    • woocommerce_review_order_after_payment
    • woocommerce_after_checkout_form

    Хуки, которые отображаются в списке товаров в заказе

    К ним относятся следующие хуки:

    • woocommerce_order_items_table
    • woocommerce_order_item_meta_start
    • woocommerce_order_item_meta_end
    • woocommerce_order_details_after_order_table
    • woocommerce_thankyou

    WooCommerce Product Hooks

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

    Хуки, которые отражаются сначала и в конце страницы товара

    К ним относятся следующие хуки:

    Хуки, которые отображаются перед началом и в конце описания товара

    К ним относятся следующие хуки:

    Хуки, которые отображаются перед началом и в конце карточки товара

    К ним относятся следующие хуки:

    Хуки, которые отражаются непосредственно в кратком описании товара

    К ним относятся следующие хуки:

    • woocommerce_single_product_summary
    • woocommerce_product_meta_start
    • woocommerce_product_meta_end
    • woocommerce_share

    Хуки, которые отображаются среди списка комментариев

    К ним относятся следующие хуки:

    • woocommerce_review_before
    • woocommerce_review_before_comment_meta
    • woocommerce_review_meta
    • woocommerce_review_before_comment_text
    • woocommerce_review_comment_text
    • woocommerce_review_after_comment_text

    WooCommerce Category Hooks

    WooCommerce имеет также достаточно хуков для работы с категориями товаров. Ниже мы рассмотрим их с кратким описанием и скринами.

    Отображается сразу под заголовком категории.

    Отображается перед карточкой товара в списке.

    Отображается перед списком товаров в категории.

    Отображается после списка товаров в категории.

    Отражается в конце описания каждой карточки товара в списке.

    Хуки, которые дополнительно размечают карточку товара в списке.

    К ним относятся следующие хуки:

    • woocommerce_after_shop_loop_item_title
    • woocommerce_shop_loop_item_title
    • woocommerce_before_shop_loop_item_title

    WooCommerce My Account Hooks

    Эти хуки служат для детальной разметки страницы My Account. Мы также выделили две категории таких хуков.

    Основные хуки для разметки страницы Мой Аккаунт

    К ним относятся следующие:

    • woocommerce_before_account_navigation
    • woocommerce_after_account_navigation
    • woocommerce_account_navigation
    • woocommerce_before_edit_account_address_form
    • woocommerce_after_edit_account_address_form
    • woocommerce_account_content

    Дополнительные хуки для разметки страницы Мой аккаунт

    К ним относятся следующие:

    • woocommerce_account_dashboard
    • woocommerce_before_my_account
    • woocommerce_after_my_account


    WooCommerce Mini Cart Hooks

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

    К ним относятся следующие:

    • woocommerce_before_mini_cart
    • woocommerce_before_mini_cart_contents
    • woocommerce_mini_cart_contents
    • woocommerce_widget_shopping_cart_before_buttons
    • woocommerce_widget_shopping_cart_buttons
    • woocommerce_after_mini_cart

    WooCommerce Email Hooks

    Служат для разметки писем, которые направляются пользователям после покупки, и содержат список товаров.

    К ним относятся следующие:

    • woocommerce_email_after_order_table
    • woocommerce_email_before_order_table
    • woocommerce_email_customer_details
    • woocommerce_email_footer
    • woocommerce_email_header
    • woocommerce_email_order_details
    • woocommerce_email_order_meta

    Другие хуки

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

    Однако существует еще ряд хуков, которые используются в меньшей степени. Мы предоставляем полный список ниже:

    • woocommerce_after_account_downloads
    • woocommerce_after_account_orders
    • woocommerce_after_account_payment_methods
    • woocommerce_before_account_download
    • woocommerce_before_account_order
    • woocommerce_before_account_orders_paginatio
    • woocommerce_before_account_payment_method
    • woocommerce_edit_account_for
    • woocommerce_edit_account_form_en
    • woocommerce_edit_account_form_star
    • woocommerce_resetpassword_for
    • woocommerce_after_available_downloads
    • woocommerce_after_checkout_registration_form
    • woocommerce_after_checkout_shipping_form
    • woocommerce_after_edit_account_form
    • woocommerce_after_subcategor
    • woocommerce_after_subcategory_titl
    • woocommerce_auth_page_foote
    • woocommerce_auth_page_heade
    • woocommerce_available_download_en
    • woocommerce_available_download_star
    • woocommerce_before_available_download
    • woocommerce_before_checkout_registration_for
    • woocommerce_before_checkout_shipping_for
    • woocommerce_before_edit_account_for
    • woocommerce_before_subcategor
    • woocommerce_before_subcategory_titl
    • woocommerce_cart_has_error
    • woocommerce_checkout_after_terms_and_condition
    • woocommerce_checkout_before_terms_and_condition
    • woocommerce_lostpassword_for
    • woocommerce_order_details_after_customer_detail
    • woocommerce_pay_order_after_submi
    • woocommerce_pay_order_before_submi
    • woocommerce_product_thumbnail
    • woocommerce_shop_loop_subcategory_titl
    • woocommerce_view_order

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

    Инициализационные хуки WordPress: преимущества и типичные ошибки

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

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

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

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

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

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

    • init выполняется после того, как WordPress закончила загрузку, но до отправки заголовков.
    • w >

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

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

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

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

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

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

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

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

    Исследование хуков init и admin_init

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

    Сейчас мы рассмотрим функциональность init и admin_init хуков.

    init исполняется в каждом запросе как для фронт-энда, так и для администраторской части WordPress сайта. admin_init выполняется после того, как администраторская часть завершает процесс загрузки. Соответственно, он тоже выполняется в каждом запросе на чтение страницы в админской части сайта. Чтобы воспользоваться его преимуществами, пользователи должны быть авторизованы.

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

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

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

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

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

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

    Типичные ошибки при использовании хуков инициализации

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

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

    • Обновление правил перезаписи – Это ресурсоемкая операция, которая обновляет и сортирует все правила перезаписи для добавления новых и удаления ненужных правил. Многие разработчики предпочитают обновлять правила перезаписи внутри действий init и заканчивают тем, что создают избыточную нагрузку в каждом запросе. Чтобы избежать этого, мы должны придумать, как провести обновление правил перезаписи вручную, используя кнопку, или обновлять их внутри таких нерегулярных действий, как сохранение настроек плагина.
    • Доступ к базе данных – Предоставление различной функциональности требует доступа к базе данных, но важно убрать лишние запросы к БД внутри хуков инициализации, так как в противном случае они будут выполняться в каждом запросе. В данном случае, идеальным решением будет встроить хуки с запросами к БД в функционально-специфичные хуки, чтобы избежать чрезмерной нагрузки.
    • Выполнение процедур обновления до новых версий – Чтобы иметь возможность обновить функционал плагинов до новых версий, в них должна быть продумана процедура апгрейда. Обычно разработчики применяют init хуки, чтобы проверить версии плагинов и настроек перед тем, как запустить процесс апгрейда. Мы можем позволить пользователям обновить плагин, предоставив им пользовательское окно, вместо автоматической проверки в каждом запросе.
    • Выполнение хуков инициализации вместо функционально-специфичных хуков – Это одна из самых типичных ошибок, допускаемых разработчиками. Существует множество хуков в WordPress, которые созданы для разных, уникальных целей. Важно использовать их, чтобы избежать возможных конфликтов и сделать код расширяемым. Такие хуки как admin_init и 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 жизненно важны в разработке плагинов и тем. Многие разработчики применяют их неправильно, создавая лишнюю нагрузку. В этой статье мы обсудили, как использовать эти хуки наилучшим образом, а также наиболее распространенные ошибки и способы их избежания.

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

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

    Хуки и хаки плагина WP-PostRating — убираем ошибки рейтинга

    Как я вижу, плагин WP-PostRatings пользуется большой популярностью среди блоггеров WordPress. Да и что греха таить, я сам питаю некоторую слабость к данному плагину и использую его во всех проектах на WordPress.

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

    Хуки плагина WP-PostRatings

    1. Важным функционалом плагина WP-PostRatings является подключение микроразметки к вашим постам. Благодаря именно этой микроразметке Google использует расширенный сниппет для ваших постов.

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

    С помощью кода, добавленного в function.php:

    add_filter(‘wp_postratings_schema_itemtype’, ‘wp_postratings_schema_itemtype’);
    function wp_postratings_schema_itemtype($itemtype) <
    return ‘itemscope itemtype=»https://schema.org/Recipe»‘;
    >

    И так любой нужную вам сущность. Если же оставить строчку пустой:

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

    С помощью данной функции вы уберёте из кода все дублирующие meta, которые могли уже быть указаны «выше» вручную или с помощью других плагинов (Yoast WordPress SEO, например)

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

    Для того, чтобы при каждом обновлении плагина ваши звёзды всегда оставались на месте, создайте отдельную папку в директории плагина (images), куда залейте ваш вариант изображения рейтинга. Обновления не затронут данную папку, и рейтинг всегда будет таким, как вы его хотите видеть.

    3. Рейтинг плагина WP-Postratings предназначен для вывода рейтинга постов, используя стандартную функцию WordPress:

    Вывести рейтинг рубрик или меток у вас не получится.

    4. Для вывода рейтинга постов только в определенных рубриках используйте:

    где xx — id необходимой рубрики.

    5. Стандартный вывод функции с возможность голосования и микроразметкой AggregateRating (если включена):

    Для вывода рейтингов у каждого поста рубрики используйте код без возможности голосовать:

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

    Данный код устанавливается в место вывода рейтинга.

    6. Многие обратили внимание, что при установке плагина WP-Postratings на блог, Google начал показывать ошибку сканирования 404 страниц:

    От данной проблемы можно избавиться, заменив часть кода в файле wp-postratings.php

    if($postratings_custom) <
    for($i = 1; $i

    Добавить комментарий