Упорядкування типів, переглядів і передплатників WordPress
Одна з речей, які я регулярно намагаюся робити, це оптимізувати те, як я будую функціональні можливості, орієнтовані на WordPress. Нещодавно я говорив про це, але вирішив розширити це трохи більше.
Тобто я думав, що я викладу підхід, який використовую під час створення таких речей, як користувацькі типи публікацій, таксономії, метабокси тощо.
Загалом, подумайте про це як про стратегію, якої я дотримуюся для розробки аспектів проекту, який безпосередньо взаємодіє з WordPress, але може вимагати кількох компонентів, таких як:
- класи, які реєструються в WordPress за допомогою різних хуків,
- класи, які вимагають викликів певних API WordPress
- і класи, які вимагають спеціального перегляду.
Звичайно, не кожна річ, яка взаємодіє з WordPress, потребуватиме всього вищезазначеного (наприклад, чи потрібен користувацький тип публікації перегляд? Ні. Але мета-поле потребує).
Упорядкування типів WordPress
Зважаючи на це, я візьму більш складний приклад, такий як метабокс, а потім розберу спосіб, яким, на мою думку, це можна реалізувати. Я зазначаю те, що вважаю необхідним, і те, що необов’язково.
І, як я вже сказав, я використовую метаблок як приклад, тому що у мене є попереднє посилання, і воно вимагає найбільшого обсягу роботи, тоді як щось інше, наприклад спеціальна таксономія, може не вимагати всіх (лише підмножини) частин .
З огляду на це, дозвольте мені викласти свій підхід.
Нам потрібні передплатники
Я достатньо говорив про цей конкретний шаблон, аж до моменту, коли я просто збираюся зробити посилання на його визначення. Якщо ви читаєте цю сторінку, ви, ймовірно, добре знаєте про різні хуки та способи їх використання в WordPress.
Фото Олександра Ендрюса на Unsplash
Але причина, чому я хочу це згадати, полягає в тому, що замість того, щоб думати про підключення функції, яка запускатиметься, коли щось станеться, я хочу, щоб ви думали про об’єкт, який підписується на подію, коли вона відбувається.
Це означає, що нам знадобиться тип класу підписника.
Класи WordPress API
По-друге, нам потрібні класи, які відповідають за безпосередній інтерфейс із WordPress. Це класи, які звертаються до API WordPress і реєструють те, за що вони відповідають.
Тобто, можливо, вони збираються визначити спеціальний тип публікації або, можливо, як зазначено, вони збираються визначити метабокс.
Визначення представлень
Нарешті, важливо зазначити, що для деяких користувальницьких функцій для області адміністрування WordPress (або навіть загальнодоступних областей) ви можете включити подання, або шаблон, або частково (я зазвичай називаю їх просто поданнями), які будуть працювати над представленням даних для метабокса.
Фотографія Saketh Garuda на Unsplash
Іноді це буде просто інформативно. Іноді для цього знадобиться надсилання даних на сервер і серіалізація даних. Хоча я вважаю, що говорити про останнє було б справді корисно, це виходить за межі поточної сфери цієї публікації.
Можливо, в наступній публікації.
Організація занять
Що все це сказано, як би це виглядало, якщо все це викласти? Принаймні, ми розглядаємо:
- абонент,
- типу WordPress,
- вид
І щонайбільше вас може зацікавити визначення інтерфейсів або абстрактних класів, щоб допомогти забезпечити виконання контракту між різними типами WordPress. Це також здоровий об’єктно-орієнтований принцип, про який я розповім у наступній публікації.
А поки що давайте поговоримо про те, як налаштувати кожен із них.
Абонент
Простіше кажучи, підписник несе відповідальність за те, щоб слухати щоразу, коли WordPress піднімає подію (публікує подію). І коли він помічає, що це так, він запускає функцію, яка підключена до нього.
Зазвичай це визначається шаблоном реєстру. Якщо ви не читали цю публікацію, я рекомендую її, але налаштувати код для неї досить просто:
<?php
class AcmeMetaBoxSubscriber extends AbstractSubscriber
{
public function __construct(string $hook)
{
parent::__construct($hook);
}
public function load()
{
(new AcmeMetaBox())->render();
}
}
Звідти, щоразу, коли виникає подія, функція запускатиметься. Однак ось що: функція має бути частиною певного класу. Таким чином, потреба в WordPress-типу
Тип WordPress
Мені подобається розглядати типи речей, які взаємодіють із WordPress, як типи WordPress (подібно до того, як наші мови програмування мають власні типи, такі як рядки та цілі числа). WordPress має таксономії, метабокси, меню тощо.
Щоб наш передплатник працював належним чином, він повинен бути в курсі нашого типу WordPress. Відповідно до прикладу метабокса, ось як це може виглядати:
<?php
class AcmeMetaBox extends AbstractMetaBox
{
public function render()
{
add_meta_box(
'acme-data',
'Acme Data',
[$this, 'display'],
$this->postType,
'normal',
'high'
);
}
public function display()
{
include_once plugin_dir_path(__FILE__).'Views/acme-data.php';
}
}
Тоді нам потрібно переконатися, що реєстр знає про цей клас.
Вид
Нарешті, для метаблока нам потрібно переконатися, що є представлення, яке принаймні відображатиме інформацію. Серіалізація інформації, а потім оновлення перегляду для користувача — це дещо інший звір.
Але як може виглядати вид? Легко :
<div class="acme-data-metabox">
<?php echo __('Acme Data', 'acme-meta-box'); ?>
<p class="description">
This is the content of the metabox.
</p>
</div>Це просто базова розмітка, яка надає інформацію користувачеві.
Зв’язуємо все разом
Щоразу, коли я збираю все це разом, у мене зазвичай є клас плагіна, з якого все починається. Якщо проект великий, їх може бути більше одного, але в цьому випадку я вважаю, що можна показати, як він виглядає, використовуючи один клас.
Отже, по-перше, основний клас плагіна виглядає так:
<?php
class Plugin
{
private $registry;
public function __construct(Registry $registry)
{
$this->registry = $registry;
}
public function start()
{
array_map(function ($subscriber) {
add_action($subscriber->getHook(), [$subscriber, 'load']);
}, $this->registry->getRegisteredSubscribers());
}
}
А завантажувальна програма для плагіна виглядає так:
<?php
// Setup a filter so we can retrieve the registry throughout the plugin.
$registry = new Registry();
add_filter('acmeApiRegistry', function() use ($registry) {
return $registry;
});
// Register all of our objects with a basic registry.
$registry->add('acmeMetaBoxSubscriber', new AcmeMetaBoxSubscriber('add_meta_boxes'));
$plugin = new Plugin($registry);
$plugin->start();І звідти запускається все інше.
Що щодо розширених функцій?
Я піднімаю це питання, тому що я вже трохи говорив про це раніше в публікації. А саме, я говорив про:
- ідея надсилати дані назад на сервер (і, ймовірно, читати їх знову),
- і я говорив про використання інтерфейсів.
Ці обидві речі, на мою думку, варто вивчити більш детально. Але перш ніж це зробити, заклавши основу для того, як я організую цю інформацію, вона побудована особливо з огляду на те, що вона побудована на попередніх публікаціях, таких як шаблон реєстру та організація класів, орієнтованих на WordPress, також за допомогою мета-блоків.