/bitrix/modules/simai.framework — код модуля: ядро /simai, компоненты (install/bitrix/components/simai), мастера (wizard/action), классы и конфигиlink

simai.framework устанавливается как модуль Bitrix и приносит “платформенную” часть SF4: то, что обновляется вместе с фреймворком и не должно правиться в проектах. Логически внутри модуля есть три слоя:

1. Платформенное ядро SF4 (которое в рабочем проекте доступно как /simai) Это системная инфраструктура SF4: загрузка ассетов, служебные файлы, базовые конфиги, действия мастера и т.д.

2. Устанавливаемые артефакты Bitrix

   • компоненты SF4, которые ставятся в /bitrix/components/simai (через install/bitrix/components/simai внутри поставки);
   • системный шаблон, который ставится в /bitrix/templates/simai.framework (через install/bitrix/templates/...).

3. Сервисная часть модуля Админ-страницы, классы/утилиты, конфиги, которые обеспечивают работу панели, редакторов и сценариев настройки.

Практическое правило разработки: код модуля и ядро SF4 — это платформа. Если вы меняете их “в проекте”, вы усложняете обновления и переносы. Проектные изменения должны жить в {site_dir}/simai.data.

/bitrix/templates/simai.framework — системный шаблон (php/css/js/include). Используется как базовый; кастомизации выполняются копированием/расширением в {site_dir}/simai.data/templatelink

Системный шаблон — это точка, где SF4 “включается” на публичной части: базовая разметка страницы, подключение ассетов и общие include-участки. В шаблоне, помимо базовых файлов (например header.php, footer.php, description.php, стили/настройки), часто присутствуют и шаблоны компонентов, которые обеспечивают типовые сценарии отображения в стиле SF4.

Ключевое правило для проектов: системный шаблон не правится напрямую. Любые адаптации под конкретный сайт/решение (дополнительные CSS/JS, переопределения meta/panel/property, локальные include-фрагменты) выносите в:

• {site_dir}/simai.data/template

Так вы сохраняете чистую границу: “платформа обновляется” — “проект не ломается”.

/simai (в составе модуля) — ядро фронтенда/бэкенда, не редактируется в проектах; все правки делать в слое данныхlink

/simai — это ядро SF4 как платформы: системные конфиги и инфраструктура, на которой работают и публичные механики (грид/представления/блоки), и админ-инструменты (панель, режимы редактирования), и мастер установки/миграций.

Смысл запрета на правки простой: если вы меняете /simai “под проект”, вы фактически делаете форк платформы. Это резко увеличивает стоимость обновлений и диагностики.

Правильный способ расширения — через проектный слой {site_dir}/simai.data: там и должны появляться ваши представления, блоки, ассеты и настройки.

{site_dir}/simai.data — слой данных сайта: config (ассеты/шрифты/структура), template (meta/style/js/panel/property), grid (view/block), include, modal, lang, image, overrides свойствlink

{site_dir}/simai.data — главный “контейнер проекта” в SF4. Это то, что вы переносите между средами и храните как проектные артефакты, потому что именно здесь живут:

• config/ — конфиги проекта

  • схема настроек сайта (.site.config.php),
  • схема настроек структуры (.structure.config.php),
  • ассеты (.asset.config.php),
  • шрифты (.font.config.php) и т.д.

• template/ — проектные расширения шаблона (meta/style/js/panel/property и прочие точки, которые вы используете в вашем решении)

• grid/ — сборка страниц

  • grid/view/ — представления областей (header/footer/sidebar/main/home и т.д.)
  • grid/block/ — блоки (реализации area-шаблонов)

• include/, modal/, lang/, image/ — проектные вспомогательные артефакты

• property/ — переопределения/расширения, связанные со свойствами на уровне проекта (когда это требуется вашим решением)

Практический смысл: если вы придерживаетесь модели “всё проектное — в simai.data”, то обновления платформы становятся рутинными, а развёртывание/перенос — предсказуемым.

Используемый проектный слой данныхlink

В рабочих проектах SF4 опирается на {site_dir}/simai.data как на единственную целевую папку проектных данных: представления, блоки, конфиги, ассеты и настройки живут именно там. Это важно фиксировать в документации как правило, потому что от него зависят и обновления, и диагностика, и переносы между средами.

Поставки решения: архивы данных и место хранения (локально/удалённо) и политика деинсталляцииlink

Для решений SF4 типовой сценарий поставки данных — через мастер (wizard), который умеет импортировать артефакты решения. На практике артефакты (например архивы инфоблоков/данных) могут:

• храниться локально в составе решения/модуля,
• либо подтягиваться с удалённого источника (в зависимости от реализации мастера конкретного решения).

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

Рекомендованная фиксация в документации решения: мастер должен явно описывать, что он создаёт и что удаляет (см. чек-лист регламента мастера в предыдущем разделе).

В ядре /simai обратить внимание на config/, property/, asset/. Site-override для свойств — в simai.data/propertylink

Если разработчик решения углубляется в диагностику или подготовку установочных сценариев, полезно знать “три опорные зоны” ядра:

• config/ — базовые системные конфиги платформы (включая системные описания ассетов/шрифтов/настроек)
• property/ — базовые шаблоны/инфраструктура свойств, на которую опирается система универсальных свойств
• asset/ — системные библиотеки и ресурсы, которые используются панелью и инструментами SF4 (и часть — как фундамент фронтенда)

А проектные переопределения/расширения, связанные со свойствами, размещаются в {site_dir}/simai.data/property — это “правильная” точка, если нужно изменить поведение/шаблоны свойств на уровне сайта, не трогая платформу.