Каждый раз, когда в проект на 1С-Битрикс прилетает нестандартная задача, свой алгоритм скидок, фильтр по нетиповым характеристикам, интеграция с внешней CRM или платёжной системой, встаёт один и тот же вопрос: ставить готовый битрикс модуль с маркетплейса, дорабатывать типовой функционал или писать модуль с нуля. От этого выбора зависит не только бюджет, но и то, переживёт ли решение следующее обновление платформы. За несколько лет работы с Битриксом я прошёл все три пути, и у каждого свои рабочие критерии выбора, конкретные ситуации, где один вариант объективно лучше двух других.
Три способа получить нужный функционал в 1С-Битрикс
Формально у любой задачи на Битриксе есть три решения.
Первый: найти готовый модуль в маркетплейсе Битрикс. Каталог решений там большой: интеграции с эквайрингом, службами доставки, CRM, конструкторы форм, коннекторы к маркетплейсам вроде Wildberries и Ozon. Модуль ставится через административную панель, у многих решений есть демо-период.
Второй: доработать типовой функционал. Битрикс устроен так, что почти любой компонент можно переопределить локально: скопировать шаблон в /local/templates/, повесить обработчик события в /local/php_interface/init.php, изменить логику через наследование класса. Файлы ядра при этом не трогаются, и правки переживают обновление платформы.
Третий: написать свой модуль. Это отдельная папка в /local/modules/ со своей структурой: install/index.php, классы, административные интерфейсы, собственные таблицы в базе. Такой путь оправдан, когда нужна логика, которой нет ни в одном готовом решении и которая достаточно объёмная, чтобы не размазывать её по обработчикам событий.
Дальше по каждому варианту, что он даёт на практике и где спотыкается.
Модуль с маркетплейса Битрикс: быстрый старт с готовым решением
Готовый модуль имеет смысл, когда задача типовая и её уже кто-то решил. Модуль интеграции с эквайрингом Т‑Банка, модуль расчёта доставки СДЭК, коннектор к amoCRM или Битрикс24, всё это стандартные вещи, которые не нужно изобретать заново.
Из плюсов: решение проверено на множестве сайтов, есть техподдержка от разработчика модуля, обновления выходят отдельно от ядра Битрикса и не требуют вмешательства в код проекта. Из минусов: модуль редко закрывает задачу на 100%, и последние 10-20% всё равно приходится дорабатывать поверх, а это уже сложнее, чем писать логику с нуля, потому что приходится разбираться в чужом коде и не ломать то, что уже работает.
Ещё момент, который часто упускают: не все модули одинаково аккуратно относятся к ядру. Часть решений исторически кладёт файлы прямо в /bitrix/, а не переопределяет их через /local/, и тогда обновление ядра рискует затереть правки или конфликтовать с модулем. Перед установкой я смотрю структуру дистрибутива и код хотя бы одного PHP-файла: если разработчик работает через события и /local/, доверия к модулю больше.
Стоимость лицензий на маркетплейсе сильно разнится, от бесплатных решений до платной годовой подписки, в зависимости от разработчика и набора функций. Точные цифры смотрите на странице конкретного модуля, здесь я не берусь называть чужие цены.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Доработка типового функционала Битрикс без правки ядра
Когда типовой функционал в целом устраивает, но нужно поменять часть логики, доработка обходится дешевле и быстрее свежего модуля. Два основных инструмента здесь: локальные шаблоны и обработчики событий.
Локальные переопределения вместо правки ядра
Шаблон компонента копируется из /bitrix/components/…/templates/ в /local/templates/ текущей темы с той же структурой папок. Битрикс сам подхватывает локальную версию и не трогает её при обновлении. То же самое работает для шаблонов страниц и отдельных блоков инфоблоков.
Обработчики событий как основной инструмент
Там, где нужно поменять логику, а не вёрстку, я вешаю обработчик на нужное событие ядра в файле /local/php_interface/init.php, например строкой вида AddEventHandler("iblock", "OnBeforeIBlockElementUpdate", ["MyHandler", "onBeforeUpdate"]);. Так можно пересчитывать остатки при обновлении товара, блокировать сохранение элемента при нарушении бизнес-правила или отправлять уведомление в Telegram при смене статуса заказа, для последнего обычно достаточно вебхука из обработчика в бота на aiogram, без изменения самого Битрикса.
Плюс подхода: минимальный риск при обновлениях, ядро остаётся типовым, а правки лежат отдельно и легко находятся через git diff. Минус: логика расползается по десяткам обработчиков, и через год поддержки без документации в этом сложно разобраться. Я обычно собираю обработчики одного проекта в один класс с говорящими именами методов, а не раскидываю их анонимными функциями по init.php.
Свой модуль для Битрикса: когда без разработки с нуля не обойтись
Свой модуль оправдан, если функциональность достаточно объёмная, чтобы жить отдельно от логики конкретного проекта: свои таблицы в базе, административный интерфейс, API для внешних систем, переиспользование на нескольких сайтах.
Структура стандартная: папка вида mycompany.mymodule в /local/modules/, файл install/index.php с классом установки, который создаёт таблицы через install/db/mysql/, регистрирует обработчики событий и агенты. Дальше обычный PHP-код в подпапках lib и classes, оформленный по правилам автозагрузки Битрикса.
Из практики: если нужно синхронизировать каталог и заказы с внешней системой (1С, WMS, собственный склад) по сценарию сложнее прямого обмена CommerceML, свой модуль с REST-эндпоинтами и очередью на агентах Битрикса работает надёжнее набора разрозненных обработчиков. Для потоковой обработки заказов из нескольких источников одновременно часть логики я иногда выношу во внешний сценарий на n8n, который дёргает REST API Битрикса по расписанию: удобно, когда правила интеграции часто меняются и их проще держать в визуальном сценарии, чем каждый раз переписывать PHP.
Минус своего модуля: дороже и дольше на старте, нужно продумать структуру данных, обработку ошибок при установке и обновлении версии, обратную совместимость. Зато при следующем крупном обновлении Битрикса ломается меньше: модуль живёт в /local/modules/ и ядра не касается.
Сколько стоит и сколько занимает каждый вариант
Три подхода закрывают разные по объёму задачи, поэтому сравнивать их напрямую по одной шкале смысла мало, у каждого свой диапазон применения. Ниже, как они соотносятся по срокам и объёму работ на практике.
| Критерий | Модуль с маркетплейса | Доработка типового | Свой модуль |
|---|---|---|---|
| Срок запуска | 1-3 дня на установку и настройку | от нескольких дней до пары недель | от 2-3 недель |
| Что меняется | настройки в административной панели | локальные шаблоны и обработчики событий | новые таблицы, API, свой административный интерфейс |
| Риск при обновлении ядра | низкий, если разработчик работает через /local/ | низкий, правки лежат вне ядра | низкий, модуль независим от ядра |
| Когда оправдан | задача типовая, готовое решение уже есть на рынке | нужно донастроить 10-20% логики поверх типового функционала | нужна отдельная сущность со своей логикой и переиспользованием |
Такие задачи, разбор чужого модуля, обработчики событий, свой модуль с нуля, закрываю по услуге доработка и поддержка 1С-Битрикс, ставка от 3 000 ₽/час: почасовая модель подходит лучше фиксированной цены, потому что объём правок в существующем проекте заранее предсказать точно почти никогда нельзя.
Как выбрать подход под свою задачу
Коротко резюмирую, на что смотреть при выборе.
- Если задача типовая и есть готовое решение на маркетплейсе (эквайринг, доставка, популярная CRM), ставьте модуль и донастраивайте его: переписывать то, что уже работает у сотен сайтов, невыгодно.
- Если типовой функционал в целом устраивает, а нужно изменить 10-20% логики или вёрстки, берите доработку через /local/ и обработчики событий: дешевле и без риска для будущих обновлений.
- Если нужна отдельная сущность со своей логикой, таблицами и API, которую придётся поддерживать и расширять годами, пишите свой модуль. На дистанции это выходит дешевле, чем годами наращивать доработки поверх чужого кода.
- Если есть сомнения, какой вариант закроет задачу с наименьшими рисками, сначала оцените объём изменений на реальном проекте, а не в абстракции. Иногда доработка на словах на деле требует свой модуль.
1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Что будет с доработкой после обновления Битрикса?
Если правки сделаны через /local/ (локальные шаблоны, обработчики событий, отдельный модуль), обновление ядра их не трогает: Битрикс подгружает переопределения поверх типового кода. Ломается обычно то, что было исправлено прямо в файлах /bitrix/: такие правки при обновлении молча перезаписываются, поэтому я никогда не редактирую файлы ядра напрямую.
Можно ли совместить готовый модуль с доработкой?
Да, и на практике так происходит чаще всего. Ставится готовый модуль под типовую часть задачи, например эквайринг или доставку, а специфичную логику поверх него добавляют обработчиком события или локальным переопределением шаблона. Так объём собственного кода получается минимальным, а типовая часть остаётся на поддержке разработчика модуля.
Сколько стоит разработка своего модуля для Битрикса?
Фиксированной цены на разработку модуля назвать нельзя: слишком сильно она зависит от того, сколько сущностей, таблиц и внешних интеграций нужно закрыть. Такие задачи, как и доработку типового функционала, я веду по ставке от 3 000 ₽/час, а перед стартом оцениваю объём работ на конкретном техническом задании.
Как понять, что пора переходить от доработки к своему модулю?
Если обработчиков событий и локальных переопределений в проекте становится больше десятка и они начинают завязываться друг на друга, это сигнал: логика уже достаточно сложная, чтобы жить в отдельном модуле со своей структурой, а не размазываться по init.php. Второй сигнал: когда одну и ту же доработку нужно поставить на несколько сайтов, модуль с нормальной установкой переносится быстрее, чем копирование обработчиков вручную.