Загрузка и установка модуля: поставить simai.framework через установщик Bitrix
simai.framework устанавливается как обычный модуль Bitrix: после размещения файлов модуля в системе вы выполняете установку через административный интерфейс Bitrix (модульная установка). Результат установки удобно проверять по “следам” платформы:
- появляется системный шаблон
/bitrix/templates/simai.framework(если он поставляется в вашей сборке); - появляется набор компонентов
/bitrix/components/simai; - в проекте доступна системная папка ядра
/simai(в ней живут системные конфиги, мастер/действия мастера и служебная инфраструктура SF4).
Быстрый прикладной тест после установки — убедиться, что модуль реально подключается в окружении:
<?php
declare(strict_types=1);
use Bitrix\Main\Loader;
if (!Loader::includeSharewareModule('simai.framework'))
{
throw new RuntimeException('Модуль simai.framework не подключился');
}
Если модуль не подключается — дальше нет смысла проверять шаблон/гриды: сначала должна быть исправлена установка/активация модуля.
Подключить зависимые модули: simai.property (и при необходимости simai.property4field, simai.property4iblock)
Для SF4 базовой зависимостью выступает модуль универсальных свойств:
simai.property— нужен как основа системы универсальных свойств/настроек (вокруг них строится часть логики конфигураций и UI).
Дополнительные модули семейства свойств подключаются по факту используемых сценариев решения:
simai.property4fieldsimai.property4iblock
Практическое правило: для старта и базовой эксплуатации SF4 фиксируйте обязательный минимум (simai.framework + simai.property), а “расширения” подключайте как часть конкретного решения, чтобы требования не раздувались без необходимости.
Активировать шаблон: выбрать /bitrix/templates/simai.framework как основной для сайта
Чтобы SF4 начал работать на публичной части, сайт должен быть переведён на шаблон SF4 (или шаблон решения, построенный поверх него). После активации шаблона важно, чтобы проектный слой сайта был готов для расширений и переопределений:
- проектные стили/скрипты и адаптации должны жить в
{site_dir}/simai.data/template(а не в системном шаблоне); - представления/блоки и конфиги — тоже в проектном слое, чтобы обновления платформы не затрагивали ваши правки.
Смысл этого шага — отделить “платформу” (обновляемую) от “проекта” (стабильного и переносимого).
Проверить ассеты и конфиги: .asset.config.php и .font.config.php
После установки и активации шаблона стоит проверить, что в проектном слое присутствуют ключевые конфиги, через которые сайт управляет ресурсами:
{site_dir}/simai.data/config/.asset.config.php— пакеты ассетов проекта (CSS/JS);{site_dir}/simai.data/config/.font.config.php— шрифты проекта.
Дальше — уже проектные правила:
- если вы переопределяете состав пакетов, важно помнить ваш принцип: конфигурация ассетов на уровне сайта замещает системную, а не “добавляется поверх неё”. Это защищает проект от неожиданных изменений при обновлениях платформы (когда в ядре поменяли состав пакетов), но требует дисциплины: все нужные пакеты должны быть корректно описаны в проектной конфигурации.
Где брать примеры: структура шаблона и компонентов
В качестве “живых” примеров для разработчика решения полезнее всего использовать то, что реально установлено в системе:
- компоненты SF4 — в
/bitrix/components/simai(включая их параметры через.parameters.phpи шаблоны); - системный шаблон —
/bitrix/templates/simai.framework(как точка подключения платформы); - проектные расширения — в
{site_dir}/simai.data(где удобно смотреть реальныеgrid/view,grid/block, конфиги и шаблонные переопределения).
Это даёт практику “учиться на том, что реально работает в проекте”, а не на абстрактных примерах.
Обновление/удаление: что важно зафиксировать, чтобы не ломать проекты
Для обновлений ключевое правило простое: не держать проектные правки в ядре. Если все изменения сделаны через {site_dir}/simai.data, обновление simai.framework не должно требовать ручных “слияний” кода.
С деинсталляцией важно различать два случая:
- удаление/обновление платформы
simai.framework(модуль SF4); - удаление решения, установленного мастером (wizard), которое могло создавать файлы, инфоблоки и другие сущности.
В вашей практике для решений, устанавливаемых мастером, деинсталляция может включать удаление всех установленных файлов и инфоблоков, но общий “канонический регламент” политики деинсталляции ещё требует формализации. Поэтому для каждого решения лучше заранее фиксировать: что мастер создаёт и что именно удаляется при деинсталляции (полностью/частично).
Примеры параметров/шаблонов компонентов
Когда нужно понять, какие параметры реально принимает компонент SF4, самый надёжный путь — смотреть его файл параметров (.parameters.php) и шаблон, который используется по умолчанию. Это полезно и для Quick Start, и для диагностики, когда “параметр передали — а он не работает”: часто причина в точном имени/типе параметра.
Если хочешь, следующим шагом я могу оформить мини-чек “после установки” в 8–10 пунктов (модуль подключается, шаблон активен, grid_view_* выставлены, view-папки существуют, базовая страница с simai:sf.grid собирается, ассеты без дублей и т.д.) — он хорошо ляжет в раздел “Проверка первого запуска”.