it-swarm.com.ru

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

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

Есть естьмногиеслучаи и многие дебаты ) по этой теме, главным образом потому, что существуют некоторые неправильные представления о внутренней работе WordPress. Я прошу ответ на основе фактов, не на мнениях.

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

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

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

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

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

86
fuxia

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

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

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

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

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

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

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

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

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

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

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

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

71
Chip Bennett

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

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

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

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

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

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

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

49
Ralf912

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

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

Отсюда Темы 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
5
Brad Dalton

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

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

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

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


  1. Создать каркас плагина

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

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

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

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


  1. Создать каркас темы

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

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

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

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

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


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

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

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

4
Privateer

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

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

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

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

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

2
CO4 Computing