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

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

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

Чаще всего расходятся не остатки, а правила их показа. В магазине статус наличия зависит от количества, минимального порога, настройки вычитания при заказе и от того, что именно прислала учётная система в последней выгрузке. Отдельная ловушка. Товары с вариантами: остаток лежит на варианте, а карточка показывает остаток родителя. Мы разбираем цепочку от выгрузки до карточки и показываем, на каком шаге число меняется.

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

Штатно OpenCart считает склад один, и это главное ограничение, о котором лучше знать загодя. Несколько точек реализуются либо модулем складского учёта, либо связкой с учётной системой, где склады уже разведены, а сайт показывает сводный остаток и доступность самовывоза по точкам. Мы начинаем с вопроса, где у вас ведётся настоящий учёт: если в 1С или МойСклад, сайту разумнее оставаться витриной.

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, мультимагазин. Штатная возможность OpenCart. Особенность в том, что настройки, шаблоны, валюты, налоги и ЧПУ задаются для каждой витрины дополнительно, и заметная часть ошибок происходит оттого, что правку внесли в одну витрину, а ждали её во всех. Мы ведём карту различий между витринами и при каждой правке проверяем, к скольким она относится. По языкам дополнительно следим за полнотой перевода полей товара и служебных писем.

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

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

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