Статьи

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

Январь 13, 2019

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

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

  1. Введение
  2. Классы
  3. Типы
  4. Управляющие структуры: условные высказывания
  5. Управляющие структуры: петли
  6. Функции и атрибуты
  7. Сфера

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

Для этого нам нужно рассмотреть несколько вещей:

  1. Определяя особенности плагина, который мы собираемся написать,
  2. Поделитесь чем-то, что мы не можем встроить в эту первую версию,
  3. Обсудите архитектуру и организацию файлов плагина.

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

Post Meta Viewer

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

1. Особенности

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

Другие функции заключаются в том, что он будет отображаться в чистом, организованном формате, чтобы мы могли легко определить ключ и значения для идентификатора записи. Мы также введем привязку, которая позволит нам скопировать строку кода, которая позволит нам вызвать часть информации в форме get_post_meta( $post_id, $meta_key, $meta_value ); ,

2. Сильный 1.0

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

Мы могли бы представить возможность:

  • добавить новые пользовательские метаданные поста
  • обновить существующие метаданные поста
  • удалить существующие метаданные поста
  • сортировать столбцы по мета-ключам
  • сортировать столбцы по мета значениям
  • …и так далее

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

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

3. Архитектура и организация файлов

Итак, со всем вышесказанным, давайте сначала поговорим о главных моментах плагина, а затем посмотрим, как мы организуем файлы и компоненты плагина.

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

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

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

Компоненты плагинов

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

  • single-post-meta-manager.php — это основной файл, который регистрирует плагин в WordPress и запускает все.
  • class-single-post-meta-manager-admin.php — это файл, который отвечает за регистрацию и постановку в очередь таблиц стилей, а также за отображение элементов пользовательского интерфейса, которые будут содержать метаданные публикации.
  • single-post-meta-manager-admin.css — это single-post-meta-manager-admin.css стилей, которая будет single-post-meta-manager-admin.css пользовательский интерфейс.
  • class-single-post-meta-manager-loader.php — это файл, который будет координировать действия и фильтры между плагином ядра и классом администрирования.
  • class-single-post-meta-manager.php — это основной файл плагина, который содержит информацию о версии плагина, информацию о слаге плагина, ссылки на загрузчик и файл, в котором мы сообщаем загрузчику, какие объекты и функции отвечают за отображение административных данных. пользовательский интерфейс.
  • README.md предоставляет обычные инструкции о том, как начать работу с плагином.
  • CHANGES.md предоставляет список изменений, которые происходят в каждой версии плагина, который мы выпускаем.

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

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

Организация файлов

Файловая организация относительно проста и, вероятно, лучше всего демонстрируется с помощью изображения:

Чтобы было ясно, вот разбивка того, что вы видите на скриншоте выше:

  • admin/class-single-post-meta-manager-admin.php
  • admin/css/single-post-meta-manager.admin.css
  • includes/class-single-post-meta-manager-loader.php
  • includes/class-single-post-meta-manager.php
  • languages/
  • single-post-meta-manager.php
  • CHANGES.md
  • README.md
  • LICENSE.txt

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

Строим плагин

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

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

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

Теперь перейдем к коду.

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

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
<?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.1.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;
}

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

Административные файлы

Все эти файлы находятся в каталоге admin как указано выше.

Класс администратора Meta Manager для одного поста

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
<?php
 
class Single_Post_Meta_Manager_Admin {
 
    protected $version;
 
    public function __construct( $version ) {
        $this->version = $version;
    }
 
    public function enqueue_styles() {
     
    }
 
    public function add_meta_box() {
     
    }
 
}

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

Мы увидим, как это согласуется позже в коде.

Таблица стилей Meta Manager для одной записи

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

Включает

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

Одиночный пост Meta Manager Loader

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?php
 
class Single_Post_Meta_Manager_Loader {
 
    protected $actions;
 
    protected $filters;
 
    public function __construct() {
 
    }
 
    public function add_action( $hook, $component, $callback ) {
 
    }
 
    public function add_filter( $hook, $component, $callback ) {
     
    }
 
    private function add( $hooks, $hook, $component, $callback ) {
 
    }
 
    public function run() {
     
    }
 
}

Обратите внимание, что в приведенном выше классе мы пометили атрибуты как protected . Это сделано для того, чтобы этот класс имел доступ к своим атрибутам, но другие классы не имеют.

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

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

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<?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.1.0’;
 
    }
 
    private function load_dependencies() {
 
    }
 
    private function define_admin_hooks() {
 
    }
 
    public function run() {
 
    }
 
    public function get_version() {
        return $this->version;
    }
 
}

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

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

Далее

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

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

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

До следующей статьи!

33
Share: