Я работал над небольшим проектом, больше похожим на веб-приложение, чем на сайт, который требовал разработки как пользовательской темы, так и тесно связанной, но очень специфической функциональности.
Это очень узконаправленный проект (о котором я, вероятно, расскажу в какой-то момент в будущем), но работа над ним заставила меня немного вернуться к аспекту разработки темы 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.
На данном этапе своей карьеры я не делаю много работы, чтобы сосредоточиться на чем-либо, кроме бэкэнда, но в редких случаях, когда у меня есть возможность расширить работу, которую я делаю, я все еще пытаюсь быть как аналитический и вдумчивый о том, как я строю проект.