Как обновить 1С-Битрикс: ядро, модули и обмен с 1С без сюрпризов

Как обновить 1С-Битрикс: что проверить до старта

Когда к нам приходят с задачей «обновите Битрикс», первое, что мы делаем — не жмём кнопку «Обновить», а прогоняем проект по чеклисту. Причина простая: система обновлений производит технически сложную серьёзную модификацию ядра продукта, а не аккуратную замену пары файлов. Обновление трогает и старое ядро, и D7 — оба работают параллельно, и оба файла настроек используются одновременно. Если на проекте есть сторонние модули, кастомные компоненты или правки в ядре, любое обновление главного модуля может задеть их косвенно.

Особенно осторожно мы работаем с магазинами, где большой каталог и активный обмен с 1С. Там обновление — это не только код, но и данные: обмен идёт через CommerceML, узел обмена настроен, выгрузка заказов и товаров работает по расписанию. Обновление модуля обмена или главного модуля в такой момент может сломать синхронизацию — и вы узнаете об этом не по ошибке в логе, а по тому, что на сайте перестали появляться новые товары. В проектах с ручными SEO-полями и торговыми предложениями мы всегда сначала проверяем, как обновление повлияет на обмен, и только потом запускаем установку.

Ниже — предстартовый чеклист, который мы проходим до запуска обновления.

• Адрес сервера обновлений — проверьте, что в глобальных настройках главного модуля указан www.1c-bitrix.ru или dev.1c-bitrix.ru, а не зеркало или старый адрес.
• Полный бекап — дамп базы данных и снапшот диска (или виртуальной машины), а не только файлы сайта.
• Права install_updates — убедитесь, что у вашей учётной записи администратора есть операция установки обновлений в уровнях доступа.
• Версия PHP — сверьте её с требованиями обновляемых модулей; на PHP 8.x часть модулей может требовать предварительного обновления.
• Оба файла настроек — держите под рукой оба файла настроек ядра: старое и D7 используются одновременно, и правки в них вносятся параллельно.

Где задать сервер обновлений и почему там должен быть www.1c-bitrix.ru

Адрес сервера обновлений задаётся на странице глобальных настроек главного модуля. Оттуда система обновлений получает информацию о доступных версиях и сами пакеты. По умолчанию там стоит www.1c-bitrix.ru; для тестирования альфа-версий используется dev.1c-bitrix.ru. В наших проектах мы всегда проверяем это поле перед обновлением: иногда его меняют под задачи тестирования и забывают вернуть обратно.

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

Обновление 1С-Битрикс: как выбрать модули и остановить установку

Заходим на страницу обновлений, жмём «Установить», смотрим на прогресс-бар. Он идёт и идёт: десятки модулей, у каждого своя цепочка версий. И тут возникает резонный вопрос: что вообще происходит в этом процессе и можно ли его контролировать?

Устроен процесс так: обновления ставятся друг за другом в строгом соответствии с версией. Каждое обновление содержит лишь изменение по сравнению с предыдущим — это не «пакет до последней версии», а последовательность шагов. Если у вас модуль версии 20.0.100, а последняя — 22.5.0, система не перескочит сразу на 22.5.0: она проставит все промежуточные релизы по очереди, от 20.0.101 до 22.5.0. Именно поэтому обновление ядра — технически сложная и серьёзная модификация, а не мгновенная операция. Чем дальше проект отстал от текущей версии, тем длиннее цепочка и тем выше шанс, что на каком-то шаге что-то пойдёт не так. Понимание этой механики даёт читателю контроль: вместо «нажал и молюсь» появляется возможность выбрать, что именно обновлять, до какой версии и в каком порядке. Комбинируется это с бэкапом (о котором мы говорили в предыдущей секции) и с проверкой прав на установку обновлений: без нужной операции кнопки просто не будет.

Как выбрать модули и указать версию, до которой обновлять

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

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

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

Что делает кнопка «Остановить установку» и когда её жать

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

Жать её стоит в нескольких случаях. Первый — когда в логе видно ошибку на конкретном модуле и вы не хотите, чтобы система шла дальше и множила проблемы. Второй — когда обновление идёт подозрительно долго и вы понимаете, что на проде сейчас час пик. Третий — когда вы осознали, что случайно выбрали не тот набор модулей.

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

Обновить Битрикс и 1С: как настроить авто-проверку обновлений и права

Многие считают, что система обновлений — это только кнопка «Установить» на странице обновлений. в истории версий главного модуля появились настройки ядра, которые определяют, как часто проект сам проверяет наличие обновлений и что делать, если проверка спотыкается. Для проектов с активным обменом с 1С это критично: модуль обмена (версии 6.5 и выше) развивается вместе с ядром, и пропущенное обновление главного модуля легко превращается в несовместимость при следующем импорте CommerceML.

Речь о двух опциях главного модуля: «Автоматически проверять наличие обновлений» и «Остановить автоматическую проверку при возникновении ошибок». Первая включает фоновую проверку на сервере обновлений, вторая — глушит её, если что-то пошло не так. В проектах, где обмен с 1С идёт по расписанию, а админкой пользуются несколько человек, эти настройки стоит выставить осознанно, а не оставлять по умолчанию.

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

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

Кому выдать операцию install_updates

В уровнях доступа добавлена операция install_updates (установка обновлений). Соблазн выдать её всем администраторам понятен, но неправильный. Обновление ядра — это серьёзная модификация продукта, и право на неё лучше держать у одного-двух человек, отвечающих за релизный цикл.

Логика простая: контент-менеджеру, менеджеру по заказам, интегратору обмена с 1С эта операция не нужна. Она нужна тому, кто тестирует обновление на копии, делает бекап и только потом ставит его на прод. Если право размазано по всем администраторам, кто-то однажды нажмёт «Установить» в момент активного обмена — и получит несовместимость на живом проекте.

Обновление модуля обмена 1С: версия 6.5, узел обмена и CommerceML

Самый частый запрос на эту тему звучит так: «у нас 1С, товары выгружаются, но заказы не уходят обратно — что не так?». Почти всегда дело в модуле обмена: он либо не установлен, либо версия ниже 6.5. Для интеграции с 1С нужно скачать и установить модуль обмена версии 6.5 или выше и настроить узел обмена документами. Без этого обмен односторонний: каталог на сайт приезжает, а заказы в 1С не возвращаются.

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

Что это значит на практике для каталога от 20 000 SKU? Разница чувствуется в трёх местах:

• выгрузка идёт пакетами, а не одной портянкой XML — большие каталоги не роняют сессию по таймауту;
• заказы возвращаются в 1С с настройкой полей экспорта под каждый тип плательщика — юрлицо и физлицо получают разный набор реквизитов;
• узел обмена можно переключать между режимами, не пересобирая всю интеграцию с нуля.

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

Что даёт CommerceML 2.0 и зачем оставили поддержку 1.0

Обмен данными идёт по открытому стандарту на основе XML — CommerceML 2.0. Это текущая версия, на ней работает модуль обмена 6.5 и выше: структура каталога, торговые предложения, цены, остатки, заказы.

Но «1С:Предприятие» версии 7.7 поддерживает выгрузку товаров в формате CommerceML 1.0. И загрузка каталога на сайт из XML-файла версии 1.0 по-прежнему осуществляется. Поэтому поддержку старого формата не выпилили — она нужна проектам, которые так и не перешли с семёрки.

Если у вас 1С 8.x — работайте со второй версией и не оглядывайтесь на первую. Если на стороне клиента всё ещё живёт 7.7 — обмен через 1.0 рабочий, но это заведомо более узкий набор данных.

Как активировать обмен документами (заказами)

Чтобы заказы пошли в 1С, недостаточно настроить выгрузку каталога. Для обмена документами (заказами) в форме настроек параметров обмена должны быть выполнены основные настройки узла и отмечена опция «Активировать обмен документами» на закладке «Режим обмена данными».

Дальше — на закладке «Профили обмена». Здесь для каждого типа плательщика настраиваются поля экспорта заказов, которые будут переданы в 1С. Это и есть та причина, по которой один и тот же заказ уходит в 1С с разным набором реквизитов в зависимости от того, оформлен он на юрлицо или на физлицо.

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

1С-Битрикс обновление: два ядра, два файла настроек и mbstring.func_overload

Есть в Битриксе особенность, которая ломает обновление чаще, чем сами обновления: платформа одновременно работает на двух ядрах — старом и D7. Старое ядро живёт с первых версий продукта и никуда не делось, D7 пришёл ему на смену, но не заменил полностью. В итоге на одном проекте соседствуют два набора классов, два стиля API и — что важнее всего для обновления — два файла настроек, которые читаются параллельно. Когда мы запускаем обновление на проекте, где разработчики годами правили только один файл, вторая половина конфигурации остаётся нетронутой, и после апдейта «вдруг» отваливается то, что раньше работало стабильно.

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

Почему нужно настраивать оба файла настроек

В системе параллельно используются старое ядро и D7, поэтому оба файла настроек применяются одновременно. Это официальная позиция разработчиков платформы, и она снимает главный вопрос: «зачем трогать второй файл, если я пишу только на старом ядре?» Ответ простой — используется код только старого ядра, но система всё равно читает оба файла. Часть параметров, влияющих на работу старого ядра, физически лежит в настройках D7, и наоборот.

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

Отсюда рабочее правило: перед обновлением проверяем оба файла, после обновления — тоже. Даже если проект целиком написан на старом ядре и мигрировать на D7 никто не собирается.

mbstring.func_overload: почему его нужно удалить с версии main 20.100.0

Отдельная история — параметр PHP mbstring.func_overload. С версии 20.100.0 главного модуля (main) требуется его удаление: опция более не требуется и не поддерживается платформой. Это не рекомендация, а требование, и оно напрямую связано с тем, как ядро работает со строками.

Параметр может быть прописан в нескольких местах, и его нужно найти и убрать везде:

• на хостинге — в .htaccess, если провайдер разрешает задавать опции PHP через него;
• на собственном сервере — в httpd.conf (для Apache) или в php.ini.

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

Ошибка после обновления PHP до 8.х: как откатиться и что обновить

Классическая ситуация: администратор поднял версию PHP на сервере до 8.х, открыл сайт — и получил белый экран или фатал в логе. Обновления Битрикса при этом не ставились. По нашему опыту, это самый частый сценарий «ошибки после обновления PHP»: версию интерпретатора подняли раньше, чем систему. Платформа и сторонние модули остались на коде, который писался под PHP 7.x, и часть вызовов в новых версиях языка просто перестала существовать.

Почему порядок «сначала PHP, потом Битрикс» неверный? Потому что система обновлений и само ядро тоже должны уметь работать на новом интерпретаторе. Если поднять PHP первым, вы лишаете себя возможности спокойно поставить обновления через административный интерфейс: страница обновлений сама может упасть с фаталом. Правильный порядок обратный: сначала обновляем ядро и модули на текущей рабочей версии PHP, убеждаемся, что всё стабильно, и только потом переключаем интерпретатор. Именно поэтому в наших проектах смена версии PHP — отдельный этап, а не «побочный эффект» переезда на новый сервер.

Основные действия по исправлению, если ошибка уже случилась:

• Вернуться на предыдущую версию PHP 7.x, на которой сайт работал стабильно.
• Обновить компоненты системы и сторонние модули до актуальных версий.
• Повторно переключить PHP на 8.х и проверить работу сайта и админки.

Как понять, что дело именно в несовместимости с PHP 8.x

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

Полезно сразу проверить версию продукта — от неё зависит, насколько глубоко придётся обновлять ядро. Версию 1С-Битрикс можно посмотреть в файле /bitrix/modules/main/classes/general/version.php (по обсуждениям на форуме файл иногда отсутствует — тогда ориентируйтесь на данные в админке). Если версия старая, часть модулей придётся обновлять последовательно, друг за другом.

Отличить несовместимость с PHP от проблемы самого обновления Битрикса помогает простой тест: откатите PHP на 7.x. Если ошибка исчезла — дело было в интерпретаторе. Если осталась — копайте в сторону конкретного обновления модуля или ядра.

Типичные симптомы несовместимости с PHP 8.x выглядят так. Фаталы в старом ядре — код, который писался под PHP 5/7, использует конструкции, удалённые в восьмёрке. Deprecation-предупреждения — они не роняют сайт, но засоряют лог и могут скрывать реальные проблемы. Отвал компонентов — отдельные страницы или блоки перестают отдавать контент, при этом остальной сайт работает. Ещё один маркер — ошибки в сторонних модулях, которые давно не обновлялись: их авторы могли не выпустить совместимую версию, и тогда модуль придётся либо обновить, либо временно отключить.

Важно не путать это с последствиями самого обновления Битрикса. Там симптомы другие: меняется поведение конкретных компонентов, ломаются настройки, но фаталов «на пустом месте» обычно нет. Если же вы видите именно фаталы и deprecation-предупреждения сразу после смены PHP — это классическая картина несовместимости.

Как обновить локальную виртуальную машину 1С-Битрикс

У большинства команд, которые ведут проекты на 1С-Битрикс, есть локальная копия продукта — та самая «Виртуальная машина» (Bitrix VM), которую ставят на ноутбук или тестовый сервер в офисе. От боевого сервера она отличается принципиально: обновление здесь идёт не через админку Битрикса, а через административное меню самой виртуальной машины. Вы не заходите в /bitrix/admin/update_system.php и не жмёте «Установить» — работа идёт с консольным меню VM, где обновление ядра вынесено в отдельный пункт.

У нас в практике локальная VM закрывает две задачи. Первая — полигон для обновлений: здесь можно спокойно поставить свежие модули и посмотреть, что отвалится, не рискуя продом. Вторая — песочница для обмена с 1С: на локальной машине удобно эмулировать выгрузку каталога и заказов, поймать ошибку в CommerceML или в настройках узла обмена и только потом трогать рабочую систему. Поэтому держать её в актуальном состоянии — не формальность: если локальная VM отстала на несколько версий ядра, тестировать на ней обновление прода просто бессмысленно.

Дальше — короткая последовательность, которую мы прогоняем каждый раз.

1. Сделать полный бекап виртуальной машины перед запуском обновления. Это первое, что рекомендуют в документации, и мы это правило не обходим: снимаем снапшот целиком, а не только базу, потому что обновление затрагивает и системные пакеты VM, и файлы ядра.
2. В административном меню самой виртуальной машины выбрать пункт 2. Configure localhost settings. Это вход в настройки локального сервера, откуда дальше идёт переход к обновлению.
3. Перейти в раздел 6. Update server и согласиться на обновление. Меню само подтянет доступные пакеты и предложит подтвердить установку — соглашаемся и запускаем.
4. Дождаться завершения процесса и проверить, что сайт поднимается, а обмен с 1С работает. Открываем локальный сайт, смотрим логи, прогоняем тестовую выгрузку каталога и заказов — чтобы убедиться, что обновление ничего не сломало.

Свои модули и партнёрская система обновлений: код партнёра и лицензионный ключ

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

Задача всплывает в двух случаях. Первый — когда студия выпускает собственный модуль и хочет распространять его через маркетплейс 1С-Битрикс. Второй — когда проект уже использует модуль стороннего партнёра, и нужно получить доступ к обновлениям, в том числе к тестовым сборкам. В обоих случаях ключевые поля одни и те же: Код партнёра и Лицензионный ключ. Разберём, что именно в них вписывать и как это связано с именованием классов модуля.

В карточке партнёра два обязательных поля, и путать их не стоит — они отвечают за разные вещи.

Код партнёра используется как код для собственных модулей. Именно по нему система понимает, что модуль принадлежит этому партнёру, и связывает обновления с автором. Если код указан неверно или отсутствует, обновления собственного модуля через партнёрскую систему не придут.

Лицензионный ключ используется для тестирования альфа-версий обновлений. Альфа-версии доступны только автору модуля по этому ключу — то есть до публичного релиза новую сборку видит лишь тот, кто её выпустил. Это удобный способ проверить обновление до того, как оно уйдёт всем пользователям модуля.

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

Как формируется имя класса модуля

Название класса модуля формируется аналогично ID модуля, только точка заменяется на подчёркивание. Если ID модуля — alexey.mycar, то класс будет alexey_mycar. Это правило работает без исключений: точка в ID — разделитель между вендором и именем модуля, а в PHP-классе точка недопустима, поэтому её заменяют подчёркиванием.

Частая ошибка при регистрации своего модуля — писать класс с точкой или с заглавными буквами «по аналогии с названием». Система такой класс не найдёт, и модуль либо не установится, либо не будет корректно обновляться. Проверяйте соответствие ID и имени класса ещё на этапе разработки: vendor.module → vendor_module, и ничего больше.

Тестирование обновления перед выпуском на прод

«Настоятельно рекомендуется при каждом выпуске обновления эмулировать самые различные ситуации для тестирования» — эту формулировку из документации мы цитируем в каждом внутреннем регламенте. И не потому, что так написано в инструкции, а потому что регулярно видим, как обновление, спокойно вставшее на dev-стенде, роняет прод в первый же час. Причина простая: тестовый контур у многих команд — чистый дистрибутив «последней версии», на котором проверили только сам факт установки. А прод — каталог на десятки тысяч SKU, живой обмен с 1С, три кастомных модуля и шаблон, который не обновлялся с прошлого релиза.

Когда к нам приходит задача «обновить ядро и модули без простоя», мы первым делом договариваемся именно о тестовом контуре. Без стенда, повторяющего прод, обновление превращается в лотерею, где приз — ночной разбор инцидента. Ниже — что именно эмулируем и как организуем контур.

• Чистый дистрибутив — базовая проверка: обновление должно вставать на пустую установку без ошибок и предупреждений.
• Проект с каталогом от 20 000 SKU — проверяем, как обновление переживает объём: переиндексация, поиск, выгрузки.
• Активный обмен с 1С — узел обмена, CommerceML, выгрузка заказов и товаров, чтобы не поймать конфликт версий модуля обмена.
• Кастомные модули — свои доработки, которые мы вынесли в отдельный модуль, а не в ядро: проверяем совместимость с обновлёнными классами.
• Старый шаблон и компоненты — если шаблон не обновлялся вместе с ядром, именно там чаще всего всплывают несовместимости.

Схема у нас отработана и занимает предсказуемое время: снимаем снапшот прода (файлы + база, включая таблицы обмена), разворачиваем его на отдельном стенде с той же версией PHP и той же конфигурацией сервера. Дальше прогоняем обмен с 1С: сначала полную выгрузку, потом обмен заказами в обе стороны. Так убеждаемся, что узел обмена и CommerceML работают на обновлённой версии модуля так же, как раньше.

И тут важный момент: не пропускать этап обмена. Многие команды тестируют только фронт и админку, а обмен с 1С оставляют «на потом» — и именно там обновление ломается чаще всего. Модуль обмена версии 6.5 и выше чувствителен к версии ядра, а кастомные обработчики узла обмена могут перестать получать события. Если на стенде обмен прошёл — фиксируем результат: какие модули обновились, какие версии встали, что в логах, какие ошибки вылезли и как их закрыли. Эту фиксацию прикладываем к задаче на прод. Она экономит часы, если что-то всё же пойдёт не так.

Самые частые ошибки при обновлении 1С-Битрикс

Сколько раз вы видели, как после нажатия «Установить» сайт уходит в белый экран, а в логах — фатал на строке, которую вчера никто не трогал? За годы работы с 1С-Битрикс мы собрали набор грабель, которые всплывают в проектах снова и снова. Размер каталога и отрасль тут ни при чём. Одни ломают обмен с 1С, другие роняют админку, третьи обнаруживаются только когда клиент звонит «сайт не работает».

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

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