Updating 1C-Bitrix modules

1C-Bitrix Module Updates

Core updates and module updates are different operations with different risks. The core updates rarely and requires careful testing. Modules update more frequently and are theoretically safer. In practice, updating the sale or catalog module breaks the cart at the worst moment—because someone hooked an event handler to an internal method that changed.

How Module Updates Work

In Bitrix, each module is a directory in /bitrix/modules/{module_name}/. Module update replaces files in this directory. Script install/updater.php (or install/db/mysql/update_{version}.php) executes during update and makes database changes.

Update a module two ways:

• Via admin panel: Settings → System Updates → "Module Updates" section
• Via console: php -f /bitrix/bin/console module.update --module=catalog

Console method is preferable on production: no PHP script time limits, no browser state dependency.

Standard High-Risk Modules During Update

sale (online store). One of the most frequently updated and riskiest modules. Update may change: discount calculation logic, order creation event call order, CSaleOrder::Add() behavior in edge cases. Any custom code using events OnSaleOrderBeforeSaved, OnBeforeSaleOrderAdd, OnSaleBasketItemAdd—potential problem source.

catalog (product catalog). Changes in price application logic, faceted indexing, trade offer handling. If custom price provider is implemented—check interface compatibility.

iblock (infoblocks). Usually backward compatible, but changes in fetch methods sometimes affect caching and performance.

main (main module). Updates synchronously with core. Changes in auth logic, file handling, ORM—all here.

Marketplace Modules

Third-party Marketplace modules update independently from core. Problems arise when:

• Developer released update with breaking change without documenting
• Module hasn't been updated long and loses compatibility with core update
• Multiple modules listen to same event and handler order changes after one updates

Before updating third-party module—read changelog in Marketplace. If changelog is absent or brief—red flag.

Safe Module Update Procedure

For production with non-zero traffic, mandatory order:

1. Backup database and module files (/bitrix/modules/{name}/)
2. Staging—reproduce update on production copy
3. Test critical scenarios on staging: order checkout, add to cart, apply discounts, auth—depending on which module updated
4. Check error log: tail -f /var/log/php_errors.log or Bitrix log—/bitrix/admin/event_log.php
5. Update production during quiet time (night, minimal traffic), in maintenance mode

Module Rollback on Problems

If module update broke something critical—rollback:

1. Stop website (maintenance mode)
2. Restore module files from backup
3. If update script changed database—restore from DB dump (made before update)
4. Check website works

Rolling back database changes without dump—nearly impossible: updater.php scripts rarely include rollback logic. That's why DB backup before update—not recommendation but mandatory.

Automatic Updates

Bitrix provides scheduled automatic updates option. On production sites with custom code not recommended. Auto-update acceptable only on sites without custom event handlers, without modified components, and only with monitoring configured—to catch problems immediately.

Timeframes