Організація екранів налаштувань WordPress
Оскільки багато хто з нас продовжує рухатися вперед із PHP7+, ми можемо й надалі користуватися перевагами багатьох нових функцій, які пропонує мова.
Тим часом, однак, все ще існують функції PHP і пов’язаного програмного забезпечення, які ми можемо використовувати, щоб допомогти оптимізувати нашу розробку. Найменше з них (і те, про що я трохи писав і говорив) — це простори імен.
Але ось що: мені подобається, щоб файли та каталоги мого плагіна були структуровані таким чином, щоб вони віддзеркалювали угоди про простір імен, яких вони дотримуються. І це можна зробити для таксономій, метаблоків, об’єктів домену, функцій, пов’язаних із базами даних тощо.
Проте в цьому дописі я хочу поговорити про спосіб організації екранів налаштувань WordPress як з логічної (тобто розташування їхньої файлової системи), так і з віртуальної (тобто з простору імен) організаційних структур.
Організація екранів налаштувань WordPress
Перше, що я хочу сказати: хоча я говорю про організацію екранів налаштувань WordPress, я нічого не говорю про API. Натомість припустіть, що для цієї публікації я говорю про наступне:
- спеціальне меню, яке має пов’язану сторінку меню,
- сторінка меню, яка відображає вимоги до сторінки налаштувань (наприклад, поле nonce тощо)
- частина, яка містить фактичні налаштування (або кілька частин, якщо ви бажаєте включити кілька налаштувань).
Я не буду говорити про процес дезінфекції, серіалізації, пошуку, перевірки та відображення. Це суто організаційно.
Мислення через процес
Враховуючи те, що ми збираємося організовувати наші файли через каталоги, які також відображаються 1:1 з просторами імен, давайте подумаємо, що саме нам знадобиться. Я підходжу до цього так:
- Ми створюємо щось спеціально для контекстної програми WordPress. Це вказує на простір імен.
- Ми збираємося створити меню адміністрування, що означає, що ми обидва працюємо в області адміністрування WordPress, тобто в іншому просторі імен, і з меню, які є іншим простором імен.
- Далі нам потрібні файли для відображення стандартного екрана для WordPress, тому нам знадобиться простір імен Views,
- І тоді нам знадобиться доменно-спеціальний код, щоб вставити в представлення, тож нам остаточно знадобиться каталог Partials (і, отже, простір імен).
Отже, остаточна логічна організація даних виглядатиме приблизно так:
Мабуть, найважливіше, що слід зазначити про цю конкретну організацію файлів, полягає в тому, що клас AdminMenu є базовим класом, від якого можуть успадковуватися всі конкретні (або більш конкретні) класи.
Це означає, що клас AcmeAdminMenu успадковує від нього певні властивості та функції, а потім реалізує його логіку або також додає свою логіку.
Простір імен Кожен файл
Коли ви організовуєте свої файли таким чином, простори імен стають майже самоочевидними, чи не так? Ось простір імен для кожного файлу:
- WordPressAdminMenuAdminMenu
- WordPressAdminMenuAcmeAdminMenu
- WordPressAdminMenuViewsSettings
- WordPressAdminMenuViewsSettingsPartials
Зауважте, що оскільки технічно acme-settings.php є просто розміткою для параметрів рендерингу, він не обов’язково має мати простір імен, оскільки він включений у View, який його рендерить.
Незважаючи на це, якщо ви любите зберігати все якомога організованіше, має сенс лише вкласти частину в каталог із такою назвою.
Що щодо коду?
Якщо вам цікаво побачити код для чогось подібного, я розглядаю можливість створення невеликого плагіна, який демонструватиме, як усе це поєднується. Зрештою, це трохи високого рівня, чи не так? Я маю на увазі, що немає реалізації.
Знову ж таки, якщо це допоможе вказати вам правильний напрямок для поточного чи майбутнього проекту, тоді цього може бути достатньо.