WordPress предлагает четкое разделение дизайна, контента и функциональности.
Темы очень четко управляют общим дизайном и макетом веб-сайта, в то время как плагины предлагают возможность добавлять новые функции к установке WordPress.
Поэтому вопрос о том, принадлежит ли ваша функциональность плагину или теме, должен получить довольно прямой ответ. На практике вода становится немного мутной, если учитывать гибкость WordPress, а также различные намерения различных веб-разработчиков.
Прежде чем мы рассмотрим эти нюансы, давайте сначала определим, что именно мы подразумеваем под «функциональностью».
Определение функциональности
Термин «функциональность» — это распространенное модное слово, которое в наши дни широко используется разработчиками, дизайнерами и клиентами, но что именно мы имеем в виду, когда ссылаемся на него?
По большей части, почти все участники согласились бы, чтобы это был общий термин, описывающий определенный набор функций, который был введен в систему. В WordPress почти все типы функциональности можно разбить на четыре основные категории:
- Основная функциональность WordPress
- Функциональность, которая расширяет существующие наборы функций в ядре WordPress
- Функциональность, которая представляет совершенно новые наборы функций, недоступные в ядре WordPress (включая интеграцию сторонних приложений, таких как Twitter)
- Функциональность, которая помогает определенной теме в обработке переменных с точки зрения дизайна и макета
Независимо от того, хотите ли вы добавить ленту твитов в реальном времени на боковую панель, галерею изображений jQuery на своей домашней странице или настроить свой сайт на более высокий рейтинг в поисковых системах, эти четыре категории должны охватывать практически все, что вы хотите киньте на WordPress.
Если мы примем, что все функциональные возможности в WordPress попадают в одну из этих четырех категорий, и если мы считаем, что WordPress предоставляет нам логическое место для «размещения» определенных типов операций, мы можем сделать несколько довольно линейных проекций относительно того, является ли конкретная часть функциональность принадлежит в плагине или в теме.
Основная функциональность WordPress просто включена в WordPress и никогда не должна редактироваться напрямую. Если вы это сделаете, с вами могут случиться что-то плохое … подумайте, «удаляя случайные части вашего двигателя, просто чтобы посмотреть, что произойдет».
Функциональность, которая либо расширяет существующие основные функции WordPress, либо вводит новые функции, обычно относится к плагину, поэтому его можно добавлять и удалять по мере необходимости.
Аналогичным образом, функциональность, которая помогает определенной теме, относится к этой теме, но полезно отметить, что это, как правило, сценарии, которые помогают отображать определенные фрагменты содержимого, а не добавлять или расширять функции — таким образом, цель сценария отличается. Это больше относится к логике отображения, чем к функциональности сайта — и это, пожалуй, самое важное различие, которое нужно сделать, чтобы определить для себя, где разместить пользовательские функции вашего сайта.
Отображать логику и функциональность сайта
Большая часть серой области, связанной с решением вопроса в нашем заголовке, связана с тем, что почти все функциональные возможности WordPress написаны на одном из двух языков — PHP или JavaScript. В конце концов, независимо от того, создаете ли вы собственный сценарий jQuery для добавления определенного поведения в слайд-шоу или изменяете цикл для добавления трех самых последних публикаций в категории «Избранные» на первую страницу, вы действительно работаете над функциональностью сайта, право?
Вроде.
Правда заключается в том, что, хотя вы действительно работаете с функциональными фрагментами сценариев на своем сайте, вы должны иметь возможность довольно просто поместить любой сценарий в одну из двух категорий. Сценарий либо:
- Добавляет или улучшает фактические функции вашего сайта WordPress (Функциональность сайта) , или
- Помогает вам отображать эту информацию для вашей аудитории (Display Logic) .
У всех нас есть достаточно разумное представление о том, что такое функциональность сайта, но логика отображения имеет все, что связано с тем, как мы отображаем полезные данные в контексте темы. Общие примеры логики отображения включают в себя:
- Регистрация боковых панелей и виджетов
- Регистрация новых меню WordPress
- Пользовательская условная логика, вставленная в цикл
- Размещать ссылки на миниатюры сценариев, такие как TimThumb
Включение готовых функциональных возможностей сайта через систему плагинов путем настройки логики отображения темы является наиболее распространенной формой разработки WordPress, выполняемой обычным разработчиком WordPress.
Большинство из нас тратят свое время на поиск более удобных и эффективных способов интеграции существующих инструментов, которые мы находим в Интернете, для создания решений для наших клиентов.
Часто разница между хорошей практикой кодирования и плохой практикой кодирования заключается в распознавании разницы между фактической функциональностью сайта и логикой отображения и кодировании каждого в соответствующем месте.
ABC Real Estate: тематическое исследование
Если пока все ясно, как грязь, давайте посмотрим, сможем ли мы немного очистить поток, применив его к практическому примеру. Предположим, у нас есть новый клиент, который является риэлтором ABC Real Estate, и они хотели бы, чтобы мы разработали новый сайт, построенный на WordPress, со следующими специальными запросами «функциональности»:
- Поскольку они будут проводить регулярные семинары, клиент хотел бы какую-то форму системы управления событиями
- Клиент хотел бы убедиться, что каждое из его свойств отображается постоянным, интуитивно понятным способом, который оставляет место для нескольких фотографий — число будет варьироваться в зависимости от списка домов
- Клиент хотел бы показать шесть рекомендуемых свойств, которые они выбирают на домашней странице в определенном формате.
- Клиент хотел бы, чтобы комментарии Facebook были интегрированы в его сайт, чтобы посетители могли легко делиться потенциальными домами со своими друзьями.
Каждый из этих запросов кажется более чем разумным и интуитивно понятным для веб-сайта, посвященного недвижимости, но давайте разберемся, где именно мы добавили бы каждую функциональность, указанную выше.
1) Поскольку они будут проводить регулярные семинары, клиент хотел бы какую-то форму системы управления событиями
Это довольно просто. Поскольку WordPress не содержит в своей основе систему управления событиями, нам нужно добавить ее через систему плагинов. Можем ли мы написать свою собственную и добавить ее непосредственно в саму тему? Технически, конечно — но это не имеет большого смысла, потому что уже есть так много систем управления событиями, которые мы можем попробовать в одно мгновение.
Кроме того, если бы мы были абсолютно заинтересованы в написании нашей собственной системы, было бы проще всего содержать все файлы, необходимые для системы, в их собственном месте, чтобы держать вещи в чистоте… для меня это похоже на плагин.
2) Клиент хотел бы убедиться, что каждое из его свойств отображается постоянным, интуитивно понятным способом, который оставляет место для нескольких фотографий — число будет варьироваться в зависимости от списка домов
Это немного сложнее, и немного хитрый вопрос. Поскольку мы говорим о том, как все отображается, вы можете подумать, что мы сразу находимся в сфере логики отображения. Тем не менее, в WordPress 3.0 введено понятие типов записей, которое позволяет разработчикам создавать определенный формат отображения для определенного типа сообщений.
Вы можете собрать отдельный набор данных в WordPress Admin для каждой записи в типе сообщения, а затем вывести эту запись в шаблон сообщения в теме, который позволяет выводить сообщение на экран определенным уникальным способом.
Из-за уникального способа работы типов записей, когда вы работаете с ними, вы по существу вынуждены создавать как логику отображения, так и функциональность сайта. Мы поговорим об этом чуть подробнее в этой статье.
3) Клиент хотел бы показать шесть избранных свойств, которые они выбирают на домашней странице в определенном формате.
Это логика дисплея. Мы вообще ничего нового здесь не добавляем, а просто выбираем конкретные фрагменты хранимого контента из базы данных. Это всегда делается прямо в рамках темы.
4) Клиент хотел бы, чтобы комментарии Facebook были интегрированы в его сайт, чтобы посетители могли легко делиться потенциальными домами со своими друзьями.
Интеграция сторонних приложений — в данном случае это Facebook. Кусок пирога… мы добавим один из множества плагинов комментариев Facebook, доступных для WordPress, и интегрируем его соответствующим образом. Плагин, все так.
«Отлично, я понимаю, как WordPress предпочел бы, чтобы я добавил функциональность моего сайта, но у меня есть свой собственный способ делать то, что действительно работает для меня».
На это я говорю: «Я полностью понимаю, откуда вы, но позвольте мне высказать несколько (надеюсь) убедительных замечаний, которые могут изменить ваше мнение» .
Прежде всего, если вы разрабатываете функциональность сайта самостоятельно, вам, вероятно, будет гораздо полезнее сделать это в контексте плагина, чем непосредственно в теме для переносимости.
В конце концов, даже после того, как определенное задание выполнено и сайт запущен, большой процент разработчиков сохраняет права интеллектуальной собственности на программы, которые они разрабатывают и используют на сайтах, на которых работают, и рано или поздно возникает необходимость в повторном использовании одного и того же приложения. код (или его версия) для другого проекта. Плагины делают эту функциональность сайта переносимой и простой в установке, что экономит много времени в долгосрочной перспективе.
Поскольку плагины WordPress структурированы так, чтобы хранить все свои файлы в отдельных каталогах вдали от других плагинов и основных функций WordPress, они по сути обеспечивают мгновенный порядок действий для функций, написанных на сайте.
Например, если у вас возникла проблема с мета-описанием на домашней странице, и вы знаете, что используете плагин SEO, который обрабатывает эту конкретную функцию (легко найти по ссылке на список активных плагинов в WordPress Admin), вы будете точно знать, где вам нужно начать расследование источника проблемы, даже если вы не были первоначальным разработчиком, который собрал сайт.
Таким образом, плагины могут на самом деле представлять собой свободную форму документации, предоставляя разработчикам разумные подсказки относительно того, где определенные функции могут жить даже на самых плохо документированных сайтах.
Устранение неполадок является еще одной невероятной причиной для поддержания функциональности сайта в плагинах, а не для встраивания его непосредственно в тему. Добавление новых функций на сайт WordPress может иногда вызывать конфликты и «ломать» сайт, вызывая любое количество проблем с отображением или производительностью, которые необходимо исправить.
Когда подобные вещи натыкаются на ночь, первая линия защиты, к которой стремятся большинство опытных разработчиков, — это начать изучение существующих плагинов, чтобы увидеть, где могут происходить сценарии. Использование системы плагинов WordPress для активации и деактивации плагинов предоставляет удобный способ устранения активных сценариев, запущенных на сайте, и их повторного использования, чтобы определить, какие сценарии нарушают работу.
Без возможности включать и выключать плагины, разработчик может застрять в темноте, пытаясь выяснить, какие именно скрипты конфликтуют друг с другом и приводит к ошибочному результату для конечного пользователя.
Наконец, не стоит недооценивать важность гибкости в функциональности вашего сайта. Чем больше основных функциональных возможностей сайта непосредственно встроено в тему, тем сложнее становится вносить изменения в дизайн этой темы или даже полностью заменять их. Это может звучать банально, но Интернет постоянно меняется и меняется, и, в конечном итоге, ваш сайт тоже — возможно, быстрее, чем вы думаете.
Жесткое кодирование функциональности сайта в тему может привести к длительным изменениям, изменениям и изменениям в долгосрочной перспективе (и часто в краткосрочной перспективе), поскольку вы понимаете, что то, что вы считали вчера столь важным, что вы основали всю разработку сайта на это становится полностью устаревшим на следующей неделе.
Поверьте мне, это случилось с лучшими из нас.
Нарушение правил
«Хорошо …» Я слышу, как вы говорите. «Это все хорошо, но у меня есть веская причина отклоняться…»
У каждого субъективного аргумента, подобного этому, есть ситуации, в которых есть веские аргументы, чтобы идти своим путем, и я думаю, что здесь полезно указать и несколько.
Причина № 1: Типы сообщений
В нашем тематическом исследовании мы обсудили создание настраиваемого типа записей для обработки формата отображения для списка свойств. С практической точки зрения это включает в себя объединение двух частей кода: 1) массива, инициализирующего данные для типа публикации, и 2) шаблона публикации для обработки визуального отображения в контексте темы.
Хотя второй компонент здесь явно является проблемой логики отображения, инициализация массива немного более размыта. Эта функция обычно определяется в файле functions.phpможно определить с помощью файла функций, инициализированного в системе плагинов.
Во многих отношениях это имеет смысл, так как сохраняет четкое разделение между функциональностью сайта и компонентами дизайна, но на момент написания этой статьи инициализация массива в файле functions.php Это конечно серая зона.
Причина № 2: Специализированные шаблоны страниц
Иногда становится важным создать специальную страницу на сайте WordPress, которая просто выполняет определенную функцию. Возможно, вы создаете что-то с другого сайта или добавляете какой-то пользовательский функционал, который не особенно способствует работе со структурами стандартного шаблона страницы WordPress и редактора контента.
В этом случае обычной практикой является регистрация нового шаблона страницы со стандартным синтаксисом WordPress в файле шаблона, а затем включение функциональности непосредственно в эту конкретную страницу. В этом случае функциональность вообще не переносима на другие сайты, но часто это делается в ситуации, когда в этом нет необходимости.
Причина № 3: Защита Клиента от Себя
Как бы нам ни хотелось верить, что WordPress является пуленепробиваемой системой, которую клиенты не могут сломать, мы все знаем, что она не совсем точна. Иногда есть очень веская причина что-то жестко закодировать.
Допустим, у вас есть клиент, которому нужно отредактировать боковую панель на своем веб-сайте, но он постоянно добавляет или редактирует неправильный элемент. В этом случае может быть полезно жестко закодировать простые элементы в боковой панели, чтобы вы были уверены, что самим клиентам никогда не потребуется обновлять их самостоятельно, защищая от возможности их случайного удаления.
Примерами вещей, которые могут быть жестко запрограммированы, могут быть поле для выбора адреса электронной почты или кнопки подключения к социальным сетям.
Причина № 4: Разработка специализированного продукта для конкретной отрасли
Есть много разработчиков тем, которые создают целевые темы WordPress, адаптированные к конкретным отраслям. Этим темам не хватает определенной гибкости, но в результате они не нуждаются в дополнительной гибкости для целевого рынка. Примеры этого включают конкретные темы недвижимости, темы обзора продукта или темы агрегации вопросов и ответов.
Причина № 5: время и бюджетные соображения
Иногда быстрее кодировать что-либо непосредственно в тему, чем сделать ее модульной и использовать плагин, как это определено в качестве передового опыта. Когда время является фактором или ваш клиент имеет ограниченный бюджет, которого вы должны придерживаться, можно привести аргумент, что существует законная причина для того, чтобы вырезать углы и кодировать функциональность сайта непосредственно в тему.
Важно отметить, что это, безусловно, не лучшая практика, но это причина делать то, что вам нужно, чтобы выполнить работу.
Какой итог?
Вопрос о том, где разместить функциональность вашего сайта, похож на все остальное … существует простой ответ, основанный на довольно ограниченных правилах, но вы всегда можете найти оправдание, чтобы пойти своим путем, если это необходимо.
Рекомендуется определить, какие функциональные возможности лучше всего описать как логику отображения, а какие функциональные возможности лучше всего описать как общую функциональность сайта , при этом логика отображения добавляется непосредственно к темам, а функциональность сайта включается в систему плагинов.
Это отражается на том, как вы работаете?