Что хранится в simai.data и почему это основной слой доработокlink

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

• не зависеть от обновлений платформы (simai.framework);
• переноситься между средами предсказуемо (dev/stage/prod);
• не превращать проект в набор ручных правок в системных местах.

Важно различать артефакты проекта и значения настроек структуры сайта. simai.data хранит проектные конфиги и макеты, а значения настроек разделов/страниц у вас могут лежать рядом со структурой сайта в .property.php внутри разделов (например /ru/.property.php). Это не “противоречие”, а нормальная схема: проектный слой отвечает за механики и артефакты, а настройки разделов/страниц — за переопределения на конкретных участках дерева сайта.

Минимально значимая точка входа по настройкам сайта в самом simai.data — файл:

• {site_dir}/simai.data/.site.property.php (в том числе выбор активных VIEW областей через grid_view_*).

Основные каталоги: grid, template, config, include, modal, lang, image, propertylink

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

• grid/ — слой сборки страниц через гриды Здесь живут представления областей и блоки:

  • grid/view/... — VIEW областей (header/footer/home/sidebar/main top/bottom). Каждое представление — папка с template.php, где хранится сохранённая конфигурация simai:sf.grid (строки/колонки/area-шаблоны/условия).
  • grid/block/... — блоки/area-шаблоны, которые используются внутри view (и которые вы безопасно переопределяете на уровне проекта).

• template/ — точка расширения фронтенда проекта Сюда выносится всё, что должно “лечь поверх” системного шаблона: проектные CSS/JS, мета-части, include-фрагменты, элементы панели/интерфейса. Это базовый механизм кастомизации без правки системного шаблона.

• config/ — конфигурации проекта Здесь обычно лежат конфиги подключения ресурсов и поведения сайта (например конфиг ассетов и шрифтов). С учётом вашей практики важно помнить: на уровне сайта конфигурация ассетов замещает системную, а не дополняет.

• include/ — подключаемые фрагменты Удобное место для повторно используемых включаемых частей (контентные вставки, “области” для view, куски разметки/логики, которые подключаются из блоков/представлений).

• modal/ — модальные окна и их шаблоны Отдельный каталог под модалки упрощает сопровождение: модальные UI-сущности не смешиваются с блоками и include.

• lang/ — языковые файлы проекта Используется для локализации проектных блоков/представлений/интерфейсов, чтобы тексты не “расползались” по шаблонам.

• image/ — изображения проекта Обычно это проектные картинки, которые используются в блоках/шаблонах/панелях; сюда же логично класть превью для view, если вы хотите показывать их в UI выбора макетов.

• property/ — проектные переопределения, связанные со свойствами В SF4 это удобно держать отдельно: всё, что касается шаблонов/представления/переопределения универсальных свойств на уровне проекта.

Чтобы увидеть “картину целиком”, удобно держать в голове минимальный срез структуры:

{site_dir}/simai.data/
  .site.property.php
  config/
  template/
  grid/
    view/
    block/
  include/
  modal/
  lang/
  image/
  property/

{site_dir}/ru/.property.php   (пример: настройки раздела/страниц вне simai.data)

Какие файлы/папки считаются “артефактами проекта” и подлежат переносу между средамиlink

К “переносимым” артефактам проекта стоит относить всё, что определяет поведение и внешний вид сайта независимо от окружения:

• весь каталог {site_dir}/simai.data (как единый пакет проектного слоя);
• файл настроек сайта {site_dir}/simai.data/.site.property.php (особенно grid_view_*, потому что это активные макеты областей);
• файлы .property.php в дереве сайта (например /ru/.property.php и аналогичные), потому что они задают наследуемые настройки разделов и точечные настройки страниц;
• артефакты установки решения (если переносите окружение “как решение”): конфиги мастера и связанные с ним пакеты данных (архивы, схемы полей и т.п.).

Что обычно не стоит переносить как часть “артефактов проекта”:

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