home chevron_right
Где хранить доработки

Фронтенд, конфиги, блоки/гриды: {site_dir}/simai.datalink

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

  • не перезаписывается при обновлении ядра SF4,
  • удобно переносится между окружениями,
  • и является основной публичной точкой расширения, на которую рассчитана архитектура SF4.

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

  • template/ — проектная кастомизация шаблона:

    • template.php — основной файл, который собирает страницу
    • area/ — include-области (подключаются через IncludeArea::includeTemplateArea())
    • panel/ — элементы панели (в вашем проекте panel.php добавляет кнопки в админ-панель)
    • property/ — установка/подготовка свойств страницы (в вашем проекте property.php задаёт значения свойств, на которых строится страница)
    • style/ и js/ — проектные стили и скрипты
    • meta/ — метаданные/обвязка <head> (если выделено в структуре шаблона)

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

    • настройки site/section/page через property-файлы
    • сервисные конфиги (например, ассеты/шрифты, если они предусмотрены проектной структурой)

  • grid/ — проектные вьюхи и блоки:

    • добавление новых вариантов
    • override существующих системных шаблонов через слой данных сайта

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

    • включаемые области (в другом формате, не “area”)
    • модальные окна/шаблоны модалок
    • языковые файлы и ресурсы
    • изображения и статические материалы

  • property overrides — слой переопределений свойств (если в проекте используется отдельная схема override, она также относится к данным сайта и должна жить в simai.data).

Ключевой принцип: если доработка выражается файлами шаблона/конфигом/шаблоном блока/ресурсом — она должна лежать в simai.data.

Бэкенд-расширения: оформлять в отдельные модули, не правя ядро simai.frameworklink

Когда доработка — это не “шаблон и конфиг”, а новая бизнес-логика (сущности, события, сервисы, API, админ-страницы, интеграции), правильная стратегия — делать это как отдельный модуль.

Почему так лучше:

  • ядро simai.framework обновляется через сервер обновлений и должно оставаться “чистым”;
  • модуль проще версионировать, тестировать и переносить;
  • модуль можно включать/выключать, обновлять отдельно и поддерживать совместимость на уровне зависимостей.

Типовой подход для модуля-расширения:

  • собственное пространство имён (чтобы не пересекаться с SIMAI\Main\...);
  • свои классы и обработчики событий;
  • если нужно — свои компоненты и админ-страницы;
  • использование D7 API Bitrix как базовой платформы.

Важно: если вам нужно “переопределить поведение SF4”, делайте это не правкой классов ядра, а через:

  • события/обработчики Bitrix (если точка расширения есть),
  • проектный слой simai.data (если это UI/шаблоны/конфиги),
  • модуль, который добавляет свою функциональность рядом (если это логика).

Всегда использовать коды и чистые пути; перед добавлениями сверять структуруlink

Независимо от того, где вы храните доработку (в simai.data или модулем), два правила одинаково критичны:

  1. Коды и пути — “чистые”: латиница, без пробелов/кириллицы, предсказуемые разделители (_/-), без “магических” символов. Это уменьшает риск ошибок путей и делает проект переносимым.

  2. Доработка кладётся в правильное место структуры. В SF4 многие механизмы ищут файлы по соглашению. Если файл лежит “почти там”, он просто не будет найден, и проблема будет выглядеть как “SF4 не подключает”.

Практический мини-чек перед коммитом:

  • Понимаю тип сущности (область, блок, вьюха, конфиг, модульная логика)?
  • Положил в корректный слой (simai.data или модуль)?
  • Имя/код читаемое и переносимое?
  • Подключение делаю через публичный механизм SF4 (IncludeArea / Block\Section / шаблон), а не через правку системных файлов?