Видалення кошика всіх предметів / сеанс з кошиком очищається

Сайт, яким я керую раптово (можливо, 2 тижні тому - зі статистики GA, і лише про це повідомляється зараз), почав скидати товари, коли ви переглядаєте кошик, або переходите до замовлення.

Угорі "міні-кошик" відображаються товари, що знаходяться у спадному меню, доки ви не перейдете до кошика / каси, а потім опинитесь у кошику із повідомленням "У вашому кошику немає товарів".

Схоже, випуск сеансу. Це не відбувається при вході в систему.

Видалено всі параметри перевірки сеансу в 'system-> web-> settings validation session' та ввімкнено те, що говорить 'Use SID on Frontend'. Це вирішило проблему, але оскільки ці налаштування не змінилися протягом останніх 3 місяців, я знаю, що існує деяка основна проблема.

Тоді це вказує на проблему з проблемою боляче-id? Якимсь чином сайт втрачає, на якому магазині ідентифікується, і видаляє дані сеансу / кошика? Можливо, якийсь спостерігач / подія / переписується якимсь модулем.

Я не можу повторити проблему на локальному розробнику або на сервері UAT. БД в UAT - це 2 тижні від прямої трансляції, тож це може вказувати на проблему / налаштування db?

Те, що я намагаюся: я зайнятий перетягуванням потокового db-трансляції до UAT, щоб отримати оновлення, щоб побачити, чи можу я повторити цю проблему там. оновиться, коли це буде зроблено.

Як тільки я можу повторити проблему в неживій зоні, я систематично відключатимуть модулі, перевіряю, чи щось не замислюється з ідентифікаторами магазину (починаючи з MageMonkey і солодкої зубки, оскільки вони оновлювались 2 тижні тому)

Питання - що ще я можу спробувати? Будь-які покажчики на те, де я можу зірвати деякі точки перерви та перейти до коду, щоб побачити, чи можу я простежити цю проблему?

не встановлено додаткових кеш-систем, таких як лак або мемоша. Сервер - це стандартна установка 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 на сервері?

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

Однією з проблем може бути те, що Magento не зберігає дані сеансу при переході з HTTP на HTTPS . Переконайтесь, що необхідні настройки для SSL тощо встановлені належним чином.

Іншою проблемою може бути те, що провайдер клієнта змінює свою ip-адресу, як це зафіксовано тут .

Щоб виправити цю проблему:

Змініть параметри перевірки сеансу в адміністраторі Magento, знайденому в розділі Система> Конфігурації> Веб , на "ні" для всього, окрім " Перевірити HTTP_USER_AGENT ". Після цього перейдіть до системи> Керування кешем та оновіть кеш конфігурації, щоб застосувати зміни.

Цю проблему ми спостерігали, коли на сторінці є зображення, яке відсутнє, особливо якщо зображення відсутнє на всіх сторінках, наприклад, у заголовку чи колонтитулі. Схоже, що сторінка 404, яку Magento або веб-сервер повертає, порушує файли cookie сеансу "фронтенд", що призводить до втрати сеансу. Це в нашому списку речей, які потрібно виправити, але вирішення проблеми полягає в тому, щоб не було відсутніх зображень ...

Це може бути проблема файлів cookie / дати. Перше, що потрібно перевірити - це заголовки файлів cookie. Огляньте заголовки (використовуючи щось на кшталт Firebug, Charles або Fiddler).

Ви повинні побачити щось таке:

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

Якщо значення для поля з закінченням терміну дії минуло, то шанси на те, що час на вашому сервері невірний. Це може статися, коли такі сервіси, як 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 для кешування 404s протягом 120-х, так що наші сервери не будуть сильно забиті, коли на сторінці є помилка 404.

Отже, проблема 404-х років Magento відповідав Set-Cookie в заголовку файлів cookie frontend та frontend_cid, який скидає сеанс клієнта.

Нашим рішенням для цього є зняття будь-якого Set-Cookies для 404 відповідей,

unset beresp.http.set-cookie;

Дурні речі, які порушили для мене сесії PHP в минулому і, можливо, варто їх перевірити:

• повний диск
• неточний час сервера