Корзина отбрасывает все предметы / корзина очищает сессию

Сайт, которым я управляю внезапно (возможно, 2 недели назад - из статистики GA, и только что сообщенный сейчас) начал сбрасывать элементы корзины при просмотре корзины или переходе к оформлению заказа.

В верхней «мини-корзине» отображаются элементы в раскрывающемся меню, пока вы не перейдете к корзине / оформлению заказа, а затем окажетесь в корзине с сообщением «В вашей корзине нет товаров».

Похоже на сессионный вопрос. Это не происходит при входе в систему.

Удалил все параметры проверки сеанса в «system-> web-> параметры проверки сеанса» и включил параметр «Использовать SID на веб-интерфейсе». Это действительно решило проблему, но, поскольку эти настройки не изменились за последние 3 месяца, я знаю, что есть некоторая основная проблема.

Это тогда указывает на проблему с проблемой sore-id? Каким-то образом сайт теряет идентификатор хранилища и отбрасывает данные сеанса / корзины? Может быть, какой-то наблюдатель / событие / переписать какой-то модуль.

Я не могу повторить проблему на локальном устройстве или на сервере UAT. БД по UAT - это 2 недели, начиная с прямой трансляции, так что это может указывать на проблему / настройку БД?

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

После того, как я смогу воспроизвести проблему в не-живой области, я буду систематически отключать модули, чтобы увидеть, не происходит ли что-нибудь с идентификаторами магазинов (начиная с MageMonkey и sweettooth, так как они были обновлены 2 недели назад).

Вопрос - что еще можно попробовать? Любые указатели, где я могу ударить некоторые точки останова и пошаговый код, чтобы увидеть, могу ли я отследить эту проблему?

нет никаких дополнительных систем кэширования, таких как лак или memcache. Сервер является стандартной установкой cpanel. Тестирование на UAT Я отключил весь кеш.

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

Я также использовал git для возврата кода, и проблема остается с каждым хэшем.

Обновление: прошло некоторое время, так как я успел потратить на это. Высокая рабочая нагрузка.

Я переместил сеансы в файл, и проблема исчезла. Так как клиент не намерен использовать несколько серверов в ближайшем будущем, и из-за моей рабочей нагрузки это было оставлено на этом. Скорее всего, вернется, чтобы укусить меня позже.

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

обновлю, когда получу больше результатов.

На наших коробках cPanel отсутствующие ресурсы обслуживали всю страницу Magento.

по умолчанию Cpanel, чтобы , ErrorDocument 404 /404.shtmlно /404.shtmlне существует в корневом каталоге документов Magento, так .htaccess , получает снова и переадресовывает выполняется /404.shtmlв index.php( с помощью mod_rewrite).

По умолчанию Magento .htaccess должен явно указывать 404, 500 и другие обработчики ошибок.

Чтобы исправить это поведение, мы добавили в наш .htaccess следующее:

ErrorDocument 404 /errors/404.php

Мы, вероятно, также должны добавить 500:

ErrorDocument 500 /errors/500.php

Вы используете Varnish на сервере?

Мы видели несколько реализаций, в которых люди удаляют куки-файлы ДО выборки статического контента (images / css / js) - поэтому, если изображение / js / css не существует; он загружает загрузчик Magento и 404-е - это полностью удаляет файлы cookie и сеанс сайта.

Одной из проблем может быть то, что Magento не сохраняет данные сеанса при переключении с HTTP на HTTPS . Убедитесь, что необходимые настройки для SSL и т. Д. Установлены правильно.

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

Чтобы исправить эту проблему:

Измените параметры проверки сеанса в Magento Admin, находящиеся в разделе « Система»> «Конфигурации»> «Интернет» , на «нет» во всем, кроме « Проверка HTTP_USER_AGENT» . После этого перейдите в « Система»> «Управление кэшем» и обновите кэш конфигурации, чтобы применить изменения.

Мы наблюдали эту проблему, когда на странице отсутствует изображение, особенно если изображение отсутствует на всех страницах, например, в верхнем или нижнем колонтитуле. Кажется, что страница 404, которую возвращает Magento или веб-сервер, ломает куки-файл сеанса внешнего интерфейса, что приводит к потере сеанса. Он находится в нашем списке вещей, которые нужно исправить, но обходной путь должен обеспечить отсутствие пропущенных изображений ...

Это может быть проблема с датой cookie / сервера. Первым делом проверьте заголовки файлов cookie. Осмотрите заголовки (используя что-то вроде Firebug, Charles или Fiddler).

Вы должны увидеть что-то вроде следующего:

Set-Cookie  frontend=9dhtlgf1qmo6loqksvvmqjd625; expires=Thu, 31-Jan-2013 05:01:13 GMT; path=/; domain=.foo.com; HttpOnly

Если значение для поля expires осталось в прошлом, скорее всего, время на вашем сервере неверно. Это может произойти, когда такие службы, как ntpd не запускаются. Если это так, проверьте время на сервере. Если время выключено, проверьте состояние ntpd (или какой-либо службы демонов, которая будет обновлять время сервера).

Сборка мусора в PHP очищает сессии преждевременно. Я сам видел это на сайтах с большим трафиком .

Некоторые советы по устранению неполадок:

• Сколько лет вашей самой старой сессии? Чтобы выяснить: ls -laht [mageroot]/var/session/ | tail- если у вас нет сеансов дольше, чем пару недель или около того, скорее всего виновата сборка мусора
• Временно перемещайте сессии в другое хранилище данных - например, MySQL или Memcached. Проблема решена?
• Это происходит на сервере разработки? Если нет, и все вещи равны, возможно, уровни трафика вызывают преждевременное истечение срока сеанса или сборку мусора.

Я исправил это одним из двух способов:

1. В вашем .htaccess добавьте php_value session.gc_maxlifetime 2592000
2. В вашем php.ini установите session.gc_maxlifetime

Больше чтения: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

У нас была похожая проблема. В нашем случае это была конфигурация Varnish (как предложил Бен Лессани). Мы настроили наш Varnish для кэширования 404 с на 120 с, чтобы наши серверы не пострадали, когда на странице возникает ошибка 404.

Таким образом, проблема заключается в том, что 404s Magento отвечал с помощью Set-Cookie в заголовке для файлов cookie frontend и frontend_cid, которые сбрасывают сеанс клиента.

Наше решение для этого состоит в том, чтобы лишить любые Set-Cookies для 404 ответов,

unset beresp.http.set-cookie;

Тупые вещи, которые в прошлом мешали мне сеансами PHP и, возможно, стоит проверить:

• полный диск
• неточное время сервера