Виджеты WordPress: рефакторинг, часть 8
Когда дело доходит до рефакторинга WordPress Widget Boilerplate, мы проделали большую работу, чтобы привести базу кода в соответствие с более объектно-ориентированным стандартом. Кроме того, мы представили множество других инструментов, которые позволяют нам привести наш код в соответствие с более современными стандартами.
Теперь, когда мы потратили на это время, пришло время вернуться к коду и начать его рефакторинг таким образом, чтобы можно было использовать абстрактные классы и подписчики (которые работают как часть шаблона проектирования, управляемого событиями ).
В конце предыдущего поста я написал:
В следующих сообщениях мы рассмотрим, как мы можем реализовать подписчиков для общедоступной части сайта (то есть там, где отображается содержимое виджета). И то же самое мы сделаем для области администрирования сайта.
Итак, в этом посте мы собираемся сделать именно это. В частности, мы начнем с работы с подписчиком для виджета, а затем сначала заставим базовый виджет отображаться на административной стороне сайта.
Шаблон виджета WordPress: рефакторинг, часть 8
Причина, по которой я заинтересован в том, чтобы в первую очередь сосредоточиться на административной части сайта, заключается в том, что она позволяет нам:
- получить представление о том, как работают подписчики,
- посмотреть, как нужно будет организовать кодовую базу,
- жестко закодировать некоторую информацию перед работой с сериализацией.
Как только все это будет установлено, мы сможем обратить внимание на более продвинутые вещи. А именно, мы сможем ввести подписчиков для отображения информации в области администрирования и подписчиков для очистки, сериализации, извлечения, проверки и отображения данных.
Но сначала давайте проделаем необходимую работу по установке нового класса, настройке автозагрузчика и отображению контента в административной части сайта.
1 Абстрактный подписчик
Давайте сначала рассмотрим абстрактного подписчика, так как это то, что будут реализовывать все подписчики.
<?php
/*
* This file is part of WordPress Widget Boilerplate
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateSubscriber;
/**
* An abstract implementation of a subscriber that requires a hook and the ability to
* start the class.
*/
abstract class AbstractSubscriber
{
/**
* @var string a reference to the hook to which the subscriber should be registered
*/
protected $hook;
/**
* @param string $hook the hook to which the subscriber is registered
*/
public function __construct(string $hook)
{
$this->hook = $hook;
}
/**
* @return string the hook to which the subscriber is registered
*/
public function getHook(): string
{
return $this->hook;
}
/**
* Implements the domain logic for the concrete class implementating this subcriber.
*/
abstract public function load();
}
Обратите внимание, что у него есть две общедоступные функции — конструкция, устанавливающая хук, и функция для извлечения хука. Он также имеет абстрактную функцию загрузки, в которой любой класс, расширяющий этот класс, реализует свою конкретную функциональность.
Вспомните, что из-за того, как WordPress обрабатывает действия и фильтры, все привязано к определенному хуку (либо к тому, который определяет WordPress, либо к настраиваемым хукам).
2 Пространство имен WordPress
Всякий раз, когда я работаю над функциональностью, тесно связанной с WordPress, я стараюсь убедиться, что помещаю ее в пространство имен WordPress. Это указывает мне, как и другим разработчикам, что все, что находится в этом пространстве имен, не может быть отделено от основного приложения.
Итак, внутри каталога src создайте каталог WordPress. Именно здесь будет находиться основной класс Widget вместе с любыми другими классами, которые будут представлены в этой серии.
Это означает, что нам больше не нужен класс в каталоге API. Поэтому обязательно переместите класс, обновите его пространство имен и удалите каталог. Чуть позже у меня будет скриншот и некоторый код для этого.
Кроме того, напомню, ранее в этой серии мы поместили каталог Views в корень каталога src, но теперь мы можем переместить его в каталог WordPress . Так что давай, сделай это сейчас.
Окончательный результат должен выглядеть примерно так:
Теперь мы можем обратить внимание на код.
3 Взгляд на класс виджетов
В этом посте мы немного упростим базовый класс виджетов. Это отменит часть проделанной нами работы, но нам нужна была эта предыдущая работа, чтобы добраться до этой точки.
Сейчас мы сосредоточимся на конструкторе и функции для получения слага виджета. Это то, что в конечном итоге позволит нам увидеть что-то в административной области WordPress.
Итак, во-первых, убедитесь, что ваш класс Widget выглядит следующим образом :
<?php
/*
* This file is part of WordPress Widget Boilerplate
* (c) Tom McFarlin <tom@tommcfarlin.com>
*
* This source file is subject to the GPL license that is bundled
* with this source code in the file LICENSE.
*/
namespace WordPressWidgetBoilerplateWordPress;
use WP_Widget;
class Widget extends WP_Widget
{
/**
* @var string unique identifier for your widget
*/
protected $widgetSlug;
/**
* Initializes the plugin by setting its properties and calling the parent class with the description.
*
* @param mixed $widgetSlug
*/
public function __construct($widgetSlug)
{
$this->widgetSlug = $widgetSlug;
parent::__construct(
$this->getWidgetSlug(),
__('Widget Name', $this->getWidgetSlug()),
[
'classname' => $this->getWidgetSlug().'-class',
'description' => __('Short description of the widget goes here.', $this->getWidgetSlug()),
]
);
}
/**
* Return the widget slug.
*
* @return string slug variable
*/
public function getWidgetSlug()
{
return $this->widgetSlug;
}
}Далее, поскольку мы переместили этот файл в пространство имен WordPress, нам нужно обновить раздел автозагрузки нашего файла конфигурации Composer :
"autoload": {
"psr-4": {
"WordPressWidgetBoilerplate": "src/",
"WordPressWidgetBoilerplateUtilities": "src/Utilities/",
"WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
"WordPressWidgetBoilerplateWordPress": "src/WordPress/"
}
},Далее нам нужно представить подписчика.
4 Знакомство с подписчиком виджетов
Всякий раз, когда у меня есть какой-то базовый класс, я обычно пытаюсь создать простого подписчика, который создает экземпляр базового класса и позволяет ему выполнять свою работу.
Я делаю это, потому что WordPress, как уже упоминалось, использует шаблон проектирования, управляемый событиями, что означает, что все должно быть зарегистрировано в каком-то хуке. И мне не нравится смешивать доменную логику с тем же классом, который подключается к WordPress. Поэтому я их разделяю.
И это то, что делает подписчик. Он регистрируется в WordPress, а затем вызывает класс, отвечающий за фактическое выполнение работы.
С учетом сказанного обратите внимание на каталог Subscriber и добавьте класс с именем WidgetSubscriber. В этом классе добавьте следующий код :
<?php
<?php
namespace WordPressWidgetBoilerplateSubscriber;
use WordPressWidgetBoilerplateWordPressWidget;
/**
* Initializes the core Widget class that's used by WordPress to instantiate the widget,
* renders the administrative area, provide serialization functionality, and displays the
* public-facing view.
*/
class WidgetSubscriber extends AbstractSubscriber
{
/**
* {@inheritdoc}
*/
public function __construct(string $hook)
{
parent::__construct($hook);
}
/**
* Registers the core Widget class using the WordPress APIs.
*/
public function load()
{
register_widget(new Widget('widget-name'));
}
}
Конструктор зарегистрирует класс с помощью определенного хука, который мы рассмотрим чуть позже; затем он будет использовать API WordPress для создания экземпляра нашего виджета (что и происходит в функции загрузки ).
5 Начальная загрузка
Наконец, нам нужно обновить загрузчик, чтобы он:
- регистрирует WidgetSubscriber с соответствующим хуком,
- добавляет подписчика в Реестр ,
- и запускает плагин (что мы и делали).
Начальная загрузка после всего этого должна выглядеть следующим образом :
<?php
namespace WordPressWidgetBoilerplate;
use WordPressWidgetBoilerplateUtilitiesRegistry;
use WordPressWidgetBoilerplatePlugin;
use WordPressWidgetBoilerplateSubscriberWidgetSubscriber;
// Prevent this file from being called directly.
defined('WPINC') || die;
// Include the autoloader.
require_once __DIR__. '/vendor/autoload.php';
// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('wpwBoilerplateRegistry', function() use ($registry) {
return $registry;
});
// Add the Widget base class to the Registry.
$registry->add('widgetSubscriber', new WidgetSubscriber('widgets_init'));
// Start the machine.
(new Plugin($registry))->start();Затем вы сможете войти в WordPress и активировать плагин.
Взгляд на административный район
На данный момент смотреть особо не на что, но мы к этому идем. Во-первых, вы должны заметить, что виджет теперь отображается в области, содержащей доступные виджеты:
И вы также должны увидеть, что когда вы перетаскиваете виджет в область виджетов (или на любую боковую панель), у него нет доступных параметров.
Тем не менее, мы находимся в хорошем состоянии, чтобы продолжать развивать то, что у нас есть. Вы всегда можете продолжить отслеживать разработку шаблона на GitHub.
Продолжение
Далее мы продолжим наращивать функциональность административной области виджета. После этого мы обратим внимание на общедоступную сторону виджета, а также на функциональность сериализации.
Вы должны увидеть, как все начинает обретать форму, когда мы начинаем разделять логику на ее различные компоненты. Если нет, не волнуйтесь — впереди еще много всего.
И окончательная версия Boilerplate, конечно же, продемонстрирует все принципы, на которых мы основываемся в этой серии постов.