Я працював над невеликим проектом, більше схожим на веб-додаток, ніж на сайт, для якого потрібна була розробка спеціальної теми та тісно пов’язаних, але дуже специфічних функцій.
Це дуже вузько сфокусований проект (про який я, швидше за все, розповім про нього в майбутньому), але, працюючи над ним, він змусив мене трохи повернутися до аспекту розробки тем у розробці WordPress.
Ні, я, на щастя, не займаюся дизайном, але мені доводиться працювати над налаштуваннями теми з функціональної точки зору. Роблячи це, однак, це змусило мене переглянути необхідні functions.phpта деякі міркування, яких я ніколи раніше не мав.
Крім того, це змусило мене глибше поглянути на використання mu-pluginsта запитати, коли вони потрібні та чому я не використовував їх частіше в минулому (або навіть коли їх справді потрібно було б використовувати).
Тож я збираюся трохи поетично розповісти про це.
TL;DRКоли я розробляв тему, functions.phpїї використовували для двох речей (що само по собі проблематично), але все ж:
- щоб увімкнути або вимкнути функції в темах,
- для визначення функціональних можливостей конкретної теми.
У Посібнику розробника теми йдеться:
У цьому
functions.phpфайлі ви додаєте унікальні функції до своєї теми WordPress. Його можна використовувати для підключення до основних функцій WordPress, щоб зробити вашу тему більш модульною, розширюваною та функціональною.Функції теми, Посібник розробника тем
І я це розумію, але з моєї точки зору та в міру того, як WordPress розвивався, я вважаю, що functions.phpйого слід присвятити тематичним функціям з точки зору речей, які підключаються безпосередньо до ядра, наприклад:
- функціональність настроювача,
- функціональність меню,
- оформлення сценарію та стилю,
- і так далі.
Але якщо є щось, що потрібно запустити під час одного з підхоплень, і це скоріше за напрямками доменно-спеціальної логіки, тоді це не належить до цього файлу.
Однак виникає запитання: де розташовуються функції, що стосуються домену?
Введіть обов’язкові плагіни
Я знаю, що такі речі, як incкаталоги, стають все більш поширеними, але мене це не турбує, коли мова йде про розробку теми, особливо коли розробка теми не в моєму центрі уваги, а ця конкретна структура каталогу не є моїм стилем.
У будь-якому разі, коли мова йде про вузькоспеціалізовані рішення (де рішення є поєднанням презентації та вузької функціональності), я починаю думати про mu-plugins.
І причина, чому я не думаю про стандартний плагін WordPress, полягає в тому, що вони, як правило, розроблені для роботи з будь-якою темою та для додавання функціональності. З mu-plugins.
Обов’язкові плагіни (так відомі як mu-plugins) — це плагіни, встановлені в спеціальному каталозі в папці вмісту, які автоматично вмикаються на всіх сайтах під час встановлення.
Обов’язкові плагіни, WordPress.org
Ось мій процес мислення:
- Теми для презентації
- Плагіни призначені для функціональності.
- Плагіни призначені для використання незалежно від теми та на всіх сайтах.
- Обов’язкові плагіни – це плагіни, які ввімкнено та використовуються за умовчанням
- Таким чином, доменно-спеціальна логіка для спеціалізованого рішення повинна міститися в обов’язковому додатку.
Звичайно, можна стверджувати, що деякі теми можуть вимагати обов’язкових функцій, але чи це все одно не відповідає ідеї, що ці функції повинні міститися в обов’язковому плагіні?
Незважаючи на це, підхід, якого я дотримувався, такий:
- Функціональність, яка спеціально пов’язує функції теми з ядром WordPress, входить до
functions.php. - Функціональність, яка є доменною логікою, але вимагає, щоб усе рішення працювало, знаходиться в
mu-plugin.
На цьому етапі моєї кар’єри я не роблю багато роботи, зосереджуючись на чомусь, окрім серверної частини, але в тих рідкісних випадках, коли я маю можливість розширити роботу, яку виконую, я все ще намагаюся бути як аналітичний і вдумливий у те, як я будую проект.