Модерация Marketplace опирается на «Стандарт разработки» 1С-Битрикс. Разберём обязательные файлы модуля, совместимость, локализацию, безопасность и чек-лист, который убережёт от отказа.
Стандарт разработки и роль модерации
Каждое решение перед появлением в каталоге проходит технический аудит и модерацию. Проверяющий разворачивает модуль на эталонном стенде, устанавливает и удаляет его, оценивает соответствие «Стандарту разработки» — своду требований к структуре, коду и поведению модуля.
Смысл требований прост: решение устанавливается на тысячи чужих проектов, поэтому оно должно быть предсказуемым, безопасным и не оставлять следов после удаления. Нарушение любого обязательного пункта — основание для возврата на доработку.
Обязательные файлы модуля
Модуль обязан содержать минимальный набор служебных файлов, без которых установщик и система обновлений не работают.
install/index.php— класс, наследующийCModule, с полным набором методов установки:DoInstall(),DoUninstall(),InstallDB(),UnInstallDB(),InstallEvents(),InstallFiles().install/version.php— массив версии:$arModuleVersion = array("VERSION"=>"1.0.0", "VERSION_DATE"=>"2026-01-01 12:00:00");..description.php— имя, описание, категория и путь к настройкам модуля для админ-панели.lang/— языковые сообщения для всех текстов интерфейса.
Идентификатор модуля в этих файлах и имя каталога partner_code.module_name должны совпадать. Регистрация выполняется через RegisterModule(), снятие — через UnRegisterModule().
Таблица ключевых требований
Требования удобно держать сгруппированными по областям. Ниже — сводка того, что проверяется в первую очередь.
| Область | Требование |
|---|---|
| Структура | Каталог partner_code.module_name, корректный install/ |
| Совместимость | Работа в заявленных редакциях и версиях ядра |
| Установка | Полная и обратимая: DoInstall / DoUninstall |
| Ядро | Никаких изменений системных модулей |
| Локализация | Все тексты через lang/, кодировка UTF-8 |
| Безопасность | Проверка прав, экранирование, отсутствие eval |
| Компоненты | Только 2.0 с полным набором файлов |
Совместимость, кодировка и локализация
Совместимость с ядром. В карточке решения указываются редакции (Старт, Стандарт, Малый бизнес, Бизнес и т. д.) и минимальные версии, при которых модуль работоспособен. Код не должен опираться на API, отсутствующее в младших заявленных редакциях, и обязан деградировать корректно, а не падать с фатальной ошибкой.
Кодировка и локализация. Файлы поставляются в UTF-8, а все выводимые строки выносятся в языковые файлы каталога lang/ и подключаются через GetMessage(). Хардкод текста прямо в коде — частая причина замечаний.
Чистая установка и безопасность
Установка и удаление без мусора. После DoUninstall() в системе не должно оставаться таблиц, обработчиков событий, файлов и прав, созданных модулем. Проверяющий сравнивает состояние стенда до установки и после полного удаления — расхождения недопустимы.
Без изменений ядра. Решение работает только через штатные API и события. Правка файлов системных модулей, подмена ядреных классов или запись в чужие директории отклоняются.
- Проверка прав. Доступ к административным действиям контролируется через права модуля и проверку сессии.
- Экранирование. Все данные, попадающие в SQL и HTML, экранируются штатными средствами; параметры запросов не подставляются напрямую.
- Без
eval. Динамическое исполнение произвольного кода и обфускация запрещены — код должен быть читаемым для аудита.
Требования к компонентам и чек-лист
Компоненты, входящие в решение, должны быть версии 2.0 и содержать полный комплект файлов: component.php, .description.php, .parameters.php и хотя бы один корректный шаблон в templates/.default/. Параметры выносятся в .parameters.php, а тексты — в языковые файлы компонента.
Перед отправкой на модерацию пройдите по короткому чек-листу:
- Модуль ставится и полностью удаляется на чистом стенде каждой заявленной редакции.
- Присутствуют
install/index.php,install/version.php,.description.php. - Все тексты вынесены в
lang/, файлы в UTF-8. - Нет изменений ядра и записи в чужие директории.
- Проверяются права и экранируются входные данные, нет
eval. - Компоненты 2.0 укомплектованы шаблонами и параметрами.
- Демо-режим и лицензирование работают согласно заявленным тарифам.
Наиболее частые причины отказа: неполное удаление, хардкод ID и текстов, изменение ядра, незакрытые дыры в проверке прав и неработающий демо-режим.
Итог
Пройти модерацию Marketplace — значит выполнить «Стандарт разработки»: обязательные файлы install/index.php, version.php, .description.php, полная обратимость установки, совместимость с заявленными редакциями, локализация через lang/, безопасность и корректные компоненты 2.0. Чек-лист перед отправкой снимает большинство замечаний ещё до аудита.
Если нужно привести существующий модуль в соответствие требованиям или спроектировать решение сразу «под модерацию», мы проводим аудит кода, дорабатываем установку и безопасность и сопровождаем публикацию. Поможем пройти проверку с первого раза и настроить последующую поддержку.
Частые вопросы
Что чаще всего становится причиной отказа модерации?
Неполное удаление модуля (остаются таблицы, события или файлы), изменение файлов ядра, хардкод ID инфоблоков и текстов, отсутствие проверки прав и неработающий демо-режим. Большинство этих проблем выявляется по чек-листу до отправки.
Обязательна ли поддержка нескольких языков?
Все выводимые тексты должны быть вынесены в языковые файлы каталога lang/ и подключаться через GetMessage. Как минимум требуется русская локализация; английская расширяет аудиторию и часто ожидается для международных решений.
Можно ли использовать компоненты версии 1.0?
Нет. Требуются компоненты 2.0 с полным набором файлов: component.php, .description.php, .parameters.php и корректным шаблоном в templates/.default/. Компоненты 1.0 не соответствуют Стандарту разработки.
Почему запрещены изменения ядра?
Правка системных модулей ломается при обновлениях платформы и делает поведение непредсказуемым на чужих проектах. Решение должно работать только через штатные API и события, не затрагивая файлы в /bitrix/modules/main и других системных модулях.
Как проверяют чистоту удаления?
Проверяющий фиксирует состояние стенда до установки, ставит модуль, затем выполняет DoUninstall и сравнивает результат. Любые оставшиеся таблицы, обработчики событий, права или файлы модуля считаются нарушением.
Что именно проверяется в части безопасности?
Проверка прав доступа к административным действиям, экранирование данных при выводе в HTML и подстановке в SQL, отсутствие eval и обфускации, корректная работа с сессией. Код должен быть читаемым и не исполнять произвольные внешние данные.
Нужен ли демо-режим для платного решения?
Да. Платное решение должно корректно работать в ограниченном демонстрационном режиме до активации лицензии, а полная функциональность открывается после проверки прав по редакции, домену или ключу. Неработающий демо-режим — повод для отказа.
Где указываются совместимые редакции и версии?
Совместимость декларируется в карточке решения в партнёрском кабинете и должна соответствовать реальному поведению кода. Модуль обязан работать во всём заявленном диапазоне редакций и версий ядра, не опираясь на недоступное в младших редакциях API.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.