Наилучшая практика структуры файловой структуры темы

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

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

Ниже приведены очевидные папки, которые я уважаю:

активы

/ CSS

/ JS

/изображений

страницы-шаблоны

файлы шаблонов страниц


В каких папках считалось бы лучшей практикой добавить, например:

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

Solutions Collecting From Web of "Наилучшая практика структуры файловой структуры темы"

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

Если вы создаете тему, которая будет использоваться другими, вы должны иметь в виду, что темы должны быть повторно использованы в нескольких случаях использования. WP это делается с помощью детских тем. Все файлы в теме будут загружены из дочерней темы, если они там существуют , за исключением functions.php и style.css . Поэтому вы должны организовать свою файловую структуру таким образом, чтобы пользователи, использующие вашу тему, могли легко понять, какие файлы им нужно скопировать и изменить в дочерней теме, чтобы использовать вашу тему так, как вы считали невозможным.

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

Типичная схема темы:

 /assets /js /css /img /includes => put your core functionality here, especially if you go OOP /lang => your i18n files go here /modules => if you create any 

Это то, что я буду использовать в качестве стартера. Когда я пишу modules я думаю о расширенных функциях, которые будут использоваться только в некоторых конкретных случаях и полностью отключены в других случаях. Если вам нравятся вещи чище, вы можете перемещать /modules в /includes .

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

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

WordPress Core не требует какой-либо конкретной структуры папок, за исключением того, что ваша тема находится в wp-content/themes/{your_theme_name} . Вы можете поместить все ваши файлы в эту папку, если хотите, и для небольшой темы, которую вы, вероятно, должны.

По мере того, как ваша тема становится больше, ломать вещи в папки становится необходимой для организации. Папка стилей, одна для Javascript и одна для изображений тем довольно разумна, но имена не имеют значения, если вы не используете смешные имена. Любой программист, которого стоит назвать, который сможет разобраться в том, что js , javascript и scripts , вероятно, такие же, как и css stylesheets или styles . Не беспокойтесь об этом слишком много.

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

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

Это приводит меня к … get_template_part() и некоторые связанные функции способны обрабатывать вложенные папки, если вы кормите правильные аргументы, но, на мой взгляд, это становится неудобно со слишком большим количеством вложенности, поэтому я бы избегал больше, чем слой или два для файлы, загружаемые этими функциями.

Опять же, все это необязательно. Ключевым соображением является эффективность организации. Имеет ли смысл структура? Будет ли кто-то смотреть на это позже и задаться вопросом, что вы сделали $ # %%? Будете ли вы оглядываться назад через год и удивляться?