Я думаю, что один из наиболее недооцененных аспектов — или, возможно, один из редко обсуждаемых аспектов разработки пользовательских плагинов — это возможность включать пользовательские шаблоны в наши плагины WordPress.
И, если честно, я понимаю: я довольно убеждён в том, каким должен быть плагин и какой должна быть тема.
То есть:
- темы для презентаций,
- плагины — это функциональность.
Если я включаю шаблоны в плагин, разве я не делаю то же самое, что когда разработчики включают функциональность в свои темы?
Как и во многих других вещах в разработке, я думаю, что это зависит от обстоятельств. Я имею в виду, что добавление большого количества функций, которые привязывают вас к теме, — это то, чем я не являюсь поклонником. Точно так же, если у вас есть плагин, предназначенный для демонстрации данных во внешнем интерфейсе и не зависящий от темы, тогда это имеет смысл.
Так что нужно быть рассудительным в своих решениях.
Несмотря на это, есть общий набор шагов, которые мы можем использовать при включении пользовательских шаблонов в наши плагины WordPress.
И это то, что этот пост собирается показать.
Если вы собираетесь включать пользовательские шаблоны в плагин, я предполагаю, что вы используете как одиночные, так и архивные шаблоны. Если нет, используйте только те хуки и код ниже, которые вам нужны.
Ибо оба, однако, знают это:
Используя эти хуки, вы можете сообщить WordPress, где в вашем плагине находятся пользовательские шаблоны.
Организация шаблонов
Что касается меня, у меня обычно есть каталог шаблонов в моем плагине, который находится на том же уровне, что и каталоги assets, src и vendor .
Это позволяет легко узнать, где они находятся, и обеспечивает согласованный способ включения их во все созданные вами плагины. В конце концов, есть кое-что, что можно сказать о последовательности в используемых нами соглашениях.
Включение шаблонов
Предполагая, что у вас есть шаблон single-acme.php и шаблон archive-acme.php, включить его несложно. И хотя я больше люблю объектно-ориентированное программирование, я покажу, как включить эти шаблоны с помощью процедурного кода.
При желании этот код легко преобразовать в объектно-ориентированный. Кроме того, я предполагаю, что вы также включаете это для пользовательских типов сообщений.
Вы всегда можете опустить условие для пользовательского типа сообщения, если хотите просто включить эти шаблоны, но, по моему опыту, я редко встречаюсь с такими ситуациями, когда не используются настраиваемые типы сообщений, но я не знаю вашей ситуации.
Тем не менее, вот код.
Определение хуков
Во-первых, нам нужно определить хуки. Это относительно просто, так как мы собираемся использовать хуки, описанные выше.
Во- первых, единый шаблон :
<?php
add_action('single_template', 'acmeIncludeSingleTemplate');
/**
* Includes a custom, single template as included in a plugin. If
* the template is being viewed for a custom post type then use it;
* otherwise, use the template that's provided by WordPress at runtime.
*
* @param string $originalTemplate the path to the original template
*
* @return string the path to the original template or the custom template.
*/
function acmeIncludeSingleTemplate($originalTemplate)
{
// More to come...
}И затем шаблон архива :
<?php
add_action('archive_template', 'acmeIncludeArchiveTemplate');
/**
* Includes a custom, archive template as included in a plugin. If
* the template is being viewed for a custom post type then use it;
* otherwise, use the template that's provided by WordPress at runtime.
*
* @param string $originalArchiveTemplate the path to the original template
*
* @return string the path to the original template or the custom template.
*/
function acmeIncludeArchiveTemplate($originalArchiveTemplate)
{
// More to come...
}И теперь мы можем реализовать код для каждой из функций.
Добавление кода
Итак, сначала мы рассмотрим единый шаблон :
<?php
add_action('single_template', 'acmeIncludeSingleTemplate');
/**
* Includes a custom, single template as included in a plugin. If
* the template is being viewed for a custom post type then use it;
* otherwise, use the template that's provided by WordPress at runtime.
*
* @param string $originalTemplate the path to the original template
*
* @return string the path to the original template or the custom template.
*/
function acmeIncludeSingleTemplate($originalTemplate)
{
$singleTemplate = plugin_dir_path(
dirname(
__DIR__) );
$singleTemplate .= '/templates/single-acme.php';
if ('acme-cpt' === get_post_type(get_the_ID())) {
if (file_exists($singleTemplate)) {
return $singleTemplate;
}
}
return $originalTemplate;
}А теперь шаблон архива :
<?php
add_action('archive_template', 'acmeIncludeArchiveTemplate');
/**
* Includes a custom, archive template as included in a plugin. If
* the template is being viewed for a custom post type then use it;
* otherwise, use the template that's provided by WordPress at runtime.
*
* @param string $originalArchiveTemplate the path to the original template
*
* @return string the path to the original template or the custom template.
*/
function acmeIncludeArchiveTemplate($originalArchiveTemplate)
{
$archiveTemplate = plugin_dir_path(
dirname(
__DIR__) );
$archiveTemplate .= '/templates/archive-acme.php';
if ('acme-cpt' === get_post_type(get_the_ID())) {
if (file_exists($archiveTemplate)) {
return $archiveTemplate;
}
}
return $originalArchiveTemplate;
}Если вы обращали пристальное внимание на код, то знаете, что он мало чем отличается. Собственно, общий процесс можно описать следующим образом:
- определить крючок,
- найти шаблон,
- проверьте пользовательский тип сообщения,
- шаблон есть, используйте его
- в противном случае используйте шаблон по умолчанию
И это процесс как для одиночных, так и для архивных шаблонов.
Написание совместимых шаблонов
И, наконец, и это важно, особенно если вы хотите сделать шаблон как можно более независимым, я стараюсь использовать как можно больше встроенных тегов шаблона WordPress при отображении контента, связанного с плагином. Это позволяет разработчикам темы легко стилизовать ее в соответствии со своей темой.
Нет, вы не сможете разместить каждую тему, но такова природа тем WordPress. Смысл в том, чтобы взять на себя как можно больше работы по извлечению и отображению данных из шаблона, чтобы фронтенд-разработчики могли легко ими управлять.