Статьи

Написание поддерживаемых виджетов WordPress: часть 2 из 2

Декабрь 30, 2018

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

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

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

Понимание хуков, действий и фильтров

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

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

Достаточно просто, правда? Вдобавок ко всему, WordPress имеет солидную документацию для добавления действий [1] и добавления фильтров [2]. Вы можете получить гораздо больше информации о плагинах в API плагинов [3] в Кодексе WordPress [4].

Плагин Boilerplate

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

В конце концов, они все еще состоят из некоторых общих функций:

  • Код основного плагина
  • Таблицы стилей
  • JavaScript
  • Файлы локализации
  • наценка
  • Картинки

Подобно нашему шаблону WordPress Widget, мы можем настроить наш каталог шаблонов так:

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

Плагин Скелет

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

1
<?php /* Plugin Name: TODO Plugin URI: TODO Description: TODO Version: 1.0 Author: TODO Author URI: TODO License: Copyright 2011 TODO ([email protected]) This program is free software;

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

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

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

Есть смысл? Давайте посмотрим на использование этой плиты котла в простом примере.

Рабочий пример с RSS вашего блога

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

Во-первых, требования:

  • Отображать сообщение в нижнем колонтитуле каждого сообщения
  • Сообщение должно появляться только в RSS-ридерах
  • Сообщение должно содержать ссылку на сайт поста

Исходя из этого, создается впечатление, что нам не нужно использовать какой-либо JavaScript, CSS или разметку для создания нашего плагина, чтобы мы могли свести шаблон нашего плагина к коду основного плагина и файлам локализации:

На этом этапе мы можем начать заглушку шаблона с именем и константами плагина:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
/**
 * Initializes constants used for convenience throughout
 * the plugin.
 */
private function init_plugin_constants() {
 
  if(!defined(‘PLUGIN_LOCALE’)) {
    define(‘PLUGIN_LOCALE’, ‘rss-note-locale’);
  } // end if
   
  if(!defined(‘PLUGIN_NAME’)) {
    define(‘PLUGIN_NAME’, ‘RSS Note’);
  } // end if
 
  if(!defined(‘PLUGIN_SLUG’)) {
    define(‘PLUGIN_SLUG’, ‘rss-note-slug’);
  } // end if
 
} // end init_plugin_constants

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
/**
 * Initializes the plugin by setting localization, filters, and administration functions.
 */
function __construct() {
 
// Define constnats used throughout the plugin
$this->init_plugin_constants();
 
    load_plugin_textdomain(PLUGIN_LOCALE, false, dirname(plugin_basename(__FILE__)) . ‘/lang’);
     
// add the note to both the excerpt and the main feed
add_filter(‘the_content’, array($this, ‘display_rss_note’));
add_filter(‘the_excerpt_rss’, array($this, ‘display_rss_note’));
 
} // end constructor

Обратите внимание, что функция использует два фильтра — один для the_content [5] и один для the_excerpt_rss [6]. Мы делаем это потому, что некоторые пользователи предпочитают публиковать только выдержки из своего блога, а не весь контент, и мы хотим убедиться, что мы фиксируем оба случая.

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
/**
 * Appends a short message at the footer of each post viewed in an RSS reader
 * reminding users to visit your site.
 */
public function display_rss_note($content) {
   
  if(is_feed()) {
   
          $content .= ‘<div class=»rss-note»>’;
              $content .= ‘<p>’;
        $content .= __(‘Thanks for reading! Be sure to catch up on the rest of my posts at ‘, PLUGIN_LOCALE);
        $content .= ‘<a href=»‘ . get_bloginfo(‘url’) . ‘»>’;
          $content .= get_bloginfo(‘name’);
        $content .= ‘</a>!’;
      $content .= ‘</p>’;
          $content .= ‘</div>’;
           
      } // end if
       
      return $content;
   
  } // end display_rss_note

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

Это сообщение, которое мы добавляем, просто говорит: «Спасибо за чтение! Обязательно прочитайте остальные мои посты на [Название блога]!» с помощью функции get_bloginfo () [7]. Конечно, вы можете обновить ее, чтобы читать что угодно. Наконец, обратите внимание, что мы обернули это в условие, которое проверяет функцию is_feed () [8]. Это важно, поскольку мы хотим, чтобы этот код срабатывал только в том случае, если содержимое отправляется через RSS-канал.

Вот и все — не так уж плохо, правда? Вы можете скачать полную версию рабочего исходного кода (включая связанный README) для этого плагина на GitHub или прямо здесь, с Wptuts . Шаблон также доступен на GitHub .

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

  1. http://codex.wordpress.org/Function_Reference/add_action
  2. http://codex.wordpress.org/Function_Reference/add_filter
  3. http://codex.wordpress.org/Plugin_API
  4. http://codex.wordpress.org/Main_Page
  5. http://codex.wordpress.org/Function_Reference/the_content
  6. http://codex.wordpress.org/Template_Tags/the_excerpt_rss
  7. http://codex.wordpress.org/Function_Reference/is_feed
  8. http://codex.wordpress.org/Function_Reference/get_bloginfo
34
Share: