Исправление ошибок на сайте

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

В таких задачах важно не просто “погасить симптом”, а понять причину. Одна сломанная кнопка может быть связана с JavaScript, шаблоном компонента, кешем, правами доступа, почтовым событием, обработчиком формы, настройками сервера или внешней интеграцией.

С какими ошибками можно обратиться

Чаще всего ко мне приходят с уже заметной проблемой: пользователь не может отправить заявку, менеджер не получает письмо, корзина ведет себя странно, страница отдаёт ошибку, после правки поехал адаптив или поисковик видит не ту версию URL. Я начинаю с диагностики цепочки, а не с угадывания “где поправить одну строку”.

• Формы и заявки: не приходят письма, не сохраняются обращения, не работает валидация, дублируются заявки, CRM получает неполные данные.
• Верстка и интерфейс: блоки съехали на мобильном, не открывается меню, не работает слайдер, кнопка или всплывающее окно.
• Каталог и карточки: не выводятся товары, свойства, цены, фильтры, изображения, торговые предложения или SEO-поля.
• Оплата и заказы: деньги прошли, а заказ не стал оплаченным; callback не доходит; статус меняется неправильно.
• PHP/JS ошибки: белый экран, 500, warnings/notices, конфликт старого скрипта, ошибка после обновления PHP или модуля.
• SEO-техника: неправильный canonical, дубли Open Graph, 404, лишние редиректы, страница выпала из sitemap или индекса.

Как проходит исправление

1. Фиксирую симптом: URL, устройство, браузер, время ошибки, что должно происходить и что происходит сейчас.
2. Проверяю публичную часть: код ответа, HTML, консоль браузера, сетевые запросы, отправку формы или нужный пользовательский сценарий.
3. Смотрю Bitrix-часть: компонент, шаблон, инфоблоки, почтовые события, обработчики, кеш, логи и зависимости от внешних сервисов.
4. Перед рискованной правкой делаю резервную копию затронутых файлов или фиксирую изменения через Git, если он есть на проекте.
5. После исправления проверяю не только место ошибки, но и соседние сценарии: адаптив, форму, письма, заявку в CRM, статус заказа или SEO-сигналы.

Почему важно искать причину, а не только симптом

Если форма не отправляет письмо, проблема может быть в шаблоне, почтовом событии, SMTP, антиспаме, обработчике, CRM или серверной ошибке. Если страница не индексируется, причина может быть не в тексте, а в canonical, sitemap, robots.txt или дублях. Поэтому быстрый bugfix всё равно должен быть аккуратной диагностикой.

Например, по заявкам полезно проверить логику из статьи почему не приходят заявки с сайта на 1С-Битрикс. Для оплаты — пройти чек-лист из материала про онлайн-оплату на 1С-Битрикс. Для индексации — смотреть цепочку из статьи почему страницы на Битрикс не попадают в поиск.

Что нужно прислать для оценки

• ссылку на страницу, где проявляется ошибка;
• короткое описание ожидаемого и фактического поведения;
• скриншот или запись экрана, если проблема видна только в интерфейсе;
• когда ошибка появилась: после обновления, правки, публикации, смены хостинга или подключения сервиса;
• доступы к админке, FTP/SSH, логам или тестовой копии, если нужна точная диагностика;
• список сценариев, которые нельзя сломать при исправлении.

Когда bugfix превращается в аудит

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

Если после исправления становится понятно, что нужна новая логика, компонент, интеграция или переработка шаблона, это уже не просто bugfix, а разработка на 1С-Битрикс. Для регулярных мелких правок и контроля лучше подходит поддержка сайта.

Как фиксирую результат после правки

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

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

Когда не стоит чинить на живую

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

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

Как выглядит безопасная точечная правка

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

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

Можно исправить ошибку без доступа к серверу?

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

Вы берёте срочные правки?

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

Что делать, если ошибку уже пытались чинить?

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