Где поставить мой код: плагин или functions.php?

Существует ли простая для понимания схема для определения того, какой код принадлежит плагину или теме functions.php?

Там есть много случаев , и много дискуссий о той теме, в основном , потому что есть некоторые неправильные представления о внутренней работе WordPress. Я прошу ответ на основе фактов, а не мнений.

Следует объяснить, как обрабатывать эти моменты (и, вероятно, больше):

• пользовательские типы сообщений и таксономии
• контактные формы
• шорткоды
• пользовательские виджеты
• add_theme_support( 'automatic-feed-links' );
• SEO работает как пользовательские metaэлементы
• переключатель темы

Часто есть плюсы и минусы для обеих сторон. Наш самый популярный вопрос « Лучший сборник кода» для вашего файла functions.php содержит множество фрагментов кода в качестве ответов, которые, по крайней мере, являются дискуссионными.
Нам нужны критерии, которые может понять новичок, возможно, контрольный список - с причинами.

См. Также связанный с этим вопрос Чипа Беннетта на нашем мета-сайте: Вопросы, конкретно требующие решения «без плагина»

Связанный: Где я могу разместить фрагменты кода, которые я нашел здесь или где-то еще в Интернете?

Я бы начал с этого вопроса: связана ли эта функциональность с представлением контента или с генерацией / управлением контентом, или с сайтом, или с идентификацией пользователя?

Если функциональность не связана конкретно с представлением контента , то это прямо в пределах территории плагина. Этот список длинный:

• Модификация основных WP-фильтров ( wp_headконтента, такого как канонические ссылки, генератор и другие HTML-мета и т. Д.
• Сайт Фавикон
• Постконтентные шорткоды
• Опубликовать ссылки для обмена
• Сценарии нижнего колонтитула Google Analytics (и аналогичные)
• SEO инструменты / элементы управления
• и т.п.

Если функциональность связана с представлением контента , то он является кандидатом на включение в тему. На этом этапе я вернусь к критерию переключения тем в @ Raf912 : скучаете ли вы по функциональности при переключении тем? Если ответ на этот вопрос - нет , то функциональность принадлежит теме. Некоторые примеры:

• Удаление / переопределение ядра WP Галерея CSS
• Фильтрация длины выдержки из сообщения, текста "читать дальше" и т. Д.
• Все, что реализовано с помощью add_theme_support()(я полагаю, это должно быть очевидно)
• Пользовательские CSS

Как правило, эти два вопроса обеспечат довольно четкую линию дифференциации; Однако есть исключения.

Пользовательские типы сообщений

Например, пользовательские типы записей представляют собой уникальный гибрид генерации и представления контента, учитывая то, как иерархия шаблонов работает для страниц индекса архива с одним постом и страниц с одним постом . Аспект создания контента CPT обычно помещал бы их прямо в Территорию Плагина; тем не менее, плагины не могут определять шаблоны страниц, которые по своей природе вписываются в дизайн / макет / стиль для любой данной Темы (особенно, если CPT отображает не обычный заголовок / контент / мета, или связанные с ним пользовательские таксономии).

В долгосрочной перспективе, решение этого неравенства, IMHO, состоит в том, чтобы иметь стандартную конвенцию / консенсус для определения CPT для заданных типов контента (списки недвижимости, события календаря, продукты электронной коммерции, записи книг / медиатек и т. Д. .). Таким образом, сгенерированный пользователем контент останется переносимым между Темами, которые реализуют стандартное / условное определение данного CPT, в то время как разработчики Тем сохраняют гибкость в определении дизайна / макета / стиля этого CPT в файлах шаблонов Тем.

Ссылки на социальные сети

Точно так же я бы обычно говорил, что ссылки на профили в социальных сетях, которые стали почти повсеместными в современных темах, являются территорией плагинов, потому что они не имеют никакого отношения к представлению контента. Лучшим решением было бы определить эти профили где-то в ядре; однако в настоящее время нет стандартных / согласованных способов определения этих ссылок. Они лучше всего определены на уровне настройки сайта или для каждого пользователя? Если для каждого пользователя мета какого пользователя отображается в шаблоне? и т.п.

Итак, опять же, в долгосрочной перспективе, решение этого несоответствия заключается в том, чтобы либо ядро ​​могло определить, где эти ссылки определены, либо сообщество разработчиков тем могло бы выработать собственный консенсус. Между тем, на самом деле ничего нет, кроме как держать их определенными в каждой теме.

Простой тест, где код лучше всего размещен:

• написать код в functions.php
• переключить тему

• вам не хватает функциональности, блог не работает должным образом или остались фрагменты старой темы (например, шорткоды)?

  • да: вставьте его в плагин

  • нет: оставьте это в functions.php

Примеры: Написать шорткод. После переключения темы простые шорткоды остаются в ваших сообщениях. Так что лучше будет поместить его в плагин.

Напишите функцию для отображения последних комментариев. После переключения темы все в порядке, потому что, возможно, другая тема имеет эквивалентную функцию.

Это действительно зависит от кода и того, что он будет делать. Некоторые коды влияют только на стиль или содержание темы, другие изменяют сообщения в блоге.

Я не думаю, что есть простой ответ на этот вопрос, но я уверен, что мы могли бы составить схему, чтобы помочь с решением. Вот примерная схема такой блок-схемы, которую можно и нужно расширять. Комментарий с предложениями!

• Этот код будет размещен на WordPress для одного сайта?
  • Да. Меняется ли тема сайта только с серьезными изменениями и изменениями в функциональности?
    • Да. Является ли данный код конкретным для данной конструкции ?
      • Да: functions.php
      • №: плагин
    • Нет (меняется часто или по прихоти) - Плагин
  • Нет (Multsisite) - Вы размещаете многосайтовую установку ИЛИ это хост-решение, позволяющее устанавливать плагины?
    • Да. Соответствующая функциональность относится к данному сайту или может / должна ли она использоваться другими сайтами в сети?
      • Специфические для этого сайта: functions.php
      • Разделяется между несколькими сайтами. Хотите ли вы использовать его на каждом сайте?
        • Да: плагин, хранящийся в каталоге mu-plugins или активированный по сети
        • Нет: это сеть не связанных между собой сайтов? (например, разные клиенты)
          • Да: было бы плохо или непрофессионально, если бы клиент A увидел или активировал плагин, который вы написали для клиентов B, C и D? (например, может быть, это сломает сайт или вызовет нежелательную функциональность)
            • Да: functions.php
            • №: плагин
          • Нет: возможно плагин
    • Нет (размещается в сервисе, таком как VIP, который не поддерживает плагины): используйте functions.php

• Родительские темы - иногда с общей функциональностью было бы лучше создать родительскую тему и поместить ее в файл functions.php родительской темы.
• Каталоги плагинов для больших многосайтовых установок могут быстро стать неуправляемыми, поэтому иногда совместно используемые функции, используемые небольшим процентом сайтов (например, <1%), лучше всего дублировать в файлах functions.php.

Отсюда Темы VS Плагины

Добавьте пользовательский код в дочернюю тему, чтобы при обновлении родительской темы пользовательский код не терялся.

Вы также можете создать плагин для конкретного сайта, который также содержит весь ваш пользовательский код.

Что касается написания кода по сравнению с плагинами, вы можете использовать плагины и функции, однако для большей части того, что вам нужно, ручное кодирование является лучшим, поскольку его легче модифицировать, за исключением некоторых случаев, таких как мета-блоки, где вы можете рассмотреть возможность использования плагина, если только вы Вы разработчик темы.

 function modify_contact_methods($profile_fields) {

// Add new fields
$profile_fields['twitter'] = 'Twitter Username';
$profile_fields['facebook'] = 'Facebook URL';
$profile_fields['gplus'] = 'Google+ URL';

return $profile_fields;
}
add_filter('user_contactmethods', 'modify_contact_methods');

http://codex.wordpress.org/Plugin_API/Filter_Reference/user_contactmethods

1. Добавить новый пользовательский тип записи - Код
2. Добавить новые поля для пользователей - код выше
3. Добавить новые виджеты - Код
4. Добавить пользовательские постоянные ссылки - Настройки постоянной ссылки WordPress

Я знаю, что это мертвая лошадь и что Чип в значительной степени покрыл ее, но хотел добавить несколько мыслей.

Если вы делаете живое программирование и обнаруживаете, что работаете над WordPress сайтами в сжатые сроки, вы обнаружите, что это действительно приходит время.

Чаще всего, особенно для тех, кто только начинает, гораздо быстрее и проще просто добавить в тему все, что вам нужно, и назвать это выполненным.

При этом, если вы работаете на WordPress на регулярной основе, вам следует серьезно подумать о следующем :

1. Создайте скелет плагина

Это должно обрабатывать все, что вам обычно нужно делать с плагином, включая активацию, деактивацию, обновление версии, создание панелей администратора и удаление.

Если вы найдете время для этого, вы найдете:

• Больше не требуется много дополнительного времени, чтобы добавить функциональность с помощью плагинов.
• Вы можете начать создавать солидный список плагинов для повторного использования в других проектах по мере необходимости, что сэкономит вам много времени в долгосрочной перспективе.
• Вы можете сделать их общедоступными, если вам нужна дополнительная видимость

Теперь вы можете правильно строить вещи и быстрее выполнять будущие проекты.

2. Создайте тематический скелет

Это должно обрабатывать все, что обычно требуется в теме:

• Основная таблица стилей, содержащая стили, которые вы обычно используете (сбрасывает и т. Д.)
• Правильный файл index.php, обрабатывающий все необходимое для любого шаблона
• Файл functions.php - вы почти не будете его использовать, но он все равно пригодится.

Как только вы это сделаете, создайте скелет дочерней темы, который использует вашу основную тему.

• Добавьте таблицу стилей, ссылаясь на вашу родительскую тему.
• Добавьте файл functions.php

Как только вы сделаете эти две вещи, создание новых сайтов для людей станет намного быстрее.

Если вы сделаете вышеупомянутое, вы можете работать над следующим:

• Потратьте свое новое свободное время на знакомство с PHP, WordPress, JavaScript, CSS и / или mySQL ... чем больше вы узнаете о них, тем быстрее вы добьетесь успеха.
• Обновляйте свой плагин, тему и скелеты дочерней темы, когда вы найдете вещи, которые вы должны улучшить. Независимо от того, насколько вы хороши, если вы продолжите учиться, вы найдете улучшения.

И, если вы выполните все вышеперечисленное , вы обнаружите, что ответ Чипа будет не только идеальным, но и оптимальным.

Простой ответ заключается в следующем ..

Зависит ли код от какой-либо функциональности, встроенной в конкретную тему? Если да, то вставь в тему.

Хотите ли вы, чтобы этот код передавался между сайтами и темами? Если да, то вставьте плагин.

Если ответ «нет» на оба вышеупомянутых вопроса, представьте себе сайт через 5 лет, когда придет время для редизайна. Будет ли функция кода, которую вы пишете, пережить следующее обновление дизайна? Если да, вставьте плагин.

Кроме того, если вы не используете дочерние темы и планируете обновить тему, я бы также предложил вам использовать плагин.