Почему OpenCart не запускается после восстановления

Если OpenCart не запускается после восстановления, сначала сохраните текущее состояние и выясните, что именно восстановили: файлы, базу или оба набора. Ошибка 500 сама по себе не называет причину. Я проверяю полноту копии, подключение к базе, пути в конфигурации и журнал сервера, а затем возвращаю магазин к работе по одному изменению за раз.

1. Сначала определите, что именно восстановили

Когда OpenCart отвечает ошибкой 500, это общий ответ веб-сервера: приложение не отдало нормальную страницу. По одному коду нельзя заключить, что виновата база. Причина может быть в PHP, расширении, конфигурации веб-сервера, правах на конкретный каталог или в несовместимой версии дополнения. Я начинаю не с перезагрузки и не с правки .htaccess, а с фиксации времени сбоя и чтения error log за этот момент. Так мы ищем сообщение о конкретной ошибке, а не гадаем по внешнему симптому. На этом шаге полезна поддержка сайта и сервера, если доступа к журналам у вас нет.

Сначала запишите версию OpenCart, PHP и СУБД, имя веб-сервера и дату копии. Сверьте это с данными старой площадки, если они сохранились. Не существует универсальной пары «эта версия PHP подходит всем OpenCart»: требования зависят от ветки движка и установленных расширений. Текущая документация OpenCart 4 указывает PHP 8.0+ для своей актуальной инструкции, но это не разрешение переключать на неё любой старый магазин. Для конкретной установки сверяйте требования именно её релиза и дополнений.

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

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

• Сохранить текущие файлы и базу перед правками
• Записать версии движка, PHP и расширений
• Сопоставить время сбоя с журналами
• Проверить, что копия включает файлы и базу

2. Проверьте импорт SQL-дампа

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

Через панель импорта проверьте журнал результата, а при большом дампе используйте штатный инструмент СУБД и доступный на сервере способ передачи файла. Консольный импорт часто удобнее, когда браузер обрывает длительный запрос, но он не исправляет повреждённый дамп и не гарантирует верный выбор базы. Синтаксис команд зависит от используемого сервера и способа авторизации; прежде чем запускать команду, проверьте имя базы, пользователя и файл. Не публикуйте пароль в истории терминала, переписке или скриншоте.

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

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

• Уточнить, одна ли это база и один ли дамп
• Проверить итог импорта и текст ошибок
• Сверить префикс таблиц с конфигурацией
• При сомнении импортировать в отдельную пустую базу

3. Сверьте config.php и расположение storage

В OpenCart есть конфигурация для витрины и отдельная для административной части: обычно это config.php и admin/config.php, где admin мог переименовать владелец магазина. В конфигурации задаются параметры подключения к базе и пути приложения. Проверьте имя базы, пользователя, адрес сервера, префикс и каталоги относительно фактического размещения файлов. Одной правки в корневом файле может не хватить, если административная часть продолжает обращаться к старому адресу или пути.

Отдельно проверьте путь к storage. После переноса он может указывать на старую файловую систему или каталог, которого больше нет. Имена констант и устройство конфигов зависят от ветки OpenCart, поэтому сверяйте файл с дистрибутивом именно установленной версии. В OpenCart 4 официальный код установки формирует пути к служебным каталогам и параметры БД; это полезный образец для понимания назначения конфигурации, но не шаблон для копирования поверх старой версии.

Сравните текущие конфиги с копией и отмечайте каждое отличие. Не вставляйте сюда реальные пароли при обсуждении проблемы. После восстановления доступ к файлам конфигурации должен быть ограничен настолько, чтобы случайный посетитель не мог их прочитать, а процесс сайта мог читать необходимые файлы. Нельзя объявить 644 обязательным для каждого сервера: доступ зависит от владельца файлов, группы, пользователя PHP-FPM и настроек хостинга. Проверяйте фактический доступ, а не магическое число.

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

• Проверить оба конфигурационных файла
• Сверить реквизиты БД и префикс таблиц
• Найти фактический каталог storage
• Проверить владельца и рабочие права без массового chmod

4. Проверьте .htaccess и настройки веб-сервера

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

Уточню важную деталь: mod_rewrite относится к Apache. В его документации сказано, что директивы в .htaccess обрабатываются при соответствующем разрешении AllowOverride (в частности, класса FileInfo). У Nginx .htaccess не используется; правила задают в конфигурации виртуального хоста. Поэтому совет «включите mod_rewrite на Apache или Nginx» технически неверен: сначала определите сервер и проверьте его конфиг штатным способом.

Не считайте каждое несовпадение старого .htaccess новой причиной 500. Часто правила просто не применяются или дают неверный маршрут, а сам 500 указывает на ошибку обработки запроса. Журнал Apache или PHP покажет, есть ли ошибка синтаксиса, запрещённая директива или сбой приложения. Если сайт размещён за панелью управления, конфигурацией могут управлять шаблоны панели; тогда локальная правка файла не обязательно меняет итоговый конфиг.

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

• Скопировать текущий .htaccess перед экспериментом
• Определить Apache или Nginx
• В Apache проверить AllowOverride и разрешённые директивы
• Сверить лог после каждого изменения

5. Запускайте магазин по контрольному списку

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

Проверяйте бизнес-функции на тестовом заказе, не создавая реальную оплату и не отправляя уведомления покупателям без согласованного тестового режима. Проверьте расчёт доставки, применимость скидки, письмо администратора и поведение платежного модуля в тестовом окружении. После переноса внешние интеграции могут требовать отдельной проверки ключей и URL обратного вызова. Это уже не обязательно причина 500, но магазин, который открывается и не принимает заказы, нельзя считать восстановленным.

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

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

• Проверить витрину и админку отдельно
• Провести безопасный тест заказа и интеграций
• Создать отдельную свежую копию
• Зафиксировать изменения и результат

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