Bagisto на сервере: частые ошибки и решения

MAATRIX

Bagisto — open-source e-commerce на Laravel, которую часто выбирают как альтернативу Magento: похожая логика (мультимагазины, каналы продаж, атрибуты товаров), но без тяжёлого Elasticsearch и без прожорливого движка Magento под капотом. На практике это означает, что Bagisto проще поднять на скромном VPS — но на Laravel-стеке есть свой набор граблей: права на storage, очереди, кэш конфигурации, сборка фронтенда через npm. Ниже — ошибки, с которыми реально сталкиваются при установке и эксплуатации Bagisto, и как их закрыть без лишних догадок.

Установка: composer падает или зависает

Первая точка отказа — ещё до php artisan bagisto:install. Bagisto тянет десятки Laravel-пакетов, и на VPS с 1-2 ГБ RAM composer может упасть с ошибкой памяти:

Fatal error: Allowed memory size of 1610612736 bytes exhausted

Решение — снять лимит памяти для самого composer (это не лимит PHP-приложения, а лимит процесса установки):

COMPOSER_MEMORY_LIMIT=-1 composer create-project bagisto/bagisto myshop

Если сервер совсем скромный (1 ГБ RAM без swap), процесс всё равно может убиваться OOM-killer'ом ядра — тогда временно добавьте swap-файл на время установки:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Вторая частая ошибка на этом же шаге — отсутствующие PHP-расширения:

- bagisto/bagisto requires ext-zip * -> it is missing from your system

Bagisto требует набор расширений: bcmath, ctype, curl, exif, fileinfo, gd (или imagick), intl, json, mbstring, openssl, pdo_mysql, tokenizer, xml, zip. Ставится одной командой на Ubuntu 24.04 с PHP 8.3:

sudo apt install php8.3-{bcmath,curl,gd,intl,mbstring,mysql,xml,zip,fpm}
sudo systemctl restart php8.3-fpm

После установки зависимостей проверьте версию PHP — Bagisto 2.x требует PHP 8.1+, и если на сервере по умолчанию стоит более старый пакет из репозитория Ubuntu, php -v покажет несовместимую версию, а установщик Laravel молча откажется запускаться.

Белый экран или 500 после установки

Классика Laravel-приложений: страница либо белая, либо 500 Internal Server Error без деталей. Причины почти всегда одни и те же, по убыванию частоты:

1. Нет APP_KEY — если .env скопирован из .env.example, а php artisan key:generate не запускался, Laravel падает с "No application encryption key has been specified":

php artisan key:generate

1. Нет прав на запись в storage/ и bootstrap/cache/. Веб-сервер (обычно www-data) должен иметь право писать в эти каталоги — там кэш конфигурации, логи, скомпилированные шаблоны:

sudo chown -R www-data:www-data storage bootstrap/cache
sudo find storage bootstrap/cache -type d -exec chmod 775 {} \;
sudo find storage bootstrap/cache -type f -exec chmod 664 {} \;

1. APP_DEBUG=false скрывает реальную ошибку. На время диагностики временно включите отладку в .env и посмотрите, что реально происходит — но обязательно верните false перед тем, как открывать сайт публично, иначе трассировки стека с путями и переменными окружения увидит кто угодно:

APP_DEBUG=true

После воспроизведения ошибки смотрите storage/logs/laravel.log — там всегда есть точный стектрейс, в отличие от белого экрана в браузере.

Очереди: письма и уведомления не уходят

В Bagisto через очередь идут письма подтверждения заказа, сброс пароля, уведомления продавцам. По умолчанию в .env часто стоит:

QUEUE_CONNECTION=sync

Это значит, что задания выполняются синхронно прямо в момент запроса — письма отправляются, но заказ "подвисает" на пару секунд, если SMTP медленный. Как только вы переключаете на database или redis (что правильно для продакшена — не блокировать ответ пользователю), задания начинают копиться в очереди и никуда не деваются, потому что никто их не обрабатывает:

QUEUE_CONNECTION=redis

Нужен постоянно работающий воркер. Разовый php artisan queue:work в терминале умрёт вместе с сессией SSH — держите его под supervisor:

# /etc/supervisor/conf.d/bagisto-worker.conf
[program:bagisto-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/myshop/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600
directory=/var/www/myshop
autostart=true
autorestart=true
numprocs=2
user=www-data
redirect_stderr=true
stdout_logfile=/var/www/myshop/storage/logs/worker.log

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start bagisto-worker:*

Отдельно нужен планировщик Laravel — без него не будут работать отложенные задачи (например, чистка старых уведомлений). Cron-запись должна быть на пользователя, от которого работает www-приложение:

* * * * * cd /var/www/myshop && php artisan schedule:run >> /dev/null 2>&1

Если крон настроен неправильно (не тот путь к PHP, не тот пользователь), задания молча не выполняются — разбор похожих ситуаций есть в статье про частые ошибки cron-задач.

Медленная админка и каталог с ростом ассортимента

Bagisto легче Magento, но при росте каталога (от нескольких тысяч товаров) и наплыве заказов дефолтные настройки начинают тормозить. Три рычага, которые реально влияют на скорость:

Кэш конфигурации и роутов. На проде обязательно кэшируйте — без этого Laravel на каждый запрос заново парсит все конфиги и маршруты:

php artisan config:cache
php artisan route:cache
php artisan view:cache

Важная ловушка: если после этого поменять .env, изменения не подхватятся, пока не пересоздать кэш — php artisan config:cache заново. Забытый config:cache после правки .env — частая причина "я поменял пароль от базы, а сайт всё равно подключается к старой".

Redis вместо файлового кэша и сессий. По умолчанию Bagisto может работать на файловом драйвере (file) для кэша и сессий — это работает, но при нескольких PHP-FPM воркерах создаёт лишнюю нагрузку на диск и не масштабируется на несколько серверов. Переключение на Redis:

CACHE_STORE=redis
SESSION_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

Частые ошибки конфигурации Redis (не запускается, "Connection refused", вылетает по памяти) разобраны отдельно в статье про Redis на сервере.

Индексы и медленные запросы MySQL. Каталог, фильтры по атрибутам и поиск в Bagisto строятся на обычных MySQL-запросах (Elasticsearch не обязателен, в отличие от Magento). Это плюс для лёгкости, но при большом каталоге без нормальных индексов запросы к product_flat начинают тормозить. Включите slow_query_log и проверьте, какие запросы реально медленные, прежде чем гадать:

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Подробный разбор диагностики медленных запросов — в статье MySQL: медленные запросы, причины и решение.

Изображения товаров не загружаются или не отображаются

Две разные проблемы, которые путают между собой.

Изображения не загружаются в админке — обычно упирается в лимит размера тела запроса на уровне nginx, а не PHP:

413 Request Entity Too Large

PHP-лимиты (upload_max_filesize, post_max_size в php.ini) нужно поднять вместе с nginx-лимитом, иначе отвалится на уровне веб-сервера раньше, чем запрос дойдёт до PHP:

client_max_body_size 20M;

; php.ini
upload_max_filesize = 20M
post_max_size = 20M

Уже загруженные изображения отдают 404 — почти всегда забытый симлинк на публичное хранилище. Laravel хранит загруженные файлы в storage/app/public, а наружу должна смотреть символическая ссылка public/storage:

php artisan storage:link

Если сайт переносили на другой сервер копированием файлов (а не через storage:link), симлинк мог скопироваться как обычная папка или сломаться из-за смены пути — проверьте ls -la public/storage, там должна быть именно ссылка на ../storage/app/public, а не пустая директория.

Nginx и PHP-FPM: конфигурация под Laravel-приложение

Bagisto — это Laravel, поэтому весь трафик должен идти через public/index.php, а не напрямую в файлы. Рабочий минимальный конфиг:

server {
    listen 80;
    server_name shop.example.com;
    root /var/www/myshop/public;
    index index.php;

    client_max_body_size 20M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_read_timeout 300;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Обратите внимание на fastcgi_read_timeout 300 — дефолтные 60 секунд nginx укладывают запрос при импорте большого каталога товаров или полной переиндексации: страница отвалится с 504 Gateway Timeout, хотя сам PHP-процесс продолжит работать в фоне ещё несколько минут. Такие импорты и массовые операции стоит вообще выносить в очередь (см. раздел про воркеры выше), а не гонять синхронным HTTP-запросом.

Пул PHP-FPM тоже стоит подстроить под память сервера — дефолтные pm.max_children на общем хостинге часто занижены или, наоборот, завышены под реальный объём RAM, что либо душит параллельные запросы, либо роняет сервер по памяти при пиковой нагрузке. Базовый расчёт и общая логика настройки nginx как обратного прокси для PHP-приложений разобраны в статье Nginx как reverse proxy: частые ошибки и решения.

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