Техподдержка сайтов
на Битрикс в Казани

Мы проверяем совместимость плагинов, восстанавливаем корректные сценарии и тестируем процесс до успешного платежа.

Да. Настраиваем интеграции, проверяем тарифы и корректность расчетов по регионам.

Настраиваем SMTP, чиним триггеры писем и следим, чтобы сообщения доходили.

Оптимизируем запросы к базе, настраиваем кеширование и ускоряем отображение карточек.

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

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

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

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

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

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

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

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

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

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

Модуль «Проактивная защита» работает вне графика обновлений ядра — его можно и нужно включать даже на старой версии платформы. Он ловит SQL-инъекции, XSS и подбор паролей. Раз в месяц проверяем список установленных модулей на известные уязвимости через бюллетени безопасности Битрикса. Дыру закрываем в течение суток, если уязвимость критичная, а не ждём планового обновления.

Смотрим не только на код, но и на связку сервера. Так виднее узкое место. Число процессов PHP-FPM, настройки MySQL или Percona, включён ли opcache — это первое, что проверяем. Медленные запросы к базе чаще всего живут в кастомных компонентах без индексов на нужных полях. Добавляем memcached или Redis под кэш сессий и композитных страниц. Итог измеряем по времени ответа сервера до и после, в миллисекундах, а не на глаз.

Дубли чаще всего рождает сам фильтр каталога: одна и та же выдача доступна по нескольким комбинациям параметров URL. Настраиваем канонический адрес на страницах фильтра и закрываем от индексации служебные комбинации через robots meta. ЧПУ проверяем на совпадение с логикой хлебных крошек. Иначе поисковик путает структуру раздела. Итог сверяем по отчёту индексации, а не только по виду страницы.

Да. У «Битрикс: Управление сайтом» есть REST API и система обработчиков событий — например, OnSaleOrderSaved при создании заказа. На эти события вешаем вебхук, который отправляет данные во внешнюю систему без опроса по расписанию. Формат — JSON, авторизация по токену. Для двусторонней синхронизации, когда CRM тоже должна писать обратно в заказ, добавляем второй входящий обработчик с проверкой подписи запроса.