Как удалить модуль 1С-Битрикс

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

Штатный механизм удаления предусмотрен в административном разделе и выполняет деинсталляцию корректно: модуль сам убирает свои таблицы, агенты и обработчики событий. Проблемы возникают обычно в двух случаях — когда модуль удалён частично вручную и админка стала недоступна, либо когда модуль сторонний и его деинсталлятор написан некачественно.

Ниже разобраны оба сценария: штатное удаление через панель управления и аварийное удаление, когда стандартный путь недоступен. Отдельно описано, как проверить, что модуль удалён полностью, и что делать с «хвостами» в базе данных.

Подготовка: что сделать до удаления

Первый и обязательный шаг — полная резервная копия. Нужны и файлы сайта, и дамп базы данных, потому что деинсталлятор модуля удаляет данные безвозвратно. Бэкап можно сделать штатным средством Битрикса («Настройки → Инструменты → Резервное копирование») или внешними инструментами: архив файлов через панель хостинга и экспорт базы через mysqldump или phpMyAdmin.

Второй шаг — проверить зависимости. Многие модули связаны между собой: например, интернет-магазин зависит от торгового каталога, а решения из Marketplace — от модулей, для которых они разработаны. Если удалить базовый модуль, зависимые перестанут работать. Список зависимостей виден в карточке модуля и в описании решения на Marketplace.

Третий шаг — определить, где используется модуль: компоненты на страницах, шаблоны, агенты, почтовые события, обработчики в init.php. Если модуль встроен в бизнес-процессы, его удаление сломает соответствующие страницы. Полезно заранее выписать, что придётся убрать или заменить после деинсталляции.

Штатное удаление через административный раздел

Стандартный путь подходит для любого корректно установленного модуля — и стороннего, и входящего в дистрибутив. Порядок действий одинаковый.

1. 1
   Войдите в административный раздел с правами администратора
2. 2
   Откройте «Настройки → Настройки продукта → Модули»
3. 3
   Найдите нужный модуль в списке и выберите действие «Удалить»
4. 4
   На шаге деинсталляции отметьте опции удаления таблиц и данных, если они предлагаются
5. 5
   Подтвердите операцию и дождитесь сообщения об успешном удалении
6. 6
   Проверьте, что модуль исчез из списка, а его папка — из /bitrix/modules/ или /local/modules/

На шаге деинсталляции многие модули задают вопросы: удалять ли таблицы, сохранить ли данные, убрать ли настройки. Если модуль удаляется окончательно, данные обычно тоже удаляют — иначе в базе останутся «мёртвые» таблицы. Если удаление временное (например, для переустановки), данные можно сохранить, отметив соответствующую опцию.

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

Удаление сторонних модулей из Marketplace

Решения из Marketplace удаляются тем же способом через список модулей, но у них чаще встречаются особенности. Во-первых, сторонний деинсталлятор может не удалять данные полностью — разработчики иногда оставляют таблицы и папки с загруженными файлами, чтобы при переустановке информация сохранилась.

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

В-третьих, проверьте лицензионные привязки: некоторые платные решения регистрируют установку на домене. Если планируется переустановка модуля позже, уточните в документации разработчика, как корректно освободить лицензию.

Аварийное удаление, когда админка недоступна

Бывает, что модуль удалён частично или содержит фатальную ошибку, и административный раздел не открывается. В этом случае порядок действий другой: сначала восстановить работоспособность, потом удалять штатно.

Если сайт падает с ошибкой вида «Class not found» или «Table doesn't exist» с упоминанием конкретного модуля, временно отключите его загрузку. Для этого переименуйте папку модуля в /bitrix/modules/ или /local/modules/ — например, добавьте к имени суффикс _off. Это не удаление, а способ остановить автозагрузку классов и получить доступ к админке.

Однако если модуль числится установленным в базе, ядро продолжит вызывать его обработчики событий и агенты. Поэтому следующий шаг — убрать регистрацию модуля в базе данных: в таблице b_module найти запись с ID модуля. Аккуратный вариант — выполнить SQL-запрос на удаление только этой строки, предварительно сделав дамп таблицы.

-- Сначала проверьте запись
SELECT * FROM b_module WHERE ID = 'vendor.module';
-- Затем удалите только её
DELETE FROM b_module WHERE ID = 'vendor.module';

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

Что почистить после удаления

Даже корректная деинсталляция не всегда убирает всё. Проверьте типичные места, где остаются следы модуля, и уберите их вручную при необходимости.

• Папки модуля: /bitrix/modules/идентификатор и /local/modules/идентификатор — после удаления их быть не должно.
• Таблицы в базе данных с префиксом модуля — сверьте список таблиц до и после деинсталляции.
• Агенты: «Настройки → Инструменты → Агенты» — уберите записи, ссылающиеся на классы удалённого модуля.
• Обработчики событий в файле /bitrix/php_interface/init.php или /local/php_interface/init.php — вызовы AddEventHandler для удалённого модуля дадут фатальную ошибку.
• Компоненты и их вызовы на страницах сайта, шаблоны компонентов в /local/templates/.
• Почтовые события и шаблоны писем, созданные модулем.
• Загруженные файлы в /upload/, если модуль хранил там данные.

Особое внимание уделите init.php: это самая частая причина «белого экрана» после удаления модуля. Любой вызов класса или регистрация обработчика несуществующего модуля останавливает выполнение всего сайта. Закомментируйте или удалите такие строки и проверьте работу публичной части.

Проверка результата

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

Если на каком-то шаге обнаружена проблема, не пытайтесь «дожать» удаление повторными действиями. Надёжнее восстановить состояние из резервной копии и повторить процедуру по шагам, устранив причину сбоя.

Частые вопросы