home chevron_right
Проверка первого запуска

Активировать шаблон для нужного сайта и открыть главную страницу: убедиться в отсутствии PHP/JS ошибокlink

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

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

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

Проверить подключение ассетов и конфигов: {site_dir}/simai.data/config/.asset.config.php, .font.config.php; сверить пути к CSS/JS при необходимостиlink

Дальше проверяется проектный слой ресурсов: наличие и корректность конфигураций ассетов и шрифтов в {site_dir}/simai.data/config. Этот шаг критичен именно в вашей модели, потому что конфигурация ассетов сайта замещает, а не дополняет системную: если в проектной конфигурации не описан нужный пакет или неверно указан путь к файлу, это приводит не к “частичному улучшению”, а к прямой поломке загрузки ресурсов.

Что стоит проверить руками на первом запуске:

  • файлы конфигурации реально существуют в проекте;
  • в браузере загружаются CSS/JS без 404;
  • ресурсы не подключаются “дважды” (особенно библиотеки типа jQuery/Bootstrap и пакеты SF4);
  • если в Bitrix включён режим минифицированных ассетов, отсутствие .min.* рядом с обычными файлами не вызывает неожиданных проблем (например, “в проде работает иначе, чем на деве”).

Если на этом этапе видите странности в поведении фронта — чаще всего причина именно в составе/замещении пакетов ассетов на уровне сайта.

Протестировать грид и блоки: вывести тестовую страницу с simai:sf.gridlink

Когда шаблон и ассеты “живые”, следующий шаг — проверить, что грид реально собирает страницу и находит проектные представления/блоки.

Удобный минимальный тест — отдельная страница (например /test-grid.php), где вы подключаете simai:sf.grid и указываете VIEW:

<?php
$APPLICATION->IncludeComponent(
    "simai:sf.grid",
    ".default",
    [
        "VIEW" => "home_main",
    ]
);

На что смотреть:

  • компонент подключился (нет фаталов, нет “компонент не найден”);
  • выбранный VIEW действительно существует как представление в проектном слое и подхватывается (если VIEW неверный — вы быстро увидите пустую сборку или неправильную структуру);
  • блоки внутри областей реально рендерятся, а не “пропускаются” из-за отсутствия реализации в simai.data/grid/block.

Если у вас активные view областей задаются через grid_view_*, полезно параллельно сверить, что коды из настроек действительно соответствуют папкам представлений нужных областей (header, footer, sidebar/left|right, main/top|bottom, home).

Проверить работу мастера: наличие /simai/wizard/action, отсутствие 404 на шаги мастераlink

На первом запуске важно подтвердить, что инфраструктура мастера доступна: платформа видит действия мастера и может выполнять шаги (копирование файлов, импорт данных, настройка окружения).

Практическая проверка тут простая по смыслу:

  • действия мастера существуют в системе и доступны платформе;
  • при запуске мастера установки решения не возникает “провалов” по шагам (404/фаталы), а длинные операции идут пошагово (обычно в AJAX-режиме).

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

Минимальный тест компонентов: simai:sf.iblock.list и simai:sf.grid в демо-режимеlink

После проверки грида имеет смысл сделать минимальную проверку одного “данного” компонента (например списка инфоблоков) — чтобы подтвердить связку: компонент SF4 → данные Bitrix → вывод в шаблоне.

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

  • компонент подключается без ошибок,
  • параметры читаются корректно,
  • шаблон компонента доступен,
  • кэширование не ломает первичную диагностику (на старте удобнее отключать кэш у тестов).

simai:sf.grid при этом остаётся основным “интеграционным” тестом, потому что он проверяет именно SF4-модель сборки областей через представления и блоки.

Где смотреть примеры/описания: готовые страницы и установленная структураlink

Для диагностики первого запуска всегда полезнее опираться не на абстрактную теорию, а на то, что уже установлено и работает в проекте:

  • сравнивать поведение “как должно быть” проще всего по готовым страницам решения;
  • структуру проекта (что где лежит) удобнее всего проверять по фактическим путям в установленной системе: модуль, шаблон, слой {site_dir}/simai.data, представления grid/view и блоки grid/block.