Существует несколько типов разработчиков WordPress. Некоторые из них создают мелкие одноразовые проекты, другие работают над более глобальными вещами. Все используют разные инструменты и методы в зависимости от того, что требует от них клиент. Очень многие при разработке тем на заказ используют стартовые темы, и мы должны отметить, что в некоторых случаях абсолютно не зря.
Смотрите также:
Что такое стартовая тема?
Стартовая тема – это тема, в которой вместо того, чтобы создать дочернюю тему, вы просто меняете название и выпускаете свою собственную тему. Она не будет родительской темой. Это просто основа с несколькими базовыми файлами для вашей новой пользовательской темы. Если вы не используете стартовую тему, каждый раз при создании темы вам придется писать один и тот же базовый код для style.css, header.php, index.php и footer.php — обязательных файлов для любой темы.
Так что, если вы еще не использовали стартовую тему, стоит задуматься об этом в будущем.
Зачем использовать стартовую тему?
Мы не будем пытаться вас убедить, что использовать стартовые темы — это хорошо или плохо. Но мы можем смело сказать, что очень удобно начинать работу над новой темой уже с готовыми этими 4 файлами. К тому же существует множество действительно классных стартовых тем, например, такие как roots.io (sage) или _s (undercores) от Automattic.
Тем не менее, у нас возникла проблема при работе с этими темами. Они оказались слишком «раздуты». Когда мы впервые взяли в руки проект roots.io, и познакомились с их DRY (Do not Repeat Yourself — не повторяйтесь) философией, мы были очень заинтригованы. Там было все сделано хорошо, качественно, но честно говоря, разобраться во всем было достаточно сложно. И это явно не было похоже на "WP-метод".
Примечание: Мы никогда не считали, что "WP метод" – это единственно верный подход на все случаи жизни, однако при создании темы оказалось, что метод DRY значительно замедлил процесс разработки.
Просмотрите весь код
Если вы делаете тему на заказ, то скорее всего, у нее будет уникальный дизайн, а значит и уникальный макет. Поэтому когда мы начали работать с темой _s, оказалось, что необходимо потратить кучу времени на рефакторинг DOM (HTML), чтобы он соответствовал нашему макету. После чего нам пришлось самостоятельно создавать каждый шаблон на основе одного макета (index.php).
Причем здесь не идет речь только об одном встроенном шаблоне. В подобных стартовых темах очень много необходимой базовой функциональности. Поэтому файлы становятся раздутыми или они перегружены функциями настолько, что вы не всегда будете понимать, нужно ли вам это все.
Когда удобно работать со стартовыми темами
В некоторых случаях можно очень эффективно использовать раздутые стартовые темы. Например, если вы убедились, что все новые темы соответствуют DOM, который уже встроен в тему. Даже если там и не будет макета, это можно легко исправить, сделав всего несколько манипуляций над стилем. Поэтому, если вы можете постоянно использовать один и тот же DOM или, если у вас есть подходящая таблица стилей, то, возможно, это хорошее решение для вас.
Ну и поскольку у этих тем уже есть много шаблонов, вы сможете с их помощью быстро и легко создавать новые мощные темы. Таким образом, следует признать, что да, определенно бывают случаи, когда при возможных временных ограничениях раздутые стартовые темы могут очень сильно помочь.
Когда не рекомендуется использовать раздутые стартовые темы
Очень часто бывает так, что темы, которые были созданы для экономии времени, требуют от вас намного больше временных затрат, да и подогнать настройки DOM не так уж и легко.
Например, если при создании новой темы вы любите создавать все с нуля, то и DOM должен быть пустым. Вас может раздражать, что необходимо редактировать все эти файлы шаблонов, уже созданные в index.php (или, возможно, page.php), чтобы они соответствовали DOM. Говоря о методах DRY, я не против сделать копи-паст из одного шаблона в другой, но предпочтительнее создавать их самому.
Другая проблема заключается в том, что большинство тем я пытаюсь монетизировать, но иногда есть те, за которые клиент мне не платит. Например, страница архива. Если существует СРТ, то нет никакой необходимости создавать и страницу архива, но WordPress создаст ее в любом случае со стартовой темой, которая стилизована, и у которой представлен готовый DOM, но которая не совсем правильно соответствует остальной части моей новой пользовательской темы. Так что теперь у меня есть файлы, которые на самом деле негативно влияют на весь проект. Вместо того чтобы возвратиться назад к index.php, WordPress показывает archive.php, который может выглядеть «поломанным» или просто незаконченным.
Также, мы считаем, что большинство из этих стартовых тем не подходят для работы с такими технологиями, как gulp, npm и т.д. Нам не нравится, когда большинство тем включают в себя скомпилированные скрипты и стили, поскольку было бы неплохо это сделать самим.
Следующий уровень
Мы поняли, что чем выше становится профессиональный уровень разработчика, тем меньше он вкладывает в стартовые темы. У большинства разработчиков-сеньоров есть свои собственные стартовые темы, которые выглядят так же, как и наши. В основном это package.json, gulp.js, style.css (с определенными основными классами WordPress), header.php, footer.php и index.php. Чтобы начать новую тему, переименуйте тему в style.css, измените то, что вы хотите в header.php (author и т.д.), сделайте npn установку и запустите gulp, чтобы все поставить на свои места.
Возможно, это просто совпадение, а возможно действительно, чем выше становится уровень разработчика, тем сильнее он минимизирует начинку своей стартовой темы.
Заключение
Мы ни в коем случае не говорим каждый раз начинать с нуля, когда вы садитесь работать над новой темой. Но перед началом работы проанализируйте: действительно ли вы сэкономите время, используя стартовую тему. Если да, то уверено приступайте к созданию своего нового шедевра с помощью этого инструмента. Удачи!
Источник: roysivan.com
Комментарии к записи: 6
Похоже, автор не в курсе, что такое DOM
Да похоже что он вообще инопланетянин…. )))) Почему вообще такие люди считают, что могут втирать (и навязывать) разработчикам что то свое.
Каждый должен сам «дойти» до определенных выводов и методов решения любых задач, а подобные «типа-советы», сбивают столку не только начинающих, но и многих опытных разработчиков, тем самым ставя под сомнения свои силы и методы работы.
Последний год во всех своих проектах использую sage. Пришлось посидеть, поразбираться, но мой скилл в разработке очень сильно вырос благодаря этой теме. Пришлось освоить gulp, bower, assets, sass, browser sync и некоторые другие вещи, которые лежат в основе sage. И подход DRY в этой теме действительно экономит время. Единственная вещь, которую я еще не понял в sage — это необходимость использования composer для менеджмента плагинов.
По composer. С ним удобнее устанавливать все необходимые компоненты. Ничего не забудешь не пропустишь, и версии у компонентов будут нужные.
А вот эти комменты стандартные или плагин?
https://hostenko.com/wpcafe/plugins/decomments/