Написание поддерживаемых тем WordPress: соглашения об именах

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

В частности, мы коснулись того, как организовать:

1. Файлы JavaScript и CSS
2. Шаблоны и части шаблона
3. Переводы
4. Вспомогательные файлы и служебные функции
5. Сторонние библиотеки

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

Но это еще не все, что нужно для написания поддерживаемых тем WordPress. Другой — следовать соглашениям, установленным стандартами кодирования WordPress; Тем не менее, эта статья не будет смотреть на стандарты. Кодекс отлично справляется с этой задачей, и мы рассмотрели их в другой серии .

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

Увеличение ремонтопригодности

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

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

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

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

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

Шаблоны

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

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

Шаблоны WordPress объединяются, как кусочки головоломки, для создания веб-страниц на вашем сайте WordPress. Некоторые шаблоны (например, файлы шаблонов верхнего и нижнего колонтитула) используются на всех веб-страницах, а другие — только при определенных условиях.

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

Шаблоны — это транспортные средства, с помощью которых информация предоставляется пользователю. Они состоят из разметки и PHP, стилизованы с помощью CSS и могут иметь некоторые эффекты, применяемые с помощью JavaScript.

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

Обратите внимание, что в связанной статье Кодекса WordPress будет иметь шаблоны по умолчанию index.php , header.php и footer.php . Правда в том, что вы действительно можете без проблем создать целую тему WordPress, используя только index.php .

Звучит привлекательно, правда? Я имею в виду, кому нужно создавать так много разных файлов, когда вы можете создать красивую, маленькую, скудную тему, которая делает все, что вам нужно.

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

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

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

Видишь, о чем я?

Но затем, создание отдельных файлов только для того, чтобы уменьшить эту сложность, может быть чудовищем само по себе. Например, предположим, что у вас есть single.php для отображения одного поста, и у вас есть page.php для отображения страницы, и оба шаблона имеют точно такую ​​же информацию, за исключением того, что single.php имеет метаданные поста, а page.php — нет. ,

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

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

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

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

Функции именования

Когда дело доходит до работы с функциями и соглашениями о присвоении имен, обычно следует соблюдать два практических правила:

1. однозначно назвать ваши функции,
2. правильно назвать их, чтобы указать, что будет return данные и что будет отображать данные

Но если вы только начинаете заниматься разработкой тем или хотите улучшить свои навыки, как это выглядит?

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

Например, предположим, что вы собираетесь написать свою собственную функцию, которая будет фильтровать контент перед его отображением на странице. Правильный способ сделать это, очевидно, использовать функцию add_filter ; однако, вы бы назвали свою функцию the_content ?

Нет, конечно нет. Причина в том, что WordPress уже определяет the_content . Если вы переименуете функцию с этим именем, вы получите ошибки. С этой целью всегда лучше поставить перед вашими функциями уникальный ключ, такой как название вашей темы или что-то подобное.

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

Допустим, вы хотите завершить каждый пост своим именем и дескриптором Twitter. Для этого вы можете определить это в вашем файле functions.php :

Это относительно просто, не так ли? Суть в том, что я пытаюсь использовать следующий формат при создании своих собственных theme_name-name_of_hook функций: theme_name-name_of_hook .

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

Возврат и отображение данных

Как упоминалось ранее, WordPress имеет другое соглашение, которое он использует и имеет отношение к тому, будет ли информация возвращаться из вызываемой функции или отражаться от вызываемой функции.

К счастью, это особое правило очень легко запомнить:

• Функции, которые возвращают данные, имеют префикс get_
• Функции, которые отражают данные, не имеют префикса get_

Вы можете найти некоторые аномалии, но это общая суть того, как WordPress API показывает, как он будет возвращать вам данные после вызова функции.

В соответствии с нашим предыдущим примером, давайте захотим, чтобы вы the_content() данные при вызове функции, тогда вы просто the_content() бы the_content() ; однако, если вы хотите извлечь контент из поста, скажем, из пользовательского цикла, вы должны вызвать get_the_content() и сохранить его в своей собственной переменной.

Возможно, что-то вроде этого: $content_for_later = get_the_content() . Теперь вы прочитали данные для контента, который в данный момент связан с активным постом в Цикле, и сохранили его в переменной, которую сможете использовать позже.

Но знание того, как WordPress называет свои функции для вас, — это только половина дела. В конце концов, вы планируете создать тему или плагин и хотите убедиться, что вы придерживаетесь «способа WordPress», верно?

Пример: в приведенном выше примере, где мы фильтровали содержимое, мы acme_the_content префикс функции так, чтобы она называлась acme_the_content , что указывает на то, что тема Acme будет возвращать содержимое, откуда бы оно ни acme_the_content в рамках темы.

Что должно было случиться, если бы мы acme_get_the_content() функцию acme_get_the_content() ?

Ну, технически говоря, функция будет по-прежнему отображать данные, где бы они ни вызывались; однако, это было бы несовместимо с WordPress API, поскольку разработчик ожидал, что данные будут ему возвращены, чтобы они могли сохранить их в переменной или передать другой функции.

Существует несоответствие между тем, что пользователь ожидает, и тем, что происходит на самом деле.

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

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

А как насчет полезных инструментов?

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

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

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