Админ-настройки сайта/раздела/страницы используют конфиги из {site_dir}/simai.data/configlink

В SIMAI Framework 4 (SF4) административные интерфейсы настройки опираются на файловый слой данных сайта {site_dir}/simai.data: значения фиксируются как конфигурация проекта, а не «вшиваются» в системные файлы. На практике это удобно тем, что настройки можно переносить между окружениями как обычные файлы, и при этом не ломать обновления ядра.

Часть настроек живёт в property-файлах уровня сайта/раздела/страницы: например, выбор активных представлений областей (grid_view_*) хранится на уровне сайта в {site_dir}/simai.data/.site.property.php, а переопределения для разделов/страниц — в соответствующих .property.php, с наследованием между уровнями.

Пример «сигнального» чтения настройки из property (используется как флаг режима редактирования, влияющий на UI):

"HIDE_ICONS" => (Property::getValue(SF_SITE_DIR, "grid_edit_mode") == "Y" ? /* ... */ : /* ... */)

Публичный редактор инфоблоковlink

В SF4 отдельно подчёркнута поддержка публичного редактирования данных инфоблоков (разделы/элементы) как части общей концепции «виртуальной CMS»: редактирование и конфигурирование — это не набор разрозненных страниц, а встроенный сценарий платформы.

При этом, по общему принципу SF4, интерфейсы редактирования и настроек стремятся опираться на универсальные свойства (simai.property*): тип данных выбирается «по данным», а шаблон отображения — «по UX» (как это должен видеть редактор/администратор).

Что именно является «компонентом публичного редактора инфоблоков» (точное имя/путь/параметры) — не найдено в локальных данных в предоставленных фрагментах.

Связь с публичными формами/компонентамиlink

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

Отдельно в составе SF4 фиксируется наличие набора компонентов для работы с инфоблоками (списки/детальные/разделы и т. п.) и наличие компонента-редактора свойств (sf.property.edit) в группе media/forms — это даёт основу, чтобы параметрические формы компонентов и редакторы были согласованы по типам/шаблонам полей.

Чек-лист готовности (настройки)link

1. В проекте используется слой {site_dir}/simai.data для изменений; системное ядро /simai не редактируется.

2. На месте property-файлы уровней (site/section/page), и вы понимаете, какой уровень должен перекрывать какой (например, site → section/page через .property.php).

3. Есть права на запись в {site_dir}/simai.data (иначе изменения через интерфейсы не смогут сохраниться и будут «пропадать»).

4. После изменения настройки вы можете проверить «артефакт сохранения»: результат визуального редактирования (в части грида) фиксируется в {site_dir}/simai.data/grid/view/.../template.php, а выбор активного view — в property (grid_view_*) на уровнях site/section/page.

5. Если настройка влияет на UI-режимы (например, grid edit mode), вы можете подтвердить эффект через чтение значения свойства (по аналогии со сниппетом Property::getValue(..., 'grid_edit_mode')).