OpenCart не видит изображения — причины и способы исправления

В OpenCart изображения могут пропасть по-разному.

У одного магазина после переноса перестают отображаться вообще все картинки товаров. У другого в админке изображение выбрано, но на витрине вместо него пустое место. У третьего открывается оригинальный файл, но не генерируются миниатюры.

Поэтому первое, что нужно сделать, — понять на каком этапе ломается цепочка:

Файл изображения существует?
        ↓
OpenCart знает правильный путь?
        ↓
Оригинал открывается напрямую?
        ↓
Может ли OpenCart создать миниатюру?
        ↓
Правильно ли формируется URL?
        ↓
Не блокирует ли браузер HTTPS / Mixed Content?
        ↓
Не подменяет ли путь тема или модификатор?

Менять права на все каталоги, очищать весь серверный кеш и переустанавливать OpenCart наугад не нужно.

Сначала локализуем проблему.

Что проверить в первую очередь

Если OpenCart перестал показывать изображения, не начинайте сразу с:

chmod -R 777
удалить весь cache
переустановить тему
пересохранить все товары

Сначала возьмите одно конкретное сломанное изображение.

Например:

Товар: Ноутбук ASUS
Файл в админке: catalog/laptops/asus.jpg

И ответьте на четыре вопроса:

1. Есть ли физически файл image/catalog/laptops/asus.jpg?

2. Открывается ли оригинал напрямую?

3. Открывается ли его версия из image/cache/?

4. Какой URL картинки реально указан в HTML страницы?

Эти четыре проверки часто сразу показывают, где проблема.

Шаг 1. Определяем масштаб проблемы

Сначала выясните, что именно не отображается.

Вариант A — пропали все изображения

Не работают:

• логотип;
• картинки товаров;
• категории;
• баннеры;
• дополнительные изображения.

Тогда вероятность выше, что проблема общая:

DIR_IMAGE
config.php
домен / HTTPS
права
путь после миграции

Вариант B — не работают только товары

Логотип и баннеры есть, но товарные изображения пропали.

Проверяем:

путь товара
наличие исходного файла
базу данных
image/cache

Вариант C — оригинал есть, миниатюры отсутствуют

Это особенно важный симптом.

OpenCart не всегда отдаёт исходную картинку прямо на карточку или каталог. Он создаёт уменьшенные версии в каталоге image/cache/.

Поэтому ситуация:

/image/catalog/product/photo.jpg     → работает
/image/cache/catalog/product/...jpg → 404

сразу отправляет нас к генерации кеша изображений.

Шаг 2. Проверяем исходный файл на сервере

Допустим, OpenCart хранит путь:

catalog/product/photo.jpg

Физически ожидаем:

/path/to/opencart/image/catalog/product/photo.jpg

На Linux можно проверить:

ls -lah /path/to/opencart/image/catalog/product/photo.jpg

Если получаем:

No such file or directory

OpenCart тут ни при чём — исходного файла физически нет.

После миграции изображения часто просто не копируют

Типичный перенос:

база данных → перенесли
код сайта → перенесли
image/ → перенесли не полностью

В базе остаётся:

catalog/product/photo.jpg

но файла на новом сервере уже нет.

Проверьте количество файлов на старом и новом сервере, если старый ещё доступен.

Например:

find /old/site/image/catalog -type f | wc -l

и:

find /new/site/image/catalog -type f | wc -l

Если было:

18432

а стало:

12107

проблема уже найдена.

Шаг 3. Открываем оригинал напрямую

Попробуйте открыть:

https://example.com/image/catalog/product/photo.jpg

Если изображение открывается — исходный файл существует и веб-сервер может его отдать.

Если получаем:

404 Not Found

проверяем:

• правильность пути;
• физическое наличие;
• регистр букв;
• права;
• корень сайта.

Если:

403 Forbidden

смотрим уже права и конфигурацию веб-сервера.

Шаг 4. Смотрим, какой URL реально отдаёт OpenCart

Откройте проблемную страницу товара.

В Chrome:

F12
→ Elements

Найдите <img>.

Например:

<img src="https://example.com/image/cache/catalog/product/photo-500x500.jpg">

Скопируйте значение src и откройте его отдельно.

Это принципиально важно.

Не надо гадать:

«Наверное, картинка не загружается».

Нужно получить конкретный ответ:

200
404
403
500
mixed content

Шаг 5. Используем Network

В DevTools:

F12
→ Network
→ Img

Перезагрузите страницу.

Теперь видно, какие изображения падают.

Например:

photo-500x500.jpg    404
logo.png             200
banner.webp          200

Это уже сильно сужает проблему.

Если изображение отдаёт 404

Проверяем:

путь
исходный файл
image/cache
регистр

Если 403

Проверяем:

permissions
owner
Nginx / Apache

Если 500

Проверяем:

PHP
GD
ошибки OpenCart
модификатор

Шаг 6. Проверяем путь изображения в OpenCart

В админке откройте проблемный товар и посмотрите выбранное изображение.

В нормальной ситуации OpenCart хранит относительный путь внутри каталога изображений, например:

catalog/product/photo.jpg

а не абсолютный Windows/Linux путь вида:

C:\Users\...

или:

/home/olduser/public_html/...

Сам каталог изображений определяется конфигурацией OpenCart через DIR_IMAGE.

Шаг 7. Проверяем DIR_IMAGE

Это особенно важно после переезда.

В зависимости от версии OpenCart структура конфигурации различается, но в классических 2.x/3.x вы обычно увидите DIR_IMAGE в:

config.php

и:

admin/config.php

Пример:

define('DIR_IMAGE', '/var/www/example.com/image/');

После переезда может остаться старый путь:

define('DIR_IMAGE', '/home/olduser/public_html/image/');

при том что реальный сайт теперь находится:

/var/www/example.com/

Тогда OpenCart ищет изображения вообще не там.

Проверяем путь

На сервере:

grep DIR_IMAGE /path/to/site/config.php

Для старых веток также:

grep DIR_IMAGE /path/to/site/admin/config.php

Затем:

ls -ld /var/www/example.com/image

Путь из конфигурации должен соответствовать реальному каталогу.

Не меняйте config.php по статье вслепую

Сначала сделайте резервную копию:

cp config.php config.php.bak

и при необходимости:

cp admin/config.php admin/config.php.bak

После этого уже сравнивайте пути.

Шаг 8. Проверяем image/cache

OpenCart генерирует уменьшенные изображения в:

image/cache/

Например исходник:

image/catalog/products/phone.jpg

может породить файл вроде:

image/cache/catalog/products/phone-300x300.jpg

Точное имя зависит от версии и требуемого размера.

Проверяем каталог

ls -ld image/cache

Затем:

find image/cache -maxdepth 2 -type f | head

Если каталог пустой, это ещё не обязательно ошибка.

Но если OpenCart пытается создать миниатюры, а каталог остаётся пустым, проверяем возможность записи.

Почему оригинал работает, а миниатюра нет

Допустим:

https://example.com/image/catalog/product/photo.jpg

открывается.

Но:

https://example.com/image/cache/catalog/product/photo-500x500.jpg

даёт 404.

Тогда вероятная цепочка:

исходник найден
↓
OpenCart пытается создать resized image
↓
создание файла не происходит
↓
браузер запрашивает отсутствующий cache-файл

Проверяем:

• права;
• владельца;
• PHP GD;
• ошибки PHP;
• свободное место;
• модификации image tool.

Шаг 9. Проверяем права

Сначала смотрим фактические значения:

namei -l /var/www/example.com/image/cache

или:

ls -ld /var/www/example.com/image
ls -ld /var/www/example.com/image/cache

И для конкретного файла:

ls -l /var/www/example.com/image/catalog/product/photo.jpg

Не ставьте 777 как универсальное решение

Совет:

chmod -R 777 image

— плохой.

Он:

• чрезмерно расширяет доступ;
• маскирует настоящую проблему владельца;
• создаёт риск безопасности.

Обычно веб-серверу/PHP нужна возможность читать исходники и создавать кешированные файлы там, где OpenCart действительно должен писать.

Конкретный пользователь зависит от сервера:

www-data
nginx
apache

поэтому универсальную команду chown копировать вслепую тоже не стоит.

Шаг 10. Проверяем владельца файлов

Очень частая ситуация после:

scp
rsync
распаковки архива под root

Получается:

image/catalog → владелец root
image/cache   → владелец root
PHP-FPM       → www-data

PHP читает часть файлов, но не может создавать новые.

Проверяем:

ls -ld image image/cache image/catalog

Например:

drwxr-xr-x root root image/cache

Само по себе это ещё не доказывает проблему, но если PHP должен туда писать, нужно проверить права именно от имени PHP-пользователя.

Шаг 11. Проверяем запись безопасно

Не создавайте мусор через PHP-код на production.

Лучше сначала определить пользователя PHP-FPM:

ps aux | grep php-fpm

или:

grep -R "^user =" /etc/php/*/fpm/pool.d/

После этого уже можно понять, имеет ли этот пользователь право записи в image/cache.

Шаг 12. Регистр букв — очень частая проблема после Windows

На Windows:

Photo.JPG
photo.jpg
PHOTO.jpg

часто воспринимаются файловой системой без различия регистра.

На Linux:

Photo.JPG

и:

photo.jpg

— разные имена.

После переноса магазин может хранить:

catalog/product/photo.jpg

а реальный файл называется:

Photo.jpg

Результат:

404

Проверяем

ls -lah image/catalog/product/

Сравниваем имя символ в символ.

Особенно:

.jpg / .JPG
.png / .PNG
Catalog / catalog
Product / product

Шаг 13. Ищем похожий файл без учёта регистра

find image/catalog -iname "photo.jpg"

Если вывод:

image/catalog/Product/Photo.JPG

а OpenCart запрашивает:

image/catalog/product/photo.jpg

причина найдена.

Шаг 14. Проверяем HTTPS

После перехода магазина с:

http://

на:

https://

часть изображений может продолжать загружаться по HTTP.

Даже если сам магазин уже работает по HTTPS, тема или старый контент может продолжать генерировать ссылки:

http://example.com/image/...

Проверяем Mixed Content

Откройте:

F12
→ Console

Если видите что-то вроде:

Mixed Content

значит HTTPS-страница пытается загрузить небезопасный HTTP-ресурс.

Проверяем HTML

В DevTools найдите:

<img src="http://example.com/image/...">

при странице:

https://example.com/product

Это уже конкретная проблема формирования URL.

Шаг 15. После смены домена

Было:

old-shop.ru

стало:

new-shop.ru

Сам OpenCart в нормальной схеме должен формировать URL изображений относительно конфигурации магазина, но кастомная тема, HTML-описания, модификаторы или сторонние модули могут содержать старый домен жёстко.

Поищите:

grep -R "old-shop.ru" catalog/ system/ extension/ 2>/dev/null

Но на большом проекте сначала лучше ограничить поиск каталогом темы и модификаций.

Не делайте массовый SQL REPLACE без backup

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

Сначала:

mysqldump ...

и только потом анализ.

Шаг 16. Проверяем кеш OpenCart

Кеш действительно может мешать после изменений.

Но здесь важно различать:

обычный системный cache

и:

image/cache

Это не одно и то же.

Удаление системного кеша само по себе не восстановит отсутствующий исходный JPG.

Когда очищать кеш имеет смысл

После:

• замены изображения;
• исправления темы;
• изменения размеров миниатюр;
• удаления старых модификаций;
• переноса сайта;
• исправления пути.

Сначала устраните причину, потом очищайте кеш.

Шаг 17. Не удаляйте image/catalog

Если захотели «очистить картинки OpenCart», удалять нужно не исходные изображения.

Вот это:

image/catalog/

обычно содержит оригиналы.

А:

image/cache/

— производные файлы.

Перепутать их — отличный способ превратить проблему «нет миниатюр» в проблему «нет вообще никаких изображений».

Перед очисткой image/cache сделайте backup

Даже если кеш воспроизводим, безопаснее:

mv image/cache image/cache.old
mkdir image/cache

Но делать это нужно только после проверки прав и понимания конкретной версии магазина.

Если OpenCart затем успешно создаёт новые миниатюры — старый cache действительно можно было регенерировать.

Если новый каталог остаётся пустым — проблема глубже.

Шаг 18. Проверяем тему

Если изображения пропали только:

на главной
в карточке товара
в модуле рекомендаций

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

Кастомная тема может:

• использовать собственный resize;
• формировать свой URL;
• ожидать нестандартные размеры;
• использовать lazy loading;
• заменять src на data-src;
• подключать WebP-модуль.

Быстрая проверка через HTML

Посмотрите:

<img src="">

или:

<img data-src="...">

Если src пустой, а JavaScript должен подставить его позже, проблема может вообще быть не в OpenCart image tool, а в JS темы.

Проверяем Console

F12
→ Console

Если есть:

Uncaught TypeError
ReferenceError

и одновременно не работают lazy-loaded картинки, сначала чините JavaScript.

Шаг 19. Проверяем OCMOD и расширения

В OpenCart 2.x/3.x огромное количество магазинов использует OCMOD и сторонние расширения.

Они могут изменять:

• image resize;
• controller товара;
• template;
• URL картинок;
• WebP;
• lazy loading;
• CDN;
• кеширование.

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

Не отключайте всё на production вслепую

Сначала:

1. зафиксируйте, после чего появилась ошибка;
2. сделайте backup;
3. проверьте modifications;
4. сравните с default behaviour;
5. по возможности тестируйте на staging.

Если проблема появилась после Refresh Modifications

Отдельно запомните момент:

Extensions
→ Modifications
→ Refresh

После refresh может начать применяться модификация, которая до этого фактически не работала.

Если сразу после этого исчезли изображения — исследуйте соответствующий XML/OCMOD.

Шаг 20. Проверяем PHP GD

OpenCart использует PHP для обработки изображений. Если нужная графическая библиотека недоступна или работает неправильно, resize может падать.

Проверяем:

php -m | grep -i gd

Нормальный результат:

gd

Дополнительно:

php -i | grep -i "GD Support"

Ожидаем:

GD Support => enabled

Важный нюанс с CLI и PHP-FPM

Команда:

php -m

проверяет CLI PHP.

А сайт может работать через другую версию PHP-FPM.

Например:

CLI: PHP 8.3
FPM: PHP 8.1

Поэтому:

php -m → gd есть

ещё не гарантирует, что GD есть именно у того PHP, который обслуживает OpenCart.

Проверяем версию PHP-FPM

Например:

systemctl status php8.2-fpm

или:

ps aux | grep php-fpm

Дальше уже смотрим конфигурацию конкретной версии.

Шаг 21. Проверяем тип исходного файла

Если тип изображения не подходит ожидаемой обработке, генерация resized-копии может не пройти как ожидается.

Проверить файл:

file image/catalog/product/photo.jpg

Нормально:

JPEG image data

Подозрительно:

HTML document
ASCII text
empty

Расширение .jpg ещё не означает, что внутри действительно JPEG.

Проверяем битое изображение

Можно использовать:

identify image/catalog/product/photo.jpg

если установлен ImageMagick.

Или:

file image/catalog/product/photo.jpg

Если файл был повреждён при загрузке или переносе, OpenCart его не починит.

Шаг 22. Проверяем свободное место

Это реже, но очень неприятно.

df -h

Если:

/dev/vda1  100%

OpenCart просто некуда записывать новые cache-файлы.

Также:

df -i

Если закончились inode, место в гигабайтах может ещё быть, но новые файлы создавать невозможно.

Шаг 23. Проверяем error log

Не угадывайте, если сервер уже сообщает ошибку.

В зависимости от версии OpenCart логи могут лежать в storage/logs.

Ищите:

error.log

Например:

tail -n 100 /path/to/storage/logs/error.log

Что искать в логе

Например:

Permission denied

getimagesize(): failed

imagecreatefromjpeg()

No such file or directory

Allowed memory size exhausted

Это гораздо полезнее совета:

«Попробуйте очистить кеш».

Шаг 24. Проверяем PHP-FPM / веб-сервер

Если OpenCart log пуст, смотрим системные логи.

Nginx:

tail -n 100 /var/log/nginx/error.log

PHP-FPM — через journal, например:

journalctl -u php8.2-fpm -n 100 --no-pager

Название сервиса зависит от установленной версии PHP.

Шаг 25. Если изображений очень много

Проблема может появляться не для всех файлов.

Например:

маленькие JPEG работают
огромные PNG → нет

Тогда проверяем память PHP.

Изображение размером:

8000 × 8000

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

Файл 8 MB не означает, что PHP нужно всего 8 MB RAM.

Проверяем memory_limit

php -i | grep memory_limit

Но опять помним: CLI и FPM могут отличаться.

Если в логах есть:

Allowed memory size exhausted

увеличивать лимит можно только после того, как вы убедились, что исходные изображения имеют разумные размеры.

Шаг 26. В админке картинка есть, на витрине нет

Это отдельная полезная ветка.

Если Image Manager показывает изображение, значит:

файл существует
админка его читает

Но витрина может использовать:

• другой размер;
• другой URL;
• cache-версию;
• кастомную тему;
• CDN/WebP extension.

Тогда сравните URL картинки:

в админке

и:

на витрине

Шаг 27. Изображение есть у товара, но в категории пусто

Если карточка товара показывает фотографию, а список категории — нет, исходный файл почти наверняка исправен.

Проверяем уже:

resize для category thumbnail
размеры темы
template категории
модификатор

Это значительно лучше, чем повторно загружать все картинки.

Шаг 28. Изображения не работают только на одном магазине multistore

Если OpenCart работает в режиме нескольких магазинов, сравните:

Store A → изображения есть
Store B → изображений нет

Если файловая система общая, проблема, вероятно, в:

• URL;
• конфигурации магазина;
• HTTPS;
• теме;
• store-specific extension.

Не в самих JPEG.

Быстрый диагностический алгоритм

OpenCart не показывает изображение
             ↓
Открываем URL картинки
             ↓
        ┌────┴────┐
       200       ошибка
        ↓          ↓
    HTML/theme     какой статус?
                   ↓
            ┌──────┼──────┐
           404    403    500
            ↓      ↓      ↓
          путь   права   PHP/log
            ↓
Исходник существует?
      ↓          ↓
     НЕТ        ДА
      ↓          ↓
восстановить   cache image работает?
файл             ↓        ↓
                НЕТ       ДА
                 ↓         ↓
            cache/GD     theme/HTML
            permissions  HTTPS/JS

Быстрый набор команд

Проверить файл

ls -lah image/catalog/product/photo.jpg

Найти файл без учёта регистра

find image/catalog -iname "photo.jpg"

Проверить каталог кеша

ls -ld image/cache

Посмотреть владельца

ls -ld image image/cache image/catalog

Проверить путь полностью

namei -l /var/www/example.com/image/cache

Проверить GD

php -m | grep -i gd

Проверить файл

file image/catalog/product/photo.jpg

Диск

df -h

Inode

df -i

OpenCart log

tail -n 100 /path/to/storage/logs/error.log

Nginx log

tail -n 100 /var/log/nginx/error.log

Что не стоит делать

1. chmod -R 777

Не делайте это как первую попытку.

Если проблема была во владельце, вы её не поняли — только обошли ценой безопасности.

2. Массово перезагружать изображения

Если сломался DIR_IMAGE, 10 000 повторных загрузок проблему не решат.

3. Удалять весь каталог image

Там находятся исходники.

4. Очищать всё подряд

cache
modification
theme cache
browser cache
Cloudflare cache

одновременно.

Если после этого заработает, вы даже не узнаете причину.

5. Править базу без backup

Перед массовой заменой путей:

backup first

6. Сразу винить OpenCart

Если прямой URL:

https://example.com/image/catalog/photo.jpg

возвращает 404, сначала разберитесь с файлом и веб-сервером.

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

Файла нет

Восстановить:

image/catalog/...

из backup или исходного сервера.

Путь неправильный

Исправить путь после проверки конфигурации и места хранения файлов.

DIR_IMAGE ведёт на старый серверный каталог

Исправить конфигурацию только после backup.

Original = 200, cache = 404

Проверить:

image/cache
write permissions
owner
GD
logs

HTTP-картинки блокируются на HTTPS

Исправить генерацию URL и старые ссылки.

Имя отличается регистром

Привести файл и сохранённый путь к одному точному имени.

Только кастомная тема не показывает изображения

Проверять theme/template/JS, а не файловую систему.

После модуля всё пропало

Проверять extension/OCMOD и делать rollback изменения на staging.

Как понять, что проблема действительно исправлена

Не ограничивайтесь одной карточкой товара.

Проверьте:

• главную;
• категорию;
• карточку товара;
• дополнительные изображения;
• поиск;
• похожие товары;
• мобильную версию.

В DevTools:

Network → Img

не должно быть массовых:

404
403
500

Проверяем кеш заново

Удалите или регенерируйте только то, что действительно требуется вашей версии и конфигурации.

После этого откройте новый товар, для которого миниатюра ранее не генерировалась.

Если появляется свежий файл в:

image/cache/

это хороший признак.

Если OpenCart всё ещё не видит изображения

Соберите перед дальнейшим ремонтом:

1. Версия OpenCart / ocStore.

2. Один конкретный проблемный товар.

3. Путь картинки из админки.

4. Фактический файл на сервере.

5. URL оригинала.

6. URL картинки из HTML витрины.

7. HTTP status этого URL.

8. Результат:
   ls -ld image image/cache

9. DIR_IMAGE / конфигурацию пути.

10. Последние строки OpenCart error.log.

11. Используется ли:
    кастомная тема
    OCMOD
    WebP
    CDN
    Cloudflare

12. После чего началась проблема:
    перенос
    HTTPS
    обновление
    модуль
    смена темы

После этого проблема перестаёт быть абстрактной:

«OpenCart не видит картинки»

и превращается, например, в:

image/catalog скопирован не полностью;

или:

DIR_IMAGE всё ещё указывает на старый путь;

или:

PHP-FPM читает оригинал, но не может писать в image/cache;

или:

в базе photo.jpg, а на Linux лежит Photo.JPG;

или:

кастомная тема выдаёт HTTP URL на HTTPS-странице.

Вот это уже ремонтируется предметно.