Плагины WordPress обычно используются двумя группами людей: владельцами веб-сайтов WordPress и разработчиками. Важно удовлетворить потребности обоих групп пользователей.
Разработчиками могут быть люди с базовым уровнем знаний WordPress / PHP, которые хотят повозиться с вашим плагином. Они также могут быть опытными разработчиками WordPress, которые хотят использовать ваш плагин для предоставления определенной функциональности веб-сайту клиента.
Если вы хотите познакомиться с разработкой плагинов для WordPress, стоит прочитать статью Тима Смита по разработке плагинов для WordPress.
Зачем делать мой плагин WordPress для разработчиков дружелюбным?
Основная причина в том, что вы поможете разработчикам не редактировать файлы базовых плагинов для достижения требуемой функциональности.
В свою очередь, это уменьшает количество запросов поддержки и потенциальное разочарование от разработчиков, которые вносят изменения, только для того, чтобы обнаружить, что их изменения отменены в обновлении плагина.
Удобные для разработчиков плагины также означают, что вы, скорее всего, получите ценные отзывы от более опытных разработчиков, которые, возможно, расширили функциональность вашего плагина и с удовольствием предоставят свои улучшения кода. Это позволяет вашему плагину естественным образом расти и становиться более стабильным, безопасным и полезным для более широкой аудитории.
Есть несколько способов сделать ваши плагины WordPress дружественными для разработчиков, и сегодня мы рассмотрим использование действий и фильтров WordPress.
Действия и фильтры: учебник для начинающих
Одной из основных функций WordPress является API-интерфейс плагина. В частности, это обеспечивает фильтры и действия, также известные как ловушки, которые «привязываются» к ядру WordPress в определенных местах.
действия
Действия позволяют нам запускать определенную функцию в определенное время. Например, если мы хотим отправить электронное письмо, когда кто-то пытается восстановить свой пароль, мы можем использовать (или «зацепить») действие retrieve_password :
add_action( 'retrieve_password', 'my_plugin_retrieve_password' );
Первый аргумент для add_action сообщает WordPress, к какому действию мы хотим подключиться. Второй аргумент сообщает WordPress, какую функцию вызывать при выполнении действия retrieve_password — в этом случае мы my_plugin_retrieve_password функцию my_plugin_retrieve_password .
Поэтому наш код будет обновлен, чтобы включить функцию, которая делает что-то, когда выполняется действие retrieve_password :
add_action( 'retrieve_password', 'my_plugin_retrieve_password' ); function my_plugin_retrieve_password( $user_login ) { wp_mail( '[email protected]', 'Reset Password Attempt', $user_login . ' attempted to request a password reset.' ); }
фильтры
Фильтры работают аналогично действиям, за исключением того, что они позволяют нам изменять данные, которые возвращаются, выводятся или передаются в подпрограмме. Например, если мы хотим всегда запретить пользователям запрашивать электронную почту для сброса пароля, мы можем подключиться к фильтру allow_password_reset , зарегистрировав наш фильтр:
add_filter( 'allow_password_reset', 'my_plugin_allow_password_reset', 999, 2 ); function my_plugin_allow_password_reset( $enabled, $user_id ) { return false; }
Это возвращает false главной переменной в WordPress, которая определяет, могут ли быть выполнены запросы на сброс пароля.
Добавление действий и фильтров в ваш плагин
Учитывая, что WordPress регистрирует ряд действий и фильтров, к которым разработчики могут подключиться, было бы одинаково полезно зарегистрировать ваши собственные действия и фильтры в вашем плагине, которые разработчики также могут использовать.
Существует два основных способа определения того, где выполнять действия и фильтры:
Общие запросы на новую функциональность
Если ваш плагин имеет несколько запросов на определенную функциональность, у вас может возникнуть желание просто добавить это в свой плагин. Однако, если только небольшая часть пользователей желает получить определенную функциональность, вы должны добавить свои действия / фильтры в этот момент в свой плагин, а затем создать код, который можно запустить в отдельном автономном плагине, который подключается к этим действиям и фильтрам.
Это позволяет разработчикам и конечным пользователям получать необходимую им функциональность, не внося значительных изменений в ядро вашего плагина. Это также полезная модель для тестирования новых функций в виде плагинов, прежде чем объединить их с плагином ядра.
Расширяемость кода
Это немного сложнее. Разработчики стремятся найти решения краткосрочных, неотложных проблем. Хорошие разработчики также будут стремиться обеспечить расширяемость, чтобы эти решения можно было повторно использовать, масштабировать или расширять в будущем.
Везде, где вы видите вероятность того, что это произойдет, но у вас пока нет конкретного варианта использования, пришло время вставить действие или вызов фильтра.
Пример из реального мира
WordPress to Buffer Pro — это плагин для WordPress, который я разработал за последние несколько лет. Я получал все больше и больше запросов на добавление или удаление функциональности — в частности, некоторые разработчики хотели меньше вариантов планирования для своих конечных пользователей плагина, а некоторые хотели большего.
Чтобы удовлетворить потребности всех разработчиков и их конечных пользователей, я построил следующую функцию:
/** * Helper method to retrieve schedule options * * @since 3.0 * * @return array Schedule Options */ static public function get_schedule_options() { // Build schedule options $schedule = array( 'queue_bottom' => __( 'Add to End of Buffer Queue', 'wp-to-buffer-pro' ), 'queue_top' => __( 'Add to Start of Buffer Queue', 'wp-to-buffer-pro' ), 'now' => __( 'Post Immediately', 'wp-to-buffer-pro' ), 'custom' => __( 'Custom Time', 'wp-to-buffer-pro' ), ); // Return filtered results return apply_filters( 'wp_to_buffer_pro_get_schedule_options', $schedule ); }
Код ключа здесь — последняя строка, где мы возвращаем результат вызова apply_filters . Представляя apply_filters , WordPress будет проверять любые зарегистрированные фильтры в теме WordPress или других плагинах, которые были зарегистрированы с помощью add_filter .
Если какие-либо фильтры найдены, они будут выполнены в этот момент.
Поэтому, хотя для массива параметров расписания по умолчанию установлено значение 4, разработчик теперь может создать свою собственную функцию, зарегистрировать ее с помощью add_filter и выбрать, чтобы она возвращала только 2 параметра:
add_filter( 'wp_to_buffer_pro_get_schedule_options', 'my_plugin_get_schedule_options', 10, 1 ); function my_plugin_get_schedule_options( $schedule ) { // Remove the 'custom' option from the scheduling options unset( $schedule['custom'] ); return $schedule; }
add_filter имеет два числовых аргумента в конце:
- 10 : Это относится к порядку приоритетов для запуска этого фильтра. Если в этом конкретном фильтре зарегистрировано несколько фильтров, они запускаются в порядке приоритетов, от низшего к высшему.
- 1 : Это относится к числу аргументов, которые может ожидать вызов функции. Всегда будет хотя бы один аргумент — переменная, которую мы модифицируем, — но в некоторых случаях фильтры могут также предоставлять дополнительные переменные / данные. В этих случаях мы бы соответственно увеличили это число.
Действия работают аналогичным образом; просто добавьте do_action() в код вашего плагина, чтобы разработчики могли подключать свои собственные действия к:
function send_emails( $emails ) { // Some code here... // Allow developers to perhaps send their own emails too do_action( 'send_emails', $emails ); }
Разработчики могут подключиться к этому действию, используя:
add_action( 'send_emails', 'my_plugin_send_emails', 10, 1 ); function my_plugin_send_emails( $emails ) { wp_mail( '[email protected]', 'Subject', 'Message' ); }
Вывод
Мы обнаружили, как WordPress позволяет разработчикам подключаться к ключевым действиям и изменять переменные в ядре WordPress, не внося изменения в основной код. Исходя из этого, мы расширили принципы Actions и Filters в наш собственный плагин, чтобы продемонстрировать, как мы можем позволить разработчикам изменять и расширять наш код плагина, не внося изменений в наш основной плагин.
В следующий раз мы рассмотрим, как документировать действия и фильтры, а также как предоставить более удобную для разработчиков документацию.