Якщо ви підходите до розробки більшої частини плагінів WordPress з об’єктно-орієнтованої точки зору, то зрештою ви досягнете моменту, коли ви не будете багато взаємодіяти безпосередньо з самим ядром WordPress.
І, як на мене, це добре. Це ознака архітектури, що ви правильно структуруєте свій код. Це:
- У вас є WordPress на базовому рівні,
- У вас є набір класів, які знаходяться безпосередньо над WordPress, відповідальними за надсилання інформації до та з WordPress між плагіном,
- І у вас є решта вашого коду, який містить решту функцій.
Те, як це реалізовано, може відрізнятися, але загальний спосіб, яким я це уявляю, є таким же, як я схильний думати про стандартну N-рівневу програму, де у вас є рівень даних, рівень програми та інтерфейс.
За винятком цього часу, у вас є WordPress, рівень для спілкування з WordPress та рештою вашого коду, і, знаєте, рештою вашого коду.
Як можна організувати плагін.
Отже, що станеться, якщо ви захочете зупинити виконання плагіна, коли він має взаємодіяти зі сторонньою залежністю, і має виконуватися, лише якщо ця залежність присутня?
Зупинити виконання плагіна
Через особливості PHP і WordPress це можна зробити кількома способами. Код, яким я збираюся поділитися, не вказує, як це зробити.
Натомість це спосіб зробити це (який було взято з чогось, що знаходиться в розробці). Крім того, я покажу, як він взаємодіє з кількома іншими компонентами плагінів.
1 Конструктор
Якщо ви прочитали достатньо статей про WordPress та об’єктно-орієнтоване програмування, то, швидше за все, виявите, що конструктори не слід використовувати для визначення хуків. І я згоден.
Це створює непотрібний рівень зв’язку, і це ускладнює тестування. Яка ж тоді мета конструктора в коді на основі WordPress?
Я використовую його з тих самих причин, з яких ви очікуєте в будь-якій іншій мові: щоб ініціалізувати властивості класу. У коді нижче ви побачите три речі:
- Я ініціалізую властивість,
- Я перевіряю, чи існує залежність від третьої сторони,
- Якщо ні, я додаю повідомлення про помилку,
- Оновлю нерухомість.
Звичайно, це багатослівно, але також не вдається до розумного коду для ініціалізації значень.
(Чим старшим я ставав, тим більше я полюбляв певний код, оскільки його легше читати, підбирати та працювати швидше, ніж альтернативний.)
2 Метод ініціалізації
Оскільки ми не використовуємо конструктор для роботи з хуками WordPress, ця функція повинна існувати в контексті іншого методу.
Це дає нам спеціальне місце для розміщення цього типу функціональності, відокремлення його від решти класу та його взаємодія з WordPress лише тоді, коли метод явно викликається.
Але пам’ятайте, що вся суть того, що я маю на увазі, пов’язана із зупинкою виконання плагіна, а не з тим, де розміщувати хуки.
Отже, припустимо, що стороння залежність не існує, тоді що? Нагадаємо, у конструкторі було встановлено властивість, яка дозволить нам визначити, чи слід нам рухатися далі з налаштуванням хуків чи ні:
І коли це на місці, решта коду не виконуватиметься.
Багато слів, мало коду
Звучить як багато пояснень для такого маленького коду.
Але частина цього також полягає в тому, щоб спробувати передати важливість того, щоб частини проекту на базі WordPress були відокремлені від решти ядра, щоб частини могли взаємодіяти самі з собою без явної потреби весь час спілкуватися з ядром.