home chevron_right
Установка модуля simai.framework и активация шаблона

Загрузка и установка модуля: поставить simai.framework через установщик Bitrixlink

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)link

Для SF4 базовой зависимостью выступает модуль универсальных свойств:

  • simai.property — нужен как основа системы универсальных свойств/настроек (вокруг них строится часть логики конфигураций и UI).

Дополнительные модули семейства свойств подключаются по факту используемых сценариев решения:

  • simai.property4field
  • simai.property4iblock

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

Активировать шаблон: выбрать /bitrix/templates/simai.framework как основной для сайтаlink

Чтобы SF4 начал работать на публичной части, сайт должен быть переведён на шаблон SF4 (или шаблон решения, построенный поверх него). После активации шаблона важно, чтобы проектный слой сайта был готов для расширений и переопределений:

  • проектные стили/скрипты и адаптации должны жить в {site_dir}/simai.data/template (а не в системном шаблоне);
  • представления/блоки и конфиги — тоже в проектном слое, чтобы обновления платформы не затрагивали ваши правки.

Смысл этого шага — отделить “платформу” (обновляемую) от “проекта” (стабильного и переносимого).

Проверить ассеты и конфиги: .asset.config.php и .font.config.phplink

После установки и активации шаблона стоит проверить, что в проектном слое присутствуют ключевые конфиги, через которые сайт управляет ресурсами:

  • {site_dir}/simai.data/config/.asset.config.php — пакеты ассетов проекта (CSS/JS);
  • {site_dir}/simai.data/config/.font.config.php — шрифты проекта.

Дальше — уже проектные правила:

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

Где брать примеры: структура шаблона и компонентовlink

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

  • компоненты SF4 — в /bitrix/components/simai (включая их параметры через .parameters.php и шаблоны);
  • системный шаблон — /bitrix/templates/simai.framework (как точка подключения платформы);
  • проектные расширения — в {site_dir}/simai.data (где удобно смотреть реальные grid/view, grid/block, конфиги и шаблонные переопределения).

Это даёт практику “учиться на том, что реально работает в проекте”, а не на абстрактных примерах.

Обновление/удаление: что важно зафиксировать, чтобы не ломать проектыlink

Для обновлений ключевое правило простое: не держать проектные правки в ядре. Если все изменения сделаны через {site_dir}/simai.data, обновление simai.framework не должно требовать ручных “слияний” кода.

С деинсталляцией важно различать два случая:

  • удаление/обновление платформы simai.framework (модуль SF4);
  • удаление решения, установленного мастером (wizard), которое могло создавать файлы, инфоблоки и другие сущности.

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

Примеры параметров/шаблонов компонентовlink

Когда нужно понять, какие параметры реально принимает компонент SF4, самый надёжный путь — смотреть его файл параметров (.parameters.php) и шаблон, который используется по умолчанию. Это полезно и для Quick Start, и для диагностики, когда “параметр передали — а он не работает”: часто причина в точном имени/типе параметра.

Если хочешь, следующим шагом я могу оформить мини-чек “после установки” в 8–10 пунктов (модуль подключается, шаблон активен, grid_view_* выставлены, view-папки существуют, базовая страница с simai:sf.grid собирается, ассеты без дублей и т.д.) — он хорошо ляжет в раздел “Проверка первого запуска”.