Обновления SIMAI/Bitrix: держать свои изменения в simai.data и отдельных модуляхlink

В SF4 обновляемыми и неизменяемыми считаются ядро /simai и базовый системный шаблон /bitrix/templates/simai.framework. Поэтому единственный устойчивый способ переживать обновления (особенно при обновлении через сервер обновлений) — хранить все проектные изменения в {site_dir}/simai.data и/или в отдельных модулях, не вмешиваясь в реализацию simai.framework.

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

Права: доступ на запись в {site_dir}/simai.data при развертывании и обновленииlink

Для эксплуатации критично обеспечить права на чтение/запись в слой данных сайта. Большинство “неочевидных” проблем после обновления выглядят одинаково: в интерфейсе что-то “сохраняется”, но фактически изменения не применяются, потому что запись в файл/каталог не удалась.

Минимальная эксплуатационная проверка перед обновлением и сразу после него:

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

Кэш: после изменений конфигов/шаблонов/блоков очищать кэш Bitrix и проверять ассетыlink

SF4 активно опирается на файловую структуру и конфиги, а Bitrix — на кэширование. Поэтому после изменений в:

• шаблоне (simai.data/template/**),
• конфигурациях (simai.data и /.property.php),
• блоках/вьюхах (simai.data/grid/**),

обязательно очищайте кэш Bitrix, иначе вы рискуете отлаживать “старую картину мира”. Для ассетов (CSS/JS) дополнительно проверяйте DevTools: реально ли загружается новый файл, нет ли дублей библиотек, и совпадает ли порядок подключения зависимостей.

Версии и совместимость: фиксировать версии модулей и проверять поведение на целевом стеке Bitrix/PHPlink

Вы договорились держаться требований 1С-Битрикс по PHP: минимум 8.0, рекомендуемо 8.2. Это нужно зафиксировать как базовый стандарт окружения для SF4-проектов.

По модулям в локальных данных видны конкретные версии (их полезно фиксировать в регламенте как “точку отсчёта”):

• simai.framework: 5.0.110 (дата версии: 2025-10-15)
• simai.property: 4.1.8 (дата версии: 2025-07-28)
• simai.property4field: 2.2.7 (дата версии: 2025-10-16)
• simai.property4iblock: 2.6.4 (дата версии: 2025-11-07)

Отдельно про “проверки совместимости”: в коде встречается использование SM_VERSION (как источника версии Bitrix). Проверки вида usertypestr в локальных данных не найдено — если в ваших проектах есть регламент “проверять usertypestr”, его стоит уточнить отдельным примером/фрагментом кода.

Матрица версий: зафиксировать текущую SF4-версию, Bitrix и PHP, плюс правила обновленийlink

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

• SF4 (версия модулей simai.framework, simai.property*)
• 1С-Битрикс (версия продукта на проекте)
• PHP (фактическая версия; минимум 8.0, целевой стандарт 8.2)
• канал обновлений (у вас: через сервер обновлений)
• статус проверки (например: “прогнаны smoke-тесты на стенде/в проде”)

Такую матрицу удобно обновлять каждый раз после апдейта: это резко снижает время диагностики “почему стало ломаться” через пару месяцев.

Регламент обновления: шаги (бэкап → модуль → проверка данных/шаблона → кэш)link

Ниже — базовый регламент, который хорошо работает при обновлении через сервер обновлений и минимизирует риск потери кастомизаций:

1. Бэкап

   • база данных;
   • {site_dir}/simai.data (как минимум);
   • при необходимости — весь сайт/код решения.

2. Обновление модулей через сервер обновлений

   • обновить SF4-модули штатным механизмом.

3. Проверка кастомизаций

   • всё ли на месте в simai.data/template/**, simai.data/grid/**, областях simai.data/template/area/**;
   • нет ли прямых правок в /simai и базовом системном шаблоне.

4. Очистка кэша

   • кэш Bitrix;
   • проверка в браузере (Network/Console).

5. Smoke-тесты

   • открываются ключевые страницы публичной части;
   • работает основной функционал редактирования/панелей (если включается режимами);
   • нет фаталов и массовых 404 по ассетам.

Кастомизация vs ядро: что считается “нашим” и что “обновляемым”link

Удобно формулировать это как контракт:

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

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

История изменений: вести changelog и привязывать к версиям окруженияlink

Для эксплуатации полезно вести changelog на уровне решения/проекта, где каждая запись фиксирует:

• дату обновления,
• набор обновлённых модулей и их версии,
• “что проверили” (ссылкой на чек-лист smoke-тестов),
• заметки о миграциях/ручных действиях (если были).

Это превращает обновления SF4 из “события с риском” в повторяемую процедуру.

Правила совместимости и тестирования: breaking changes, миграции, эталонный стендlink

Чтобы управлять рисками обновлений, достаточно трёх дисциплин:

• фиксировать, какие изменения являются breaking (если они есть), и описывать миграцию как пошаговый рецепт;
• прогонять обновления сначала на эталонном стенде (желательно с актуальными кастомизациями simai.data, чтобы ловить проблемы “как в бою”);
• поддерживать матрицу SF4↔Bitrix↔PHP как живой документ: минимум — “какая связка на проде” и “какая проверена на стенде”.