Установщик решения (install/index.php) как точка запуска мастераlink

В SF4 решение обычно ставится как модуль 1С-Битрикс (например, simai.sf4university). Установщик модуля выполняет две ключевые задачи: раскладывает артефакты решения (в том числе мастер установки) в ожидаемые системные пути и переводит пользователя в установочный сценарий.

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

• /simai/wizard/master/<код_решения>/

На этой странице подключаются базовые ассеты и вызывается компонент мастера (simai:sf.wizard), который дальше уже управляет сценарием (шагами, данными, условиями, автопереходами).

Пример входной страницы мастера (упрощённо):

<?php
define("LANGUAGE_ID", "ru");
require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/main/include/prolog_before.php");

\Bitrix\Main\Loader::includeSharewareModule("simai.framework");

$APPLICATION->IncludeComponent(
    "simai:sf.wizard",
    ".default",
    [
        "WIZARD_DIR" => "/simai/wizard/master/simai.sf4university",
        "WIZARD_CONFIG_FILE" => "/simai/wizard/master/simai.sf4university/.wizard.config.php",
        "AJAX_TIME_STEP" => 3,
        "AJAX_TIME_INTERVAL" => 1,
        "AJAX_MODE" => "Y",
        "CACHE_TYPE" => "N",
    ]
);

Конфиг мастера .wizard.config.php: description + action (цепочка шагов)link

Сценарий мастера задаётся одним PHP-конфигом, который возвращает массив. В нём две смысловые части:

• description — мета-информация мастера (название, код, параметры поведения вроде возможности продолжать сценарий).
• action — цепочка шагов; каждый шаг ссылается на action по коду (например file.copy, iblock.import.archive, data.add.property) и описывает вход/выход данных и параметры запуска.

Важная идея: мастер ведёт единый массив данных, а шаги читают и пишут отдельные подмассивы по ключам data_input_code / data_output_code. Это позволяет строить сценарии “конвейером”: один шаг подготовил данные — следующий их использовал.

Пример одного шага с условием и автопереходом:

return [
    "description" => [
        "code" => "simai_sveden",
        "stage_renew" => "Y",
    ],
    "action" => [
        [
            "name" => "Копирование файлов",
            "code" => "file.copy",
            "data_input_code" => "site_config",
            "autocomplete" => "Y",
            "condition" => [
                "property" => [
                    [
                        "array" => "site_config",
                        "key" => "sf4",
                        "value" => "Y",
                        "operator" => "==",
                    ],
                ],
            ],
            "parameter" => [
                [
                    "source" => "/some/source",
                    "destination" => "/some/destination",
                    "name" => "copy-step",
                ],
            ],
        ],
    ],
];

Конфиг полей мастера .property.config.php: схема ввода параметровlink

Когда на шаге нужно запросить данные у пользователя (название организации, домен, цвета и т.п.), мастер использует отдельный конфиг полей. Такой шаг обычно реализуется действием data.add.property, а конфиг подключается через параметр file.

Файл .property.config.php описывает поля в виде массива: для каждого поля задаётся как минимум type и default (часто ещё name для подписи). Типы полей зависят от UI мастера (например, string, color).

Пример схемы полей:

return [
    "organization" => [
        "name" => " ",
        "type" => "string",
        "default" => "",
    ],
    "domen" => [
        "name" => " ",
        "type" => "string",
        "default" => "",
    ],
    "primary_color" => [
        "name" => " ",
        "type" => "color",
        "default" => "#C51162",
    ],
];

Артефакты импорта: архивы инфоблоков/данных (локально в модуле или с удалённого источника)link

Для “разворачивания решения” мастер работает не только с файлами шаблона и конфигами, но и с импортом данных: структуры инфоблоков, разделов, контента и связанных настроек. Для этого используются пакеты-архивы (обычно .zip), которые мастер распаковывает и применяет через actions семейства iblock.* и вспомогательные file.*.

Откуда берутся пакеты:

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

Отдельный важный кейс — iblock.import.archive.sveden: по вашему описанию там используется разделение архива структуры и архива контента (то есть импорт идёт в два этапа/двумя источниками).