Большая часть работы, которую я сейчас делаю, сосредоточена на пользовательских плагинах или утилитах, которые работают поверх WordPress.
Если бы вам нужно было понять, сколько проектов, которые я создаю, собраны вместе, вы бы рассмотрели WordPress (и все, что с ним связано) как основу, а затем код имеет слой, который взаимодействует с WordPress, и который может общаться со сторонними API.
При этом, однако, часто есть интерфейсный компонент, который требует, чтобы я отображал информацию в шаблоны. Хотя создание шаблонов для WordPress по своей сути не сложно (хотя я бы хотел, чтобы у нас было что-то большее, чем теги шаблонов — например, механизм шаблонов, это другой пост), я думаю, что стоит рассмотреть несколько способов, которыми мы можем обрабатывать пользовательские шаблоны, которые мы связали с плагинами.
Тем не менее, один из первых вопросов, который часто возникает в связи с этим утверждением, заключается в следующем.
Зачем включать пользовательские шаблоны в плагин?
И я понимаю это на некоторых уровнях.
- Хранение шаблонов в плагине немного стирает границы между темами и плагинами, особенно когда вы оставляете темы для презентации, а плагины — для бизнес-логики.
- Просить пользователей копировать файлы темы из одного места в другое — плохой пользовательский опыт.
Но есть несколько опровержений или, возможно, прямых исключений из приведенных выше случаев.
Хук WordPress template_redirect
Прежде чем говорить о хуке WordPress template_redirect, я хочу немного поговорить о пунктах, упомянутых выше.
1 Шаблоны в плагинах
Если вы создаете пользовательский плагин, который взаимодействует как с WordPress, так и со сторонним API или использует какую-либо комбинацию репозиториев, фабрик, моделей и представлений, вам нужно будет отобразить эту информацию на передней панели. -end, и он должен быть независимым от темы.
Это не означает, что кто-то не может стилизовать элементы на странице или включать шаблон в свою работу, но это означает, что подключаемый модуль должен предоставлять базовый уровень информации, отображаемой пользователю.
2 Плохо просить пользователей копировать файлы
Помните слоган, который Apple когда-то и часто рекламировала: «Это просто работает? «Хотя это может быть не то, что они говорят так часто, как когда-то (если вообще, то больше), мне нравится идея «просто работать» для пользователя, и это то, к чему я стараюсь стремиться в своей работе. Работа.
Поэтому, когда дело доходит до создания пользовательских шаблонов или представлений для плагинов, я не хочу просить пользователя копировать файлы. Я просто хочу, чтобы они:
- установить плагин,
- нажмите активировать.
Вот и все. Остальное должно быть либо самоочевидным, либо хорошо задокументированным.
Назад к крючку
Итак, давайте на мгновение предположим, что мы создали плагин, который включает в себя несколько основных шаблонов (или представлений, в зависимости от используемого вами жаргона) и что шаблоны должны быть записаны в корень каталога активной темы.
Вы можете использовать хук template_redirect (и многие популярные плагины делают это). Подробнее об этом можно прочитать здесь, но суть в следующем:
Этот хук действия выполняется непосредственно перед тем, как WordPress определяет, какую страницу шаблона загрузить. Это хороший хук, который можно использовать, если вам нужно выполнить перенаправление с полным знанием запрошенного контента.
И, чтобы было ясно, я не отговариваю от использования этого хука. Я просто предлагаю альтернативу. И вот это (поскольку это должно работать следующим образом):
- активировать плагин,
- найти активную тему,
- если они еще не существуют, скопируйте файлы шаблонов из плагина в корневой каталог активной темы.
Последний шаг имеет решающее значение, потому что, если файлы шаблонов существуют, важно не перезаписать их, прежде всего потому, что пользователь мог записать свои настройки.
С учетом сказанного, вот как вы можете сделать это в одной функции (с комментариями, чтобы показать, что вы используете).
<?php
add_action('plugins_loaded', __NAMESPACE__. 'acmeCopyTemplates');
/**
* Copies the template files from the `assets/templates` directory to the root directory
* of the currently active theme (if they do not already exist).
*/
function acmeCopyTemplates()
{
// Find the currently active theme.
$activeThemeDir = get_template_directory();
/**
* Read all of the template files from assets/templates into an array but
* exclude the '.' and the '..' from the array.
*/
$templates = array_slice(scandir(dirname(__FILE__).'/assets/templates'), 2);
/**
* Now copy all of these files to the active theme directory.
* If the file already exists, then don't do it.
*/
foreach ($templates as $template) {
if (!file_exists($destination = trailingslashit($activeThemeDir).$template)) {
continue;
}
$source = dirname(__FILE__).'/assets/templates/'.$template;
$destination = trailingslashit($activeThemeDir).$template;
copy($source, $destination);
}
}
Обратите внимание, что здесь используются несколько функций PHP. А именно:
Все это, я думаю, удобно и важно знать, независимо от характера, в котором вы их используете.
Хосты поддерживают это?
Некоторые хосты делают. Я точно знаю, что такие хосты, как WPEngine, этого не делают, и это также не критика хоста. Некоторые делают это из соображений безопасности; другие разрешают это, но это не означает, что они менее безопасны — это просто означает, что их инфраструктура настроена по-другому.
В конечном счете, это показывает, что есть и другие способы сделать шаблоны доступными для пользователей при использовании плагина, но это не единственный способ, и он не всегда может работать.
Однако наличие опций — это хорошо, особенно если вы предпочитаете определенную архитектуру в своем плагине другой.