Не нашел ветки по этому поводу, поэтому создал эту.
В настоящее время я работаю над довольно сложной темой для 3.1+, и под сложной я имею в виду, что в дополнение к стилю и обычной функциональности внешнего интерфейса я включаю плагины в ядро темы, как для внутреннего, так и для внешнего интерфейса.. Итак, чтобы сделать это немного более организованным, я разделил это на три вопроса:
- Является ли интеграция плагинов обычной практикой?
- Каковы последствия/сложности в отношении автоматического обновления темы/плагинов?
- Каким будет наиболее оптимизированный способ включения каждого плагина без нарушения уже существующей функциональности?
Все приведенные ниже ответы превосходны, поэтому я просто добавлю здесь оговорку: постарайтесь убедиться, что код Theme имеет дело с представлением контента, а генерацию контента оставить на Plugins.
@Chip Bennet Это действительно классическое определение того, что должна делать тема. Тем не менее, грань между ними несколько более размыта: изменение функциональности в презентации, например, общий антиспамовый плагин, обычно считается предназначенным только для плагинов. Но разве это не может быть неотъемлемой частью темы, поскольку тема обычно имеет дело как с представлением комментариев, так и с поведением? Я согласен с вашей точкой зрения, и это действительно самый классический подход к теме, но я надеюсь расширить некоторые аспекты тем, чтобы выйти за рамки этого.
Конечно, вы можете настроить свою тему на защиту от спама, а не на классическую дифференциацию. Вы также можете отказаться от CSS ради классической дифференциации представления и стиля. Хотя ни то, ни другое я бы не советовал. 🙂 Причина отделения представления от функциональности — сохранение функциональности при смене текущей темы. Пользователь (по праву) ожидает, что его функция защиты от спама будет работать одинаково, независимо от того, какую тему он использует.
1) Да, я принимаю точку зрения о наворотах и излишней функциональности. Однако, если бы я сделал их модульными, а не интегрированными, они служили бы для включения в тему, а не для загрузки. 2) Есть ли способ разделить тему или части темы на Git-подобную систему, чтобы были необходимы только дифференциальные обновления? 3) Как обсуждалось с @Drew Gourley, function_exists появляется только на верхнем уровне, чтобы проверить наличие плагина.
Объявление 1) Обслуживание плагинов с темами imo не является хорошей идеей. Трудно копировать файлы вокруг (chmod) и еще. В этом случае я бы предложил просто интегрировать его в тему. Объявление 2) Нет, не совсем так. Но вы могли бы, возможно, добавить что-то вроде константы номера версии в каждый файл и проверить ее, а затем обновить только измененные файлы. Кажется, много работы только для того, чтобы получить эту структуру. Объявление 3) См. редактирование в A.
Дополнение: Если вы используете ООП-подход, вы также можете задаться вопросом, существует ли класс. Количество загруженных классов составляет около 10% от общего числа загруженных функций.
Что касается 3; Даже если я переименую функции, их функциональность все равно будет применяться. Будет ли мне лучше использовать имя оригинального плагина вместе с if
(function_exists), поскольку это даст только одному из них разрешение на работу?На самом деле, это гораздо лучшее решение, чем переименование функций, своего рода способ включения предустановленных плагинов, независимо от того, установлены они у пользователя или нет.
Да, в основном используя существующие плагины, но реализуя их на уровне темы (активируется вместе с темой). Например, я разрабатываю систему комментариев, похожую на Disqus. Плагин будет существовать как отдельный плагин, а также как неотъемлемая часть темы. Я думаю, проблема в том, что его не следует устанавливать вместе с темой, если установлена другая система комментариев или плагин уже установлен. Но каков оптимальный способ обойти такие проблемы?
Не совсем. Обычно у вас есть тема, которая предлагает базовую функциональность. Затем вы расширяете тему только с помощью плагинов для специальных целей, таких как твиттер, календари событий и т. д.
Имхо имеет смысл. В настоящее время я работаю над очень тонкой темой, в которой есть несколько плагинов (подход ООП), которые поставляются в виде плагинов, но не входят в комплект. Эти плагины предлагают теги шаблонов для нумерации страниц, хлебных крошек,… даже цикла с форматами сообщений. Мне нравится идея предлагать функциональность только в том случае, если пользователь действительно этого хочет. Например система комментариев редко нужна, если вы используете WP в качестве CMS для домашней страницы бизнеса, так почему тема должна предлагать это? Еще один плюс этого подхода: вы просто отключаете плагин и заменяете теги шаблона пользовательскими вещами, если они вам не нужны.
При таком подходе важно следующее: не размещайте эти теги шаблона напрямую. Используйте хуки и фильтры, завернутые в функции, чтобы ваша тема не вылетала из-за неопределенных вызовов функций, если вы отключили плагин.
Это то, что я сейчас задаю себе вопросом. Я думал о массивной процедуре, которая проверяет наличие обновлений как в теме, так и в плагинах, но в целом: это не имеет смысла. Имо, даже лучше, если вы просто используете встроенную систему обновлений (или используете какой-то пользовательский класс, если вы не размещаетесь в официальном репо). Зачем: вы обновляете только то, что действительно необходимо обновить. Это экономит время и энергию, поэтому я бы даже назвал это «более экологичным» способом.
Что именно является в вашем случае уже существующим функционалом?
Имена функций
В WordPress есть около 2500 функций, которые считываются по запросу. Так что задавать вопросы
if ( function_exists('whatever') )никогда не бывает хорошей идеей. Лучше использовать уникальные имена. У @Jan Fabry была хорошая идея: здесь он ставит перед всеми своими функциями ответа префиксwpseи номер Q — пример:wpse14277_function_name(). 4- или 5-значное число в сочетании с буквами, скорее всего, останется уникальным. Представьте, что у вас есть 50 пользовательских функций в вашей теме и вы ставите под сомнение их 2.500 на запрос (вы можете сделать математику самостоятельно) — это неэффективно.Изменить:
если вы просто хотите узнать, активен ли плагин, используйте
is_plugin_active()условный тег.Если вы обнаружите, что ваш functions.php становится немного громоздким и неорганизованным, вы можете создать больше файлов.php в своей теме, чтобы упростить организацию, а затем вызывать эти файлы в functions.php через include_once(‘path/filename.php’).
Просто для ясности, вы говорите о включении кода, который уже существует в качестве автономных полнофункциональных плагинов?
Интеграция кода в темы в целом является обычной практикой. Однако объединение чрезмерного количества кода и функциональности, обычно реализуемое с помощью обычных плагинов, рассматривается некоторыми как раздувание функций и попытка привязать пользователей к вашей теме.
Обновление перезаписывает все новой версией.
Это в значительной степени зависит от специфики того, что делает плагин, как он закодирован и требуется ли он для вашей темы вообще или это просто дополнительная функциональность.