В течение последнего года я работал над крупномасштабным проектом с несколькими веб-сайтами, основанными на одной и той же кодовой базе. Все эти сайты требуют одинаковых основных функций, но иногда отличались дополнительными функциями или уникальными стилями. Когда дело дошло до стиля, главной проблемой, которую мы обнаружили, была необходимость того, чтобы у одних сайтов была совершенно другая тема. Из-за этого мы решили использовать Sass для создания CSS для сайтов. В этой статье я хочу рассказать вам, как мы работали над редактированием тем для разных сайтов.
Чтобы дать краткий контекст, проект использует WordPress со структурой родительских / дочерних тем. Существует основная родительская тема WordPress со всеми основными функциями, которые будет использовать каждый сайт, а также дочерние темы для каждого из различных рыночных сайтов.
Настройка вашего Sass
Для начала я хочу кратко взглянуть на то, как мы обычно используем файлы конфигурации в нашем Sass. Ниже приведена базовая структура папок для одного из наших проектов:
assets/
|- scss/
|- base/
|- components/
|- pages/
|- settings/
|- _colors.scss
|- _layout.scss
|- _fonts.scss
|- tools/
|- vendor/
|- main.scssЯ расширил папку настроек выше, в которой мы сохраняем различные отдельные партиалы для каждой группы настроек. Цель состоит в том, чтобы сохранить эти файлы конфигурации как можно меньшими и легкими для навигации. Что-то, о чем я думал с тех пор, как прочитал статью Стюарта Робсона о переосмыслении переменных Sass .
Например, если бы мы заглянули внутрь частичных цветов, мы бы увидели что-то вроде этого:
// COLORS
// ---------------------------
$clr-lightblue:#4BCEFA;
$clr-pink:#F96EC4;
$clr-orange:#FFB400;
$clr-green:#8DD400;
$clr-purple:#009edc;
Частицы настроек сначала включаются в наш основной файл манифеста, что позволяет нам использовать эти переменные в оставшихся частях. Это означает, что все объявления цветов находятся в одном месте и их легко найти.
Структура
Использование описанного выше способа настройки хорошо в контексте одной таблицы стилей с одной темой. В нашей ситуации у нас была одна базовая тема WordPress и несколько дочерних тем, для которых требовались бы таблицы стилей — здесь есть проблема масштаба, о которой я расскажу чуть позже.
Чтобы создать таблицы стилей для каждой из дочерних тем, мы настроили нашу структуру Sass в соответствии со структурой тем WordPress.
scss/
|- australia/
|- china/
|- core/
|- uk
themes/
|- australia/
|- china/
|- core/
|- uk
У каждого рынка в каталоге scss
Примечание : мы выбрали эту структуру, основываясь на использовании Compass и Grunt для создания нашего Sass, и это, казалось, был самый эффективный метод в то время.
Настройка нескольких тем
До сих пор я проходил настройку конфигурации и немного обсуждал структуру, которая у нас была. Теперь давайте перейдем к тому, как мы на самом деле использовали файлы конфигурации для изменения различных тем.
Для начала у нас была базовая или стандартная конфигурация благодаря основной / родительской теме. Чтобы создать каждую отдельную таблицу стилей темы, мы смогли включить нашу основную часть в каждый из манифестов style.scss. Затем мы могли бы добавить специфичные для сайта партиалы для добавления / перезаписи любых стилей, необходимых для этого рынка.
// Import the core partial containing all base site styles
@import “../core/core”;
// Import site-specific styles
@import “partials/campaigns/competition”;
@import “partials/campaigns/promotion-spring”;
Перезапись конфигураций
Пока что метод, который мы используем для создания наших нескольких таблиц стилей, прекрасно работает для перезаписи стилей. Но конфигурации перезаписи немного отличаются. При импорте основной части в каждый из сайтов рынка мы получаем все стили, которые уже использовали наши настроенные переменные. После того, как он импортирован, нет возможности переписать то, что уже настроено. В этом случае нам нужно было добавить пользовательские конфигурации перед импортом основных стилей. Для этого у нас было два варианта:
- Создайте набор партиалов конфигурации для каждого рынка или
- Создайте набор конфигураций по умолчанию и перезапишите их, где это необходимо для каждого рынка.
Либо возможно, и вполне достижимо. В обоих случаях отдельные рыночные сайты style.scss будут выглядеть примерно так:
// Import configuration partials
@import “settings/colors”;
@import “settings/fonts”;
// Import the core partial containing all base site styles
@import “../core/core”;
// Import site-specific styles
…
При создании набора совершенно разных тем, где в большинстве случаев все настройки могут измениться, первый вариант может оказаться наиболее подходящим. В нашем случае, однако, у нас было много сайтов, которые почти всегда имели бы одинаковые цветовые схемы, и только нескольким потребовались совершенно другие настройки.
Использование !default
Чтобы мы могли создать нашу конфигурацию настроек по умолчанию, нам нужно было использовать флаг !default . Флаг !default
[…] Если переменная уже была назначена, она не будет переназначена, но если у нее еще нет значения, ей будет присвоено значение.
Это означает, что необходимо установить флаг для значений, которые вы хотите использовать, если ничего уже не было настроено. Возвращаясь к нашему файлу конфигурации цвета, теперь он выглядит примерно так:
// COLORS
// ---------------------------
$clr-lightblue:#4BCEFA !default;
$clr-pink:#F96EC4 !default;
$clr-orange:#FFB400 !default;
$clr-green:#8DD400 !default;
$clr-purple:#009edc !default;
При использовании флага !default
Именование переменных
Одна вещь, которую мы осознали, когда начали использовать разные конфигурации для наших тем, заключалась в том, что это означало, что имена наших переменных были немного бесполезными, если не сказать больше. Намерение было достаточно честным, но когда мы начали делать такие вещи в наших конфигурациях:
$clr-lightblue:#f02233; // Red for China
Мы знали, что что-то должно было измениться, чтобы улучшить ситуацию.
Схема именования, которую мы определили, была весьма специфичной для наших требований, поскольку у нас был набор разделов, которые требовали отдельных цветов. Хотя я определенно рекомендую придерживаться соглашения, которое будет наиболее подходящим для проекта, над которым вы работаете. Хотя соглашение об именовании в стиле «первичный», «вторичный», «третичный» может работать для некоторых, оно может работать не для всех.
В нашем случае переменные цвета имеют гораздо более согласованные имена, относящиеся к проекту. Это, безусловно, позволило нам намного проще определить их использование.
$clr-brand:#4BCEFA !default; // lightblue
$clr-kids-activities:#F96EC4 !default; // pink
$clr-parenting:#FFB400 !default; // orange
$clr-sustainability:#8DD400 !default; // green
$clr-mmr:#009edc !default; // blue
Потенциальная ловушка: масштабирование
Есть одна область, где этот метод немного отклеился: масштабирование. Когда дело дошло до масштабирования этого решения для настройки каждой из 31 тем, которые у нас есть в проекте (скоро будет 33), время для компиляции стало астрономическим. Я никогда не думал, что смогу относиться к компиляции комикса XKCD в качестве внешнего разработчика.
Причина, по которой это решение может плохо масштабироваться, заключается в том, что для каждой создаваемой темы нам приходится компилировать все Sass 31 раз. Соедините это с тем фактом, что мы используем Sass и Compass в качестве наших компиляторов (вместо гораздо более быстрого LibSass), вы просматриваете 3-5 секунд на файл в 31 теме. Ожидание где-то между 2-3 минутами каждый раз, когда вы хотите внести изменения, далеко не продуктивно.
Есть несколько маршрутов, чтобы мы могли решить эту проблему. Первый состоит в том, чтобы скомпилировать одну базовую таблицу стилей со всеми стилями по умолчанию, а затем несколько гораздо меньших, чтобы добавить файлы, специфичные для сайта. Это уменьшило бы количество, которое мы должны скомпилировать для каждого из сайтов, и в то же время позволило бы перезаписывать полные конфигурации при необходимости. Тем не менее, поскольку существует всего несколько сайтов, которые имеют тяжелую настройку тем, мы сможем ограничить объем дополнительной работы.
Второй вариант — отделить все определения цвета от основных таблиц стилей и использовать их в отдельных частях. Затем мы можем создать специальный файл темы, который может быть перезаписан, как мы уже делаем. Нам все еще нужно было бы создать отдельные частичные файлы для специфических для сайта модификаций и функций. Но они все еще могут быть созданы отдельно от основной таблицы стилей.
Обе эти опции оставят нам несколько выходных файлов, которые нам нужно будет затем объединить в один файл для вывода в тему. Это должно быть просто для нас, учитывая, что мы используем Grunt, и есть задачи, которые могут позаботиться о сцеплении. Нам просто нужно провести некоторое тестирование того, насколько эффективны эти решения, как со временем компиляции, так и с относительным размером выходного CSS.
Вывод
Когда дело доходит до тем, Sass может быть чрезвычайно сильным союзником. Возможность использовать переменные для хранения настроек вашей темы и иметь возможность их перезаписи с помощью флага !default Тематика также облегчается, когда вы устанавливаете правильные условия. Создайте понятное, ориентированное на проект соглашение об именах, избегая имен, которые могут быть неправильно поняты при изменении значения. И не забывайте знать о потенциальных проблемах, таких как масштабирование, поскольку вы можете видеть, что это может значительно повлиять на ваш рабочий процесс. Счастливой темы!