Настройка свойств → правка view → правка блока → стили/скриптыlink

В SF4 удобно вести изменения “сверху вниз”: сначала понять, какие настройки управляют поведением, затем уточнить какое представление (view) отвечает за область, потом — какой блок реально выводит нужный фрагмент, и только после этого — подключать стили/скрипты. Такой порядок помогает не “лечить симптомы” (правкой шаблонов), а менять причину.

Обычно цикл выглядит так.

Настройка свойств (site/section/page) Сначала определите, на каком уровне должно действовать изменение:
- для всего сайта — меняете {site_dir}/simai.data/.site.property.php;
- для ветки — меняете section в .property.php раздела;
- для конкретной страницы — меняете page['имя_страницы.php'] в .property.php.
Если изменение связано с доступностью параметра в интерфейсе, проверяете схему:
- site: {site_dir}/simai.data/config/.site.config.php
- structure: {site_dir}/simai.data/config/.structure.config.php и при необходимости локальный {section_dir}/.structure.config.php (локальный переопределяет базовый).
Правка view (если меняется структура области) Если нужно перестроить область (добавить/убрать строки, поменять расположение блоков, поменять набор area-шаблонов), правится соответствующее представление в:
- {site_dir}/simai.data/grid/view/<area>/<view_code>/template.php
Здесь вы управляете “композицией”: какие area-шаблоны стоят в каких строках/колонках и с какими параметрами.
Правка блока (если меняется логика/разметка конкретного фрагмента) Если структура области верная, но не устраивает внешний вид или поведение конкретного элемента, меняется блок в:
- {site_dir}/simai.data/grid/block/<section>/<block_code>/template.php
Важно: блоки лучше делать максимально переиспользуемыми, а различия задавать через параметры, которые приходят из view (ключи __...__...).
Стили/скрипты (если нужны проектные правки оформления/интерактивности) После того как вы определили правильную структуру и правильный блок, подключаете:
- CSS в {site_dir}/simai.data/template/style/...
- JS в {site_dir}/simai.data/template/js/...
Если вы используете пакеты — фиксируете подключение в:
- {site_dir}/simai.data/config/.asset.config.php
И помните правило проекта: конфигурация ассетов сайта замещает, а не дополняет системную — это влияет на то, где и как вы должны добавлять новые файлы, чтобы не получить “двойное подключение”.

Проверка результата и очистка кэша при необходимостиlink

Проверка после изменения должна отвечать на два вопроса: “изменение применилось?” и “оно применилось правильно, без побочных эффектов?”.

Минимальный практический чек:

Проверить уровень применения настроек
- если правили .site.property.php — применяется ли это ко всем страницам?
- если правили .property.php — не перекрывается ли настройка выше/ниже по дереву (page/section/site)?
Проверить, что используется правильный view
- значение grid_view_* соответствует существующей папке в simai.data/grid/view/...;
- для нужной области реально подхватился ожидаемый <view_code>.
Проверить блок
- в view стоит правильный ...AREA_*_TEMPLATE;
- в simai.data/grid/block/... существует реализация блока;
- параметры, которые вы передали из view, реально читаются блоком (особенно важно для префиксов вроде CUSTOM.BUTTON__...).
Проверить ассеты
- CSS/JS загрузились один раз (без дублей);
- порядок подключения не сломал зависимости (особенно если есть библиотеки);
- если включён режим minified в Bitrix, убедиться, что сайт не “переключился” на .min.*, которых нет.
Кэш Если после правок изменения не видны, почти всегда причина — кэш. В SF4 это проявляется в двух местах:
- кэш Bitrix-компонентов (если блок/компонент кешируется);
- кэш подключения/сборки ассетов (если конфигурация или список пакетов менялся).
Поэтому практическое правило простое: после правок в simai.data и конфигов, если результат не совпадает с ожидаемым — чистите кэш и проверяйте снова.