Один шаблон шапки для нескольких сайтов: как скрывать партнёрские пункты меню настройкой

Когда настройка полезнее копии шаблона

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

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

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

Семантика признака

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

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

Дерево меню и фильтрация

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

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

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

Скрытая ссылка и право доступа

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

Обратная ситуация: страница может оставаться разрешённой, но не участвовать в основной навигации. Это допустимое редакционное решение. Тогда прямой вход должен работать по выбранной модели, а отсутствие ссылки не является ошибкой. Важно не смешивать эти случаи. В требованиях пишут либо «не показывать пункт», либо «ограничить доступ», либо оба действия с отдельными критериями.

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

Где хранить настройку

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

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

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

Публичный кэш

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

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

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

Мобильное меню

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

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

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

Редакторский сценарий

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

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

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

Проверка конечного поведения

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

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

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

Одно правило в двух представлениях шапки

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

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

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

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

Смежная тема разобрана в материале Большой интернет-магазин: каталог, поиск и ассортимент.

Вопросы по теме

Как различать меню основного и партнёрского сайта без отдельных копий вёрстки?

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

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

• MDN: проверка данных формы: Клиентская проверка не заменяет серверную; прикладной сценарий спроектирован в статье.