Как развести оформление нескольких сайтов на одном ядре без копирования каждой правки

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

Сначала определить границу общего и отдельного

Фраза «тот же сайт в другом цвете» скрывает несколько решений. Могут различаться только акцентные цвета, а могут также отличаться структура меню, контактные данные, способы доставки и контент. Если сразу скопировать каталог шаблона, эти различия окажутся перемешаны с одинаковой разметкой. Следующая правка корзины потребует поиска двух похожих мест и проверки, что они ещё совпадают.

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

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

Выбирать настройки по текущему сайту

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

Учебный пример: существуют витрины А и Б. Обе используют одну карточку, но А получает зелёный акцент, а Б синий. Компоненту не нужно знать названия компаний или домены. Он читает смысловые настройки «основной акцент», «фон секции», «цвет текста на кнопке». Привязка этих значений к витрине находится в одном конфигурационном слое, доступном для проверки.

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

Хранить цвета по смыслу, а не по месту использования

Параметр «цвет кнопки в правом верхнем углу» быстро становится неудобным. После перестройки шапки местоположение меняется, а назначение кнопки остаётся. Смысловые названия вроде «основное действие», «ошибка», «граница поля» переживают такие изменения. Разработчик связывает их с компонентами, редактор видит ограниченный набор параметров и не правит таблицу стилей целиком.

Пользовательские свойства CSS подходят для передачи значений внутри области темы. Они подчиняются каскаду и обычно наследуются от родителя, что описано в документации MDN. Однако переменная сама по себе не гарантирует изоляцию: если значение объявлено слишком высоко или правило другого сайта оказалось специфичнее, оформление всё равно пересечётся. Проверять нужно вычисленное значение в конкретном элементе.

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

Ограничить область действия стилей

У каждой темы должна быть понятная область. Это может быть атрибут корневого контейнера, отдельный слой стилей или явно подключённый набор переменных. Компоненты внутри области получают её значения, а правила соседнего сайта не должны случайно менять их. Глобальные селекторы наподобие «все ссылки во всех блоках» особенно опасны, когда две темы загружаются из одного пакета.

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

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

Общий компонент менять один раз

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

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

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

Кэш должен учитывать различия сайтов

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

В учебном тесте сначала прогрейте страницу А, затем откройте аналогичную страницу Б в отдельной сессии. Повторите порядок в обратную сторону. Сравните HTML, ссылки на ресурсы и значения настроек, а не только цвет кнопки. Если данные зависят ещё от языка или режима посетителя, эти различия должны быть учтены соответствующим механизмом кэширования, а персональные данные нельзя помещать в общий ответ.

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

Переносить существующий сайт постепенно

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

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

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

Проверять состояния, а не две главные страницы

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

Полезна матрица «компонент × сайт × состояние × ширина». Она не обязана превращаться в сотни скриншотов. Сначала проверяют общие критические компоненты и места, где были исключения. При изменении общей логики повторяют действия, а при замене палитры дополнительно проверяют читаемость текста и границы элементов. Успешная проверка старой версии не подтверждает новое сочетание цветов.

Передать редактору управляемый набор

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

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

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

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

Связанный разбор: Как перенести корпоративный сайт на 1С-Битрикс: контент, SEO-адреса, формы и доступы.

Документация и источники

• MDN: CSS custom properties: Область действия и наследование пользовательских CSS-свойств