1C-Bitrix Core Version Update
Bitrix core updates break websites more often than admitted. Not because the core is bad, but because most custom code is written violating the principle "don't touch the core": edits in bitrix/modules/, direct calls to deprecated functions, dependence on internal component structure. Updates expose this debt.
What Exactly Gets Updated
The Bitrix core is the /bitrix/ directory on the server. When updating via built-in mechanism (/bitrix/admin/update_system_partner.php), the system:
- Downloads update package from Bitrix servers
- Unpacks in
/bitrix/updates/ - Executes update PHP scripts that change the database and filesystem
- Replaces core and module files
Your code in local/ is untouched. Your templates in local/templates/—untouched. Files in /bitrix/—replaced.
What Breaks After Update
Direct core file edits. bitrix/modules/catalog/install/components/bitrix/catalog.element/templates/.default/template.php—manually edited. After update—overwritten with original. Anything inside /bitrix/ that was changed—lost.
Deprecated functions. Every few versions Bitrix deprecates functions and eventually removes them. Calling CIBlockElement::GetList() with wrong parameters in version 22.x may behave differently than in 18.x. Calling a removed method—Fatal Error.
Module API changes. The sale module was significantly reworked in versions 17.x and later: old API (CSaleOrder::Add) coexists with new (Bitrix\Sale\Order), but edge-case behavior may differ.
Custom Marketplace modules. If module developer hasn't updated it for new core version—after update the module may not work.
Correct Update Order
Step 1: Staging. Production site copy on test server. Update done only here. Without staging, updating production is Russian roulette.
# Minimal staging environment checklist:
- Full site file copy
- Database dump
- Identical PHP version
- External integrations disabled (don't send customer emails, don't sync with 1C)
Step 2: Custom code audit. Before update, check:
- Any edits inside
/bitrix/(viagit diffif repository exists, orfind /bitrix -newer /bitrix/bitrix_version.php -type f) - Are deprecated functions called (grep codebase for
local/) - Are Marketplace modules compatible with target version—check module page in store
Step 3: Staging update. Run update via admin panel or console tool /bitrix/bin/console update. On large sites, console update is preferable—no PHP execution time limit.
Step 4: Testing. Go through critical scenarios: homepage, catalog, product card, cart, checkout, personal account, admin interface. Check PHP error log for new errors.
Step 5: Production update. After successful staging test. In maintenance mode (503 page) during update. After—check error log again.
Special Considerations for Multi-Major-Version Updates
If lag is 2+ years—can't update straight to latest. Path: 18.x → 20.x → 22.x → current. Each intermediate step—separate testing. Can't skip intermediate versions: database update scripts execute sequentially.
Timeframes
| Situation | Timeframe |
|---|---|
| Regular update (lag up to 3 months) | 1-2 days |
| Update after 6-12 months downtime | 3-5 days |
| Update with 1.5-2 year lag | 1-2 weeks |
| Update with 3+ year lag + custom code | 2-4 weeks |
Main variable—volume of custom code needing adaptation. Site on standard components with code in local/ updates easier than site with core edits and five-year-old custom modules.