Исправление ошибок после обновления или переноса 1С-Битрикс

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

После апдейта чаще всего срабатывает несовместимость версий. Новое ядро Битрикса требует более свежего PHP, а старый кастомный модуль или сторонний компонент написан под предыдущую версию языка и падает с фатальной ошибкой. Или, наоборот, на сервере обновили PHP, а часть кода использует функции, которые в новой версии удалены. Сюда же относятся конфликты между модулями, изменения в API ядра, по которым перестают работать старые обработчики, и правки, ранее внесённые прямо в ядро — при обновлении они затираются, и логика рушится. Мы находим точку конфликта по логам и версиям и приводим код к совместимому состоянию, не ломая остальное.

Что обычно ломается после переезда на новый сервер

Перенос на новый хостинг добавляет свой набор проблем, завязанных на окружение. Сайт переехал, но в файле .settings.php остались старые реквизиты подключения к базе данных или путь к кешу указывает на каталог, которого на новом сервере нет. Абсолютные пути, прописанные в коде или настройках, перестают совпадать с новым DocumentRoot. Файл .htaccess или конфигурация веб-сервера не перенесены, из-за чего ломается человекопонятный URL и сыплются ошибки 404. Права на файлы и каталоги выставлены так, что Битрикс не может писать в кеш или загружать файлы. Каждая из этих мелочей по отдельности роняет сайт целиком.

Самые частые источники сбоев после обновления и переноса:

• несовместимость версий ядра, модулей, PHP и расширений сервера;
• поломка шаблона и компонентов, отвал подключения CSS и JS, съехавшая вёрстка;
• битые абсолютные пути, неверный DocumentRoot, отсутствующий .htaccess и ошибки 500 и 404;
• потеря настроек модулей, разделов, форм и прав доступа после миграции;
• неверная конфигурация .settings.php — подключение к базе, домен, хранилище кеша;
• остановка обмена с 1С: сбитые пути, домен и доступы профиля выгрузки.

Кеш, права и .settings.php — тихие причины сбоев

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

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

Обмен с 1С после переноса

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

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

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

Почему нельзя чинить сайт наугад

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

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

Откат против доработки: когда что выбрать

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

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

Когда проще перенести заново

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

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

Типовые ошибки и их настоящие причины

За одинаковыми с виду симптомами стоят разные корни. Белый экран после обновления — почти всегда фатальная ошибка PHP: несовместимый модуль, удалённая функция языка, нехватка памяти. Массовые ошибки 500 после переезда — чаще конфигурация: неверный .settings.php, отсутствующий .htaccess, недостаточные права. Ошибки 404 по человекопонятным адресам — не перенесённые правила маршрутизации. Съехавшая вёрстка — отвал подключения CSS и JS из-за смены путей или версии шаблона. Старые данные на сайте — кеш, указывающий на прошлое окружение. Остановка обмена с 1С — сбитые домен, пути и доступы профиля выгрузки. Зная эту карту соответствий, мы не гадаем, а проверяем гипотезы по очереди, начиная с самой вероятной.

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

Почему мы не правим ядро даже в аврале

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

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

Как проходит работа по шагам

Первый шаг — приём заявки и снятие бэкапа: фиксируем текущее состояние файлов и базы, чтобы любой откат был возможен. Второй — диагностика: включаем вывод ошибок на копии, читаем логи веб-сервера и PHP, сверяем версии ядра, модулей и PHP, изучаем историю обновления или переноса. Третий — согласование: показываем найденную причину, оценку времени и план, выбираем между откатом, доработкой и повторным переносом. Четвёртый — исправление: чиним несовместимости, восстанавливаем шаблоны и компоненты, правим пути и права, выверяем .settings.php, чистим и пересобираем кеш, переподключаем обмен с 1С. Пятый — проверка и сдача: прогоняем ключевые сценарии и фиксируем результат.

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

Гарантии, сроки и защита от повторного сбоя

На выполненные правки мы даём гарантию: если в её рамках всплывает связанная проблема, устраняем без дополнительной оплаты. Аварийные заявки берём в работу от тридцати минут до реакции и в режиме 24/7, потому что понимаем цену простоя для интернет-магазина или оптового сайта. Типовую ошибку после апдейта обычно закрываем в день обращения, сложный перенос с восстановлением путей, прав и обмена занимает один-два дня. Точные сроки называем после бесплатной диагностики, когда видим реальную причину, а не по телефону наугад.

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

Что мы проверяем в окружении нового сервера

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

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

Восстановление после неудачного самостоятельного апдейта

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

Если обновление прервалось из-за нехватки ресурсов сервера — закончилась память или превышено время выполнения — мы сначала чиним причину в окружении, а потом повторяем апдейт. Иначе обновление снова упадёт в той же точке. Такой системный взгляд отличает восстановление от попыток просто перезапустить процесс в надежде, что в этот раз пронесёт. Мы устраняем корень, чтобы апдейт прошёл до конца и больше не обрывался.

С чего начать

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