home chevron_right
Правила безопасной кастомизации

Не править файлы ядра /simai и системного шаблона /bitrix/templates/simai.framework; копировать/расширять в {site_dir}/simai.datalink

В SF4 безопасная кастомизация строится на разделении слоёв:

  • ядро фреймворка (/simai) — обновляемая системная часть;
  • системный шаблон Bitrix (/bitrix/templates/simai.framework или /local/templates/simai.framework) — точка входа, которая делегирует сборку страницы проектному слою;
  • проектный слой ({site_dir}/simai.data) — всё, что относится к конкретному сайту и должно переживать обновления.

В вашем проекте системный header.php / footer.php именно так и сделаны: они подключают модуль и затем включают {site_dir}/simai.data/template/template.php. Поэтому править “входной” шаблон нет смысла: любые изменения должны жить в simai.data, иначе обновления превратятся в ручной мердж.

Хранить все правки в simai.data/template и simai.data/config; следить за чистыми путями и корректной структуройlink

Два главных каталога для кастомизаций:

  • {site_dir}/simai.data/template/ — каркас страницы, области (area), панели, проектные точки подключения meta/style/js и т.д.
  • {site_dir}/simai.data/config/ — проектные конфиги (включая ассеты и схемы настроек), которые должны оставаться частью проекта.

Практические правила, которые экономят время на сопровождении:

  • используйте чистые пути: латиница, цифры, дефисы/подчёркивания, без пробелов и кириллицы;
  • сохраняйте устойчивую структуру каталогов (как у уже работающих частей проекта), а не “как удобно сейчас”;
  • не переносите проектные артефакты в альтернативные места вроде /upload/simai: если это не simai.data, вы теряете единый стандарт, переносимость и предсказуемость.

Подключать ассеты через .asset.config.php в simai.data/config, а не напрямую менять базовые файлыlink

Если проекту нужно менять набор/порядок подключения CSS/JS, правильный подход — делать это в проектном слое:

  • правила/описание подключения — {site_dir}/simai.data/config/.asset.config.php
  • “точки подключения” в шаблоне — через {site_dir}/simai.data/template/style.php и {site_dir}/simai.data/template/js.php

Так вы не вмешиваетесь в системные ассеты ядра и не ломаете обновления. А ещё проще отлаживать: в любой момент понятно, что именно подключает проект и где это описано.

Важно: точный формат массива в .asset.config.php зависит от принятого в проекте соглашения (ключи/пакеты/зависимости). Если нужно — пришли ваш .asset.config.php, и я зафиксирую в документации каноничный формат “как у нас принято”.

Проверять наличие ссылок/путей перед изменениями; использовать коды, не IDlink

В SF4 почти всё “стыкуется” по кодам, а не по числовым идентификаторам:

  • области подключаются по коду ("sidebar/right", "service/top") и соответствуют пути вида {site_dir}/simai.data/template/area/sidebar/right/template.php
  • настройки и свойства хранятся по кодам ключей (например, layout_type, sidebar_show, show_title), и переопределение работает только если код совпадает
  • grid/view/block и прочие вариативные части также выбираются по кодам/папкам, а не по ID

Поэтому перед правками полезная дисциплина такая:

  • сначала убедиться, что путь/код уже используется в проекте или соответствует принятому паттерну;
  • затем добавить файл по ожидаемому пути;
  • затем добавить/проверить точку подключения (в template.php, в настройке, в конфиге).

Мини-пример: добавление новой области “как принято”link

  1. Создать файл области:

{site_dir}/simai.data/template/area/promo/top/template.php

  1. Подключить в {site_dir}/simai.data/template/template.php:
<?IncludeArea::includeTemplateArea("promo/top");?>

Если область не вывелась — в 90% случаев проблема в одном из трёх мест: неверный код области, неверный путь/имя файла template.php, или вызов подключения добавлен не в ту часть layout’а.