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

17 января 2018

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

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

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

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

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

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

    В Введение Классы Таблицы Создание структур: Условные выражения Системы управления: Циклы Функции и атрибуты Scope Построение плагина I

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

Где мы начинаем?

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

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

Loader

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

В некотором смысле он предоставляет оболочку API-интерфейсов 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'] ) );
        }
    }
}

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

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

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

Панель управления

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

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

Единый пост Meta Manager 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__ ) . 'css/single-post-meta-manager-admin.css',
            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__ ) . 'partials/single-post-meta-manager.php';
    }
}

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

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

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

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

Однопользовательский мета-менеджер Partial

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

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

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

Разметка для этого файла выглядит так:

<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>
            <td class="value"><?php print_r( $post_meta_value[0] ); ?></td>
        </tr>
    <?php } ?>
    </table>
</div><!-- #single-post-meta-manager -->

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

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

Стили простого метастата почты

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

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

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

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

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

Файл основного плагина

На этом этапе нам нужно определить основной файл плагина. Это файл, который определяет версию плагина, plugin 's slug (который обычно используется в интернационализации, а также другие функции), создает экземпляр 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__ ) ) . 'admin/class-single-post-meta-manager-admin.php';
        require_once plugin_dir_path( __FILE__ ) . 'class-single-post-meta-manager-loader.php';
        $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;
    }
}

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

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

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

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__ ) . 'includes/class-single-post-meta-manager.php';
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, после чего мы вызываем run, который является тем, что устанавливает все в движении.

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

Что дальше?

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

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

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