Существует ли простая для понимания схема для определения того, какой код принадлежит плагину или файлу functions.php?
Есть много случаев и много споров на эту тему, в основном потому, что есть некоторые неправильные представления о внутренней работе WordPress. Я прошу ответ на основе фактов, а не мнений.
Хочу понять, как обрабатывать эти моменты (и, возможно, больше):
- пользовательские типы сообщений и таксономии
- контактные формы
- шорткоды
- пользовательские виджеты
add_theme_support( 'automatic-feed-links' );
- SEO функции как пользовательские метаэлементы
- переключатель темы
Часто есть плюсы и минусы для обеих сторон. Нужны критерии, которые может понять новичок, возможно, контрольный список — с причинами.
Добавьте пользовательский код в дочернюю тему, чтобы при обновлении родительской темы пользовательский код не терялся.
Вы также можете создать специальный плагин для сайта, который также содержит весь ваш код.
Что касается написания кода по сравнению с плагинами, вы можете использовать плагины и функции, однако для большинства из того, что вам нужно, ручное кодирование является лучшим, поскольку его легче модифицировать, за исключением некоторых случаев, таких как мета-блоки, где вы можете рассмотреть использование плагин, если вы не разработчик темы.
Чаще всего, особенно для тех, кто только начинает, гораздо быстрее и проще просто добавлять в тему все, что вам нужно, и вызывать ее.
Тем не менее, если вы работаете над WordPress на полурегулярной основе, вам следует серьезно подумать о следующем :
Это должно обрабатывать все операции с плагином: активацию, деактивацию, обновление версии, создание панелей администратора и удаление.
Также:
Теперь вы можете правильно строить вещи и быстрее выполнять будущие проекты.
Это должно обрабатывать все, что обычно требуется в теме:
Сделав это, создайте скелет дочерней темы, который использует вашу основную тему.
Как только вы сделаете эти две вещи, создание новых сайтов для людей станет намного быстрее.
Если вы выполните вышеизложенное, вы можете поработать над следующим:
Я бы начал с этого вопроса: Связана ли функциональность с представлением контента или с генерацией / управлением контента или сайта, или идентичности пользователя?
Если функциональность не связана конкретно с представлением контента , то она находится прямо внутри территории подключаемого модуля. Этот список длинный:
wp_head
, таких как канонические ссылки, генератор и другие HTML-мета и т.д.Если функциональность связана с представлением контента , то она является кандидатом для включения в тему. Несколько примеров:
add_theme_support()
Обычно эти два вопроса дают довольно четкую линию дифференциации. Однако есть исключения.
Пользовательские типы постов
Пользовательские типы записей, например, представляют собой уникальный гибрид создания и представления контента, учитывая то, как иерархия шаблонов работает для одного типа поста.
Ссылки на социальные сети
Точно так же я бы сказал, что ссылки на профили в социальных сетях, которые стали почти повсеместными в текущих темах, являются территорией плагинов, поскольку они не имеют никакого отношения к представлению контента. Лучшим решением было бы определить эти профили где-то в ядре; однако в настоящее время нет стандартных / согласованных способов определения этих ссылок. Они лучше всего определены на уровне настройки сайта или для каждого пользователя?р>
Итак, опять же, в долгосрочной перспективе, решение этой проблемы заключается в том, чтобы либо ядро определяло, где были определены эти ссылки, либо сообщество разработчиков тем могло выработать собственный консенсус. Между тем, на самом деле ничего нет, кроме как держать их в каждой теме.
Все, что реализовано с помощью
add_theme_support ()
, может быть реализовано только через тему. Использованиеadd_theme_support ('automatic-feed-links')
в теме фактически обеспечивает согласованное взаимодействие от темы к теме.Ответ прост:
Зависит ли код от какой-либо функциональности, встроенной в конкретную тему? Если да, то вставьте тему.
Хотите ли вы, чтобы этот код передавался между сайтами и темами? Если да, то вставьте в плагин.
Если вы ответили «нет» на оба вышеперечисленных вопроса, представьте себе сайт через 5 лет, когда придет время для редизайна. Переживет ли функция кода, которую вы пишете, следующее обновление дизайна? Если да, вставьте в плагин.
Кроме того, если вы не используете дочерние темы и планируете обновить тему, я бы также предложил вам использовать плагин.
Простой тест, где лучше всего разместить код:
вам не хватает функциональности, блог не работает должным образом или остались фрагменты старой темы (например, шорткоды)?
да: вставьте его в плагин
нет: оставьте его в functions.php
Примеры. Введите шорткод. После переключения темы простые шорткоды остаются в ваших постах. Так что лучше будет поместить его в плагин.
Напишите функцию для отображения последних комментариев. После переключения темы все в порядке, потому что, возможно, другая тема имеет эквивалентную функцию.
Это действительно зависит от кода и от того, что он нужно сделать. Некоторые коды влияют только на стиль или содержание темы, другие изменяют посты в блоге.