Куда вставить код: плагин или functions.php?

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

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

Хочу понять, как обрабатывать эти моменты (и, возможно, больше):

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

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

Понравилась статья? Поделиться с друзьями:
WPAsk
Ответов: 6
  1. Brad Dalton

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

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

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

      function modify_contact_methods ($ profile_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');
     
  2. Privateer

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

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

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

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

    Также:

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

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

    1. Создайте скелет темы

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

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

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

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

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

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

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

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

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

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

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

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

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

    Пользовательские типы постов

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

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

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

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

    1. Chip Bennett

      Все, что реализовано с помощью add_theme_support () , может быть реализовано только через тему. Использование add_theme_support ('automatic-feed-links') в теме фактически обеспечивает согласованное взаимодействие от темы к теме.

  4. CO4 Computing

    Ответ прост:

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

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

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

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

  5. Ralf912

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

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

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

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

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

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

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

Добавить ответ

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: