Модуль для Маркетплейса 1С-Битрикс: от идеи до публикации

Технически модуль Bitrix Framework — это каталог в /bitrix/modules/ с классом установки и набором файлов. Сделать такой модуль для своего проекта можно за день. Сделать модуль, который переживёт установку на чужой сайт, — совсем другая работа.

Главное отличие: вы не контролируете окружение

Своё решение работает на сайте, который вы знаете: редакция, версия PHP, набор модулей, шаблон, структура инфоблоков. Тиражное решение поставят туда, где всё иначе:

• Другая редакция — часть API может быть недоступна.
• Другая версия ядра — то, что появилось в свежем релизе, у клиента может отсутствовать.
• Уже установлены решения других разработчиков, иногда с теми же именами констант и обработчиками тех же событий.
• Свой шаблон сайта, который не обязан содержать привычные вам блоки.
• Права на файлы и структура каталогов могут отличаться от типовых.

Из этого следует базовое правило: модуль не должен предполагать ничего, чего он сам не проверил.

Структура и обязательные файлы

Каркас модуля устроен строго, и отступать от него не стоит — Маркетплейс проверяет структуру:

• install/index.php — класс установки, наследник CModule, с методами установки и удаления.
• include.php — точка входа, подключается при загрузке модуля.
• options.php — страница настроек в административном разделе.
• lang/ — языковые файлы, зеркалящие структуру модуля.
• install/components/, install/js/, install/admin/ — то, что копируется на сайт при установке.
• lib/ — классы в пространстве имён вендора, автозагружаемые ядром.

Идентификатор модуля вида vendor.modulename — не формальность. Он должен совпадать с именем каталога, с префиксом пространства имён и с идентификатором в партнёрском кабинете. Расхождение здесь ломает и автозагрузку, и обновления.

Установка и удаление: половина проблем именно здесь

Установка обычно пишется внимательно, а удаление — по остаточному принципу. При проверке смотрят как раз на второе.

Корректный обработчик удаления должен:

• снять все зарегистрированные обработчики событий;
• удалить созданные таблицы — но только с явного согласия администратора, а не молча;
• убрать скопированные файлы из /bitrix/components/, /bitrix/js/, /bitrix/admin/;
• удалить свои настройки из таблицы опций;
• снять пункты меню и права доступа, если они добавлялись.

Отдельный момент — повторная установка. Модуль удалили с сохранением данных, поставили снова: он должен подхватить существующие таблицы, а не упасть на попытке создать их заново.

Совместимость: проверяйте, а не предполагайте

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

То же касается версии PHP. Синтаксис, которого нет в минимально поддерживаемой версии, приведёт к белому экрану ещё до того, как отработает любая ваша проверка, — потому что файл не распарсится.

Локализация и тексты

Ни одной строки на русском в коде — всё через языковые файлы. Это требование Маркетплейса и одновременно здравый смысл: решение может попасть на портал с английским интерфейсом.

Стоит помнить и о том, что языковые константы глобальны. Префикс с идентификатором модуля в имени каждой константы избавляет от конфликтов с чужими решениями.

Что проверяют перед публикацией

Проверка в основном инженерная, а не формальная. Наиболее частые причины возврата на доработку:

• ошибки и предупреждения PHP при включённом выводе ошибок;
• прямые SQL-запросы вместо API там, где API есть;
• отсутствие проверки прав в административных скриптах;
• непроверенные пользовательские данные в запросах и в выводе;
• файлы, оставшиеся после удаления модуля;
• жёстко зашитые пути вместо констант документа и сайта;
• тексты в коде вместо языковых файлов.

Полезно перед отправкой поставить модуль на чистый сайт минимально поддерживаемой редакции, пройти сценарий «установил — настроил — использовал — удалил» и посмотреть, что осталось в файловой системе и в базе.

После публикации

Публикация — начало сопровождения, а не финал. Появятся вопросы в поддержке, отзывы, обновления ядра, которые что-то ломают, и запросы на функциональность, о которой вы не думали.

Здесь помогает дисциплина версий: обновление должно накатываться поверх любой ранее выпущенной версии, а не только предыдущей. Клиенты обновляются нерегулярно, и модуль вполне может прыгнуть через несколько релизов сразу.