Пример разработки WordPress плагина

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

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

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




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

/*
Plugin Name: Имя плагина
Plugin URI: Веб-сайт плагина
Description: Текст описания
Version: Указание версии
Author: Имя автора
Author URI: Личный сайт автора
License: Указание лицензии
*/

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

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

Разработчики WordPress настоятельно просят следовать ряду правил, предъявляемых к плагинам. Среди прочих, можно выделить рекомендации по использованию phpDoc комментариев (Inline Documentation) и определение уникальных имен функций.

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

Рассмотрим пример простого плагина, реализованного с использованием объектно-ориентированного программирования.

Для начала создадим директорию для файлов плагина, назвав ее, например /wp-content/plugins/simple-plugin. Для демонстрационного примера ограничимся двумя файлами: главный файл плагина и файл с классом, где инкапсулируем всю логику:

/simple-plugin/simple-plugin.php
/simple-plugin/Application.php

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

<?php
/*
Plugin Name: Simple Plugin
Plugin URI: http://example.com/
Description: <strong>Just for fun</strong>
Version: 0.1 alfa
Author: Incognito
Author URI: http://example.org/
License: MIT
*/

/**
 * Plugin version
 * 
 * @var string
 */
define('SP_VERSION', '0.1');

/**
 * Path to the plugin directory
 * 
 * @var string
 */
define('SP_DOCUMENT_ROOT', dirname(__FILE__));

require_once 'Application.php';

try {
    $spApplication = new SP_Application();
    $spApplication->run();
} catch (Exception $e) {
    echo $e->getMessage();
}

Если вы работаете с WordPress, то должны знать, что для всех файлов (шаблоны или плагины) необходимо использовать кодировку UTF-8 без BOM, дабы избежать несанкционированного вывода заголовков. По этой же причине опущен закрывающий тэг ?>. Данная практика рекомендуется не только для WordPress, но и для любых PHP приложений.

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

<?php

class SP_Application
{
    /**
     * Backend run mode
     * 
     * @var integer
     */
    const MODE_BACKEND = 1;

    /**
     * Frontend run mode
     * 
     * @var integer
     */
    const MODE_FRONTEND = 2;


    /**
     * Current run mode
     * 
     * @var unknown_type
     */
    protected $currentMode = null;

    public function __construct($autoStart = false) {
        if (is_admin()) {
            $this->currentMode = self::MODE_BACKEND;
        } else {
            $this->currentMode = self::MODE_FRONTEND;
        }

        if ($autoStart) {
            $this->run();
        }
    }

    public function run() {
        if ($this->currentMode === self::MODE_FRONTEND) {
            add_shortcode('simple-plugin', array($this, 'shortCode'));
        }
    }

    public function shortCode() {
        return 'Simple-Plugin version is ' . SP_VERSION;
    }
}

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

Класс, безусловно, ни на что не претендует. Это всего лишь синтетический пример плагина, тем не менее, с некоторой базой, которую можно использовать в небольших «живых» приложениях.
Для того чтобы увидеть результат работы плагина, достаточно добавить в запись блога или страницу вызов шорткода [simple-plugin].

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

Комментарии (4)

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

  2. Спасибо за толковое вступление. Но очень хотелось бы увидеть продолжение. Хоть самое простое — активация/деактивация плагина, создание таблиц, работа с админкой, и прочее.

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

  3. Алексей

    Здравствуйте! Нужна кнопка записи аудио отзыва на сайте WP. То есть необходимо реализовать возможность для пользователя (посетителя сайта) оставить голосовое сообщение нажав на ОДИН раз на кнопку записи на странице сайта. Предпочтительно реализовать в качестве дополнительной опции в каком-либо уже существующем плагине аудио для WP. Файл аудио сообщения должен автоматически попадать в папку сайта на моем хостинге. Сторонние сервисы и сотовых операторов использовать не хочу. С уважением, Алексей. +7 910 742 83 95

Добавить комментарий для Алексей Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *