Техподдержка сайтов
на Битрикс
в Ростове-на-Дону

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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