Объектно-ориентированное программирование в WordPress: создание плагина II

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

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

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

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

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

Для справки мы рассмотрели:

С учетом сказанного, давайте продолжим, где мы остановились

С чего начать?

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

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

Загрузчик

Первый класс, который мы собираемся завершить, находится в includes/class-single-post-meta-manager-loader.php . Если вы помните предыдущую статью, этот класс отвечает за координацию действий и фильтров между плагином ядра и классом администрирования.

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

Во-первых, давайте посмотрим на класс:

<?php
 
class Single_Post_Meta_Manager_Loader {
 
    protected $actions;
 
    protected $filters;
 
    public function __construct() {
 
        $this->actions = array();
        $this->filters = array();
     
    }
 
    public function add_action( $hook, $component, $callback ) {
        $this->actions = $this->add( $this->actions, $hook, $component, $callback );
    }
 
    public function add_filter( $hook, $component, $callback ) {
        $this->filters = $this->add( $this->filters, $hook, $component, $callback );
    }
 
    private function add( $hooks, $hook, $component, $callback ) {
 
        $hooks[] = array(
            ‘hook’ => $hook,
            ‘component’ => $component,
            ‘callback’ => $callback
        );
 
        return $hooks;
 
    }
 
    public function run() {
 
        foreach ( $this->filters as $hook ) {
            add_filter( $hook[‘hook’], array( $hook[‘component’], $hook[‘callback’] ) );
        }
 
        foreach ( $this->actions as $hook ) {
            add_action( $hook[‘hook’], array( $hook[‘component’], $hook[‘callback’] ) );
        }
 
    }
 
}

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

Существует два protected атрибута, каждый из которых ссылается на arrays определенные в конструкторе. Один предназначен для действий, другой для фильтров.
Есть две public функции. Один предназначен для простого добавления действий, другой предназначен для простого добавления фильтров. Обратите внимание, что каждый принимает три компонента: имя ловушки, главный объект, который имеет функцию, которую нужно вызвать, и функцию, которая будет вызвана во время фактического выполнения ловушки. Для получения дополнительной информации о действиях и фильтрах см. Эту ссылку .
Далее у нас есть private функция, которая используется для упрощения двух предыдущих public функций, так что у нас есть единственное место, чтобы добавить хук к соответствующему массиву.
Наконец, у нас есть функция run которая используется для подключения всех определенных хуков. Это то, что зарегистрирует все наши пользовательские функции в WordPress.

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

Панель администрирования

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

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

Один пост администратор мета-менеджер

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

Давайте посмотрим на полный код, а затем рассмотрим, что он делает.

<?php
 
class Single_Post_Meta_Manager_Admin {
 
    private $version;
 
    public function __construct( $version ) {
        $this->version = $version;
    }
 
    public function enqueue_styles() {
 
        wp_enqueue_style(
            ‘single-post-meta-manager-admin’,
            plugin_dir_url( __FILE__ ) .
            array(),
            $this->version,
            FALSE
        );
 
    }
 
    public function add_meta_box() {
 
        add_meta_box(
            ‘single-post-meta-manager-admin’,
            ‘Single Post Meta Manager’,
            array( $this, ‘render_meta_box’ ),
            ‘post’,
            ‘normal’,
            ‘core’
        );
 
    }
 
    public function render_meta_box() {
        require_once plugin_dir_path( __FILE__ ) .
    }
 
}

Это относительно простой класс, предполагающий, что вы знакомы с wp_enqueue_style и add_meta_box . Если нет, просмотрите связанные статьи, а затем вернитесь к этому сообщению.

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

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

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

Одиночный пост Мета-менеджер Частичный

Некоторым разработчикам нравится писать разметку для представлений meta box в PHP и сохранять их в очень длинные строки.

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

В этом случае нам нужен файл, который отображает все метаданные, связанные с текущим сообщением, в элементе table который содержится внутри мета-блока.

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

<div id=»single-post-meta-manager»>
 
    <?php $post_meta = get_post_meta( get_the_ID() );
    <table id=»single-post-meta-manager-data»>
    <?php foreach ( $post_meta as $post_meta_key => $post_meta_value ) { ?>
        <tr>
            <td class=»key»><?php echo $post_meta_key;
            <td class=»value»><?php print_r( $post_meta_value[0] );
        </tr>
    <?php } ?>
    </table>
 
</div><!— #single-post-meta-manager —>

Хотя разметка и минимальный PHP, содержащийся в этом файле, должны быть достаточно get_post_meta , это зависит от вашего знания функций get_post_meta и get_the_ID .

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

The Simple Post Meta Admin Стили

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

Для этого мы отредактируем css/simple-post-meta-manager.css .

#single-post-meta-manager-data {
    width: 100%;
}
 
#single-post-meta-manager-data .key {
    font-weight: bold;
}

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

Но этого достаточно для того, что мы хотим сделать сейчас.

Основной файл плагина

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

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

<?php
 
class Single_Post_Meta_Manager {
 
    protected $loader;
 
    protected $plugin_slug;
 
    protected $version;
 
    public function __construct() {
 
        $this->plugin_slug = ‘single-post-meta-manager-slug’;
        $this->version = ‘0.2.0’;
 
        $this->load_dependencies();
        $this->define_admin_hooks();
 
    }
 
    private function load_dependencies() {
 
        require_once plugin_dir_path( dirname( __FILE__ ) ) .
 
        require_once plugin_dir_path( __FILE__ ) .
        $this->loader = new Single_Post_Meta_Manager_Loader();
 
    }
 
    private function define_admin_hooks() {
 
        $admin = new Single_Post_Meta_Manager_Admin( $this->get_version() );
        $this->loader->add_action( ‘admin_enqueue_scripts’, $admin, ‘enqueue_styles’ );
        $this->loader->add_action( ‘add_meta_boxes’, $admin, ‘add_meta_box’ );
 
    }
 
    public function run() {
        $this->loader->run();
    }
 
    public function get_version() {
        return $this->version;
    }
 
}

Класс содержит следующие атрибуты:

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

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

load_dependencies используется для импорта всех файлов, которые используются в этом плагине, таких как Admin Manager и Loader.
define_admin_hooks — это то, как мы используем Loader для координации функций, определенных в нашем классе Admin, которые ставят в очередь наши стили и наш мета-блок с WordPress. Вот как мы разделяем проблемы нашего плагина и следим за тем, чтобы каждый класс был единой целью.
run — это функция, которая приводит все в движение, так что все функции плагина работают при активации в WordPress.

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

Загрузочный плагин

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

Что бы вы ни называли, это файл, который регистрируется в WordPress и приводит все в движение. Давайте посмотрим на код, а затем рассмотрим, что он делает потом:

<?php
/*
 * Plugin Name: Single Post Meta Manager
 * Plugin URI: http://github.com/tommcfarlin/post-meta-manager
 * Description: Single Post Meta Manager displays the post meta data associated with a given post.
 * Version: 0.2.0
 * Author: Tom McFarlin
 * Author URI: http://tommcfarlin.com
 * Text Domain: single-post-meta-manager-locale
 * License: GPL-2.0+
 * License URI: http://www.gnu.org/licenses/gpl-2.0.txt
 * Domain Path: /languages
 */
 
if ( ! defined( ‘WPINC’ ) ) {
    die;
}
 
require_once plugin_dir_path( __FILE__ ) .
 
function run_single_post_meta_manager() {
 
    $spmm = new Single_Post_Meta_Manager();
    $spmm->run();
 
}
 
run_single_post_meta_manager();

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

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

Наконец, мы вызываем require_once для включения файла основного плагина, который мы рассмотрели выше, а затем мы определяем функцию и Single_Post_Meta_Manager экземпляр Single_Post_Meta_Manager после чего мы вызываем run который и run все в движении.

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

Что дальше?

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

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

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

Объектно-ориентированное программирование в WordPress: создание плагина II

С чего начать?

Загрузчик

Панель администрирования

Один пост администратор мета-менеджер

Одиночный пост Мета-менеджер Частичный

The Simple Post Meta Admin Стили

Основной файл плагина

Загрузочный плагин

Что дальше?

Категории

Последние статьи

Рефакторинг Hudson God Class

Альтернативы синтаксиса Java лямбда

Morphia и MongoDB: развивающиеся структуры документов

OpenShift Express: развертывание приложения Java EE (с поддержкой AS7)

Интеграция jqGrid, REST, AJAX и Spring MVC