OpenCart корзина не сохраняет товары, сессия сбрасывается

Товар добавляется в корзину OpenCart, счётчик меняется, всё выглядит нормально. Потом обновляешь страницу - корзина пустая.

Самое неприятное здесь то, что по такой ошибке легко начать искать проблему в коде корзины. Открыть cart.php, проверить контроллер, AJAX, модификаторы. А причина при этом может находиться вообще в другом месте.

Первое, что стоит проверить, - что происходит с cookie сессии после добавления товара.

Начинаем с браузера

Это самая безопасная проверка: сервер менять не нужно.

В Chrome или другом Chromium-браузере откройте инструменты разработчика через F12, затем Application → Storage → Cookies и выберите домен сайта.

Найдите cookie, которая используется для сессии. Её название зависит от настроек сайта, поэтому ориентироваться лучше на фактические cookies, а не на заранее известное имя.

Теперь добавьте товар в корзину и запомните значение этой cookie. Обновите страницу и посмотрите на неё ещё раз.

Если было:

//text

ABC123

и осталось:

//text

ABC123

браузер продолжает отправлять тот же идентификатор.

Если значение изменилось на другое, уже стоит смотреть в сторону настроек cookie, домена, HTTPS, редиректов и регенерации session ID.

Причём само изменение идентификатора ещё не означает ошибку. PHP может менять его штатно. Важнее понять, почему это произошло и что стало с данными сессии.

Можно проверить и через вкладку Network. Найдите запрос добавления товара и следующий запрос, после которого корзина становится пустой. В заголовках запроса посмотрите отправляемые cookies.

На этом этапе ничего удалять или редактировать в cookies не требуется.

Когда cookie остаётся прежней

Допустим, браузер отправляет тот же session ID, но после обновления товара уже нет.

Тогда стоит посмотреть, что происходит на сервере.

Здесь часто встречается команда:

//bash

php -i | grep session.save_handler
php -i | grep session.save_path

Но php -i в консоли показывает настройки CLI PHP. Для сайта это может быть совсем не то окружение, потому что OpenCart обычно работает через PHP-FPM.

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

Поэтому я бы не делал выводы только по результату php -i.

Для начала можно проверить сам PHP-FPM:

//bash

systemctl status php8.3-fpm

Версия здесь, конечно, должна соответствовать установленной на сервере.

Настройки PHP-FPM обычно находятся в каталоге:

//text

/etc/php/8.3/fpm/

А пользователя, от которого работает пул, можно посмотреть в его конфигурации:

//bash

grep -E '^[[:space:]]*(user|group)=' \
/etc/php/8.3/fpm/pool.d/www.conf

Не стоит автоматически считать, что это www-data. На типичной Ubuntu-системе так бывает часто, но правильнее посмотреть значение в конфигурации.

Что действительно использует сайт

Если хочется получить реальные параметры PHP, с которыми работает OpenCart, проще всего временно вывести их через небольшой PHP-файл:

//php

<?php

echo 'SAPI: ' . PHP_SAPI . '<br>';
echo 'session.save_handler: ' . ini_get('session.save_handler') . '<br>';
echo 'session.save_path: ' . ini_get('session.save_path') . '<br>';
echo 'session.name: ' . ini_get('session.name') . '<br>';

Откройте файл через браузер.

Если в результате будет, например:

//text

SAPI: fpm-fcgi
session.save_handler: files
session.save_path: /var/lib/php/sessions

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

После проверки файл нужно удалить. Оставлять диагностические скрипты на рабочем сайте не стоит.

Если PHP хранит сессии в файлах

При обработчике files проверяем именно тот путь, который указан в session.save_path.

Например:

//bash

ls -ld /var/lib/php/sessions

Смотрим владельца, группу и права.

Если PHP-FPM работает от www-data, можно сделать простой тест записи:

//bash

sudo -u www-data touch /var/lib/php/sessions/test_session

После этого проверить файл:

//bash

ls -l /var/lib/php/sessions/test_session

и удалить:

//bash

sudo rm /var/lib/php/sessions/test_session

На другом сервере путь может отличаться, поэтому /var/lib/php/sessions здесь только пример.

Если вместо создания файла появляется Permission denied, причина уже становится гораздо конкретнее: процесс PHP-FPM не может писать в каталог, где хранятся сессии.

Если с правами всё нормально

Тогда смотрим логи PHP-FPM.

Для PHP 8.3 это может быть:

//bash

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

Или только события за последние полчаса:

//bash

journalctl -u php8.3-fpm --since "30 minutes ago"

Кроме journalctl, проверьте error log PHP-FPM, который указан в конфигурации.

Особенно интересны сообщения об ошибках открытия, создания или записи данных сессии. Если PHP не может нормально работать с хранилищем, это гораздо более полезная зацепка, чем попытка наугад исправлять код корзины.

А если сессия на сервере работает?

Тогда уже имеет смысл вернуться к OpenCart.

Вспомните, после чего появилась проблема. Обновлялся PHP или сам OpenCart? Устанавливался модуль? Появился новый модификатор? Менялся домен? Сайт переносили на другой сервер? Включали HTTPS?

Последние изменения здесь особенно важны.

Например, расширение может вообще не называться «корзина», но вмешиваться в cookies, события OpenCart, авторизацию или редиректы. В результате проблема проявляется именно при работе с корзиной, хотя её код никто не менял.

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

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

Когда всё-таки открывать cart.php

Здесь полезно разделить две ситуации.

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

Если товар добавился, но пропал после обновления страницы, сначала проверяем cookie и серверное хранение сессий.

Это экономит довольно много времени.

Потому что пустая корзина сама по себе ещё ничего не говорит о месте поломки. Она лишь показывает результат: при следующем запросе OpenCart не получил ожидаемые данные.

Поэтому начинать поиск стоит с самого простого - открыть DevTools и посмотреть, что происходит с cookie после добавления товара.

Если с браузером всё нормально, переходить к PHP-FPM.

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

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