Koszyk upuszczający wszystkie przedmioty / sesje koszyka są czyszczone

27

Witryna, którą zarządzam nagle (potencjalnie 2 tygodnie temu - na podstawie statystyk GA i tylko zgłoszona teraz) zaczęła upuszczać elementy koszyka, gdy przeglądasz koszyk lub przechodzisz do kasy.

Górny „mini-koszyk” pokazuje pozycje w menu rozwijanym, dopóki nie przejdziesz do koszyka / kasy, a następnie nie znajdziesz się w koszyku z komunikatem „Brak produktów w koszyku”.

Wygląda na problem z sesją. Nie dzieje się to po zalogowaniu.

Usunięto wszystkie opcje sprawdzania poprawności sesji w „System-> web-> ustawienia sprawdzania poprawności sesji” i włączono opcję „Użyj SID na interfejsie użytkownika”. To rozwiązało problem, ale ponieważ te ustawienia nie zmieniły się w ciągu ostatnich 3 miesięcy, wiem, że istnieje pewien podstawowy problem.

To wskazuje na problem z problemem sore-id? Jakoś strona traci swój identyfikator sklepu i upuszcza dane sesji / koszyka? Może jakiś obserwator / zdarzenie / przepisanie przez jakiś moduł.

Nie mogę zreplikować problemu na lokalnym urządzeniu deweloperskim lub na serwerze UAT. DB na UAT ma 2 tygodnie od daty na żywo, więc może to wskazywać na problem / ustawienie db?

Rzeczy, których próbuję: jestem zajęty przeciąganiem aktualnej bazy danych na żywo do UAT, aby uzyskać aktualność, aby sprawdzić, czy mogę tam odtworzyć problem. zaktualizuje się po zakończeniu.

Gdy będę mógł powtórzyć problem w obszarze nieżywym, będę systematycznie wyłączać moduły, sprawdzać, czy coś się nie kręci z identyfikatorami sklepu (zaczynając od MageMonkey i Sweettooth, ponieważ zostały zaktualizowane 2 tygodnie temu)

Pytanie brzmi - co jeszcze mogę spróbować? Jakieś wskazówki, w których mogę walnąć niektóre punkty przerwania i krok kodu, aby sprawdzić, czy mogę wyśledzić ten problem?

nie ma zainstalowanych dodatkowych systemów pamięci podręcznej, takich jak lakier lub memcache. Serwer jest standardową instalacją cpanel. testując na uat wyłączyłem całą pamięć podręczną.

dalsza aktualizacja: wydaje się, że kiedy przejdę do domyślnego motywu, nie będę mógł go odtworzyć. Systematycznie cofam foldery zastępujące motywy.

Użyłem również git do wycofania kodu, a problem występuje z każdym haszowaniem.

Aktualizacja: Minęło trochę czasu, odkąd miałem na to czas. Wysokie obciążenie pracą.

Przeniosłem sesje do pliku i problem zniknął. Ponieważ klient nie zamierza używać wielu serwerów w najbliższej przyszłości, a ze względu na moje obciążenie pracą, zostało to pozostawione. Najprawdopodobniej wróci mnie ugryźć później.

obsługa magento zasugerowała, że ​​problem dotyczy modułu łakomczucha rozszerzającego klasy sesji, ale ten moduł został wyłączony i problem pozostał.

zaktualizuje się, gdy otrzymam więcej wyników.

ProxiBlue
źródło
„Użyj SID w interfejsie użytkownika” w rzeczywistości nie rozwiązało problemu. Wygląda na to, że problem jest losowy. Działa dobrze dla niektórych sesji, upuszcza dla innych.
ProxiBlue
Mogę teraz niezawodnie powielić to na UAT. Wygląda na to, że 8/10 prób dodania do koszyka ma ten problem. Następnie sesja „trzyma się” i wszystko działa normalnie. Wyeliminowano SweetTooth i MageMonkey jako przyczyny (po ich aktualizacji) Potwierdzono, że jest to problem z sesją. Kiedy dodam do koszyka, mam sesję z jednym identyfikatorem, kiedy idę do koszyka, dostaję nowy identyfikator sesji.
ProxiBlue
Niektórzy koledzy napotkali prawie identyczny problem. Nie wiem dokładnie, co spowodowało problem (wiem, że było to związane z memcache i / lub lakierem), ale rozwiązaniem było ustawienie modułu równoważenia obciążenia dla serwerów. Dlatego powinieneś porozmawiać o tym z administratorem serwera.
Vlad Preda
1
Co to jest wersja Magento? Czego używasz jako miejsca do przechowywania sesji? Czy przejście odpowiednio do plików lub bazy danych robi różnicę?
Kristof w Fooman
@Fooman Cześć, EE 1.11.2.0, używając sesji DB, nie próbowałem zamiany na pliki, poinformuje z powrotem, jaki daje wynik.
ProxiBlue

Odpowiedzi:

8

W naszych pudełkach cPanel brakujące zasoby obsługiwały całą stronę Magento.

cPanel ma domyślną wartość, ErrorDocument 404 /404.shtmlale /404.shtmlnie istnieje w katalogu głównym Magento, więc .htaccess zostaje ponownie wykonany i przekierowuje /404.shtmlna index.php(używając mod_rewrite).

Domyślny plik .htaccess w Magento powinien wyraźnie określać 404, 500 i inne programy obsługi błędów.

Aby rozwiązać ten problem, do naszego .htaccess dodaliśmy następujące elementy:

ErrorDocument 404 /errors/404.php

Prawdopodobnie powinniśmy również dodać 500s:

ErrorDocument 500 /errors/500.php

jmlnik
źródło
@ProxiBlue czy to rozwiązało problem, ponieważ jest to zaakceptowana odpowiedź? Mam prawie identyczny problem. Nadal nie jestem pewien, co go powoduje.
dchayka
9

Czy używasz Varnish na serwerze?

Widzieliśmy wiele implementacji, w których ludzie usuwają plik cookie PRZED pobieraniem zawartości statycznej (images / css / js) - więc jeśli obraz / js / css nie istnieje; ładuje bootstrap i 404 Magento - całkowicie usuwając pliki cookie i sesję witryny.

Ben Lessani - Sonassi
źródło
Bez lakieru, szkoda, że ​​to nie jest takie proste: (
ProxiBlue
Cześć, mam ten sam problem. Czy mogę wiedzieć, jakie jest rozwiązanie?
Kandarp B Patel
@ Ben Proszę o rozwinięcie tego.
burntblark
6

Jednym z problemów może być to, że Magento nie zapisuje danych sesji podczas przełączania z HTTP na HTTPS . Upewnij się, że niezbędne ustawienia SSL itp. Są poprawnie skonfigurowane.

Innym problemem może być to, że dostawca usług internetowych klienta zmienia swój adres IP, zgodnie z dokumentacją tutaj .

Aby rozwiązać ten problem:

Zmień ustawienia sprawdzania poprawności sesji w Administratorze Magento, znajdującym się w System> Konfiguracje> Internet , na „nie” we wszystkim oprócz „ Sprawdź poprawność HTTP_USER_AGENT ”. Po wykonaniu tej czynności przejdź do System> Zarządzanie pamięcią podręczną i odśwież pamięć podręczną konfiguracji, aby zastosować zmiany.

pzirkind
źródło
Koszyk jest nadal w http, dlatego nie występuje problem z http-> https.
ProxiBlue
1
Dzieje się tak również w naszym środowisku UAT i mamy stały adres IP. Doceń sugestie.
ProxiBlue
5

Zauważyliśmy ten problem, gdy na stronie brakuje obrazu, szczególnie jeśli obrazu brakuje na wszystkich stronach, np. W nagłówku lub stopce. Wygląda na to, że strona 404, którą zwraca Magento lub serwer WWW, psuje plik cookie sesji frontendu, co prowadzi do utraty sesji. Jest na naszej liście rzeczy do naprawienia, ale obejście polega na tym, aby upewnić się, że nie brakuje brakujących obrazów ...

Jonathan Day
źródło
Cieszę się, że nie dzieje się tak u niektórych naszych klientów. Więcej 404, niż chcę przyznać.
philwinkle
2
@jonathanday Magento tego nie zrobi, ale źle skonfigurowany lakier.
Ben Lessani - Sonassi
@sonassi, czy możesz rozwinąć na źle skonfigurowanym Varnish pls? Mamy ten sam problem. Naprawienie strony 404 rozwiązało problem, ale chcielibyśmy wiedzieć, czy możemy lepiej skonfigurować Lakier!
jmlnik
Tak właśnie się działo. Jakoś przegapiłem tę odpowiedź! Faktem jest, że Magento nie powinien przesuwać wersji strony 404 kontrolera, ale statyczną stronę 404.
ProxiBlue
1
Zamieściłem odpowiedź, która to wyjaśnia.
Ben Lessani - Sonassi
1

Może to być problem z datą pliku cookie / serwera. Pierwszą rzeczą do sprawdzenia są nagłówki plików cookie. Sprawdź nagłówki (używając czegoś takiego jak Firebug, Charles lub Fiddler).

Powinieneś zobaczyć coś takiego:

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

Jeśli wartość pola wygasła jest w przeszłości, istnieje prawdopodobieństwo, że czas na serwerze jest nieprawidłowy. Może się to zdarzyć, gdy usługi takie jak NTTP nie zostaną uruchomione. W takim przypadku sprawdź czas na serwerze. Jeśli czas jest wyłączony, sprawdź status ntpd (lub dowolnej innej usługi demona, aby aktualizować czas serwera).

beeplogic
źródło
Sprawdzone, data / czas serwera, jeśli jest w porządku, data / czas pliku cookie jest w porządku :(
ProxiBlue
1

Śmieciowanie PHP przedwcześnie usuwa sesje. Widziałem to sam na stronach o dużym natężeniu ruchu .

Niektóre wskazówki dotyczące rozwiązywania problemów:

  • Ile lat ma Twoja najstarsza sesja? Aby dowiedzieć się: ls -laht [mageroot]/var/session/ | tail- jeśli nie masz sesji trwających dłużej niż kilka tygodni, winą może być wywóz śmieci
  • Tymczasowo przenieś sesje do innego magazynu danych - na przykład MySQL lub Memcached. Czy problem został rozwiązany?
  • Czy dzieje się to na serwerze programistycznym? Jeśli nie, a wszystkie rzeczy są takie same, poziomy ruchu mogą powodować przedwczesne wygaśnięcie sesji lub wyrzucanie elementów bezużytecznych

Naprawiłem to na jeden z dwóch sposobów:

  1. W swoim .htaccess dodaj php_value session.gc_maxlifetime 2592000
  2. W swoim php.ini ustaw session.gc_maxlifetime

Więcej lektur: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

philwinkle
źródło
1
Dobre sugestie. Spróbuję za kilka dni
ProxiBlue
1

Mieliśmy podobny problem. W naszym przypadku była to konfiguracja lakieru (jak sugerował Ben Lessani). Skonfigurowaliśmy nasz Lakier do buforowania 404 przez 120s, aby nasze serwery nie zostały mocno uderzone, gdy na stronie występuje błąd 404.

Problem dotyczy 404 s. Magento odpowiadało za pomocą Set-Cookie w nagłówku plików cookie frontend i frontend_cid, które resetują sesję klienta.

Naszym rozwiązaniem w tym przypadku jest usunięcie dowolnych plików cookie dla 404 odpowiedzi,

unset beresp.http.set-cookie;
Thanu
źródło
0

Głupie rzeczy, które w przeszłości łamały mi sesje PHP i warto je sprawdzić:

  • pełny dysk
  • niedokładny czas serwera
xyphoid
źródło
:) najpierw sprawdziłem dysk, wszystko w porządku.
ProxiBlue
data w porządku :( nie takie proste, ugh [~ / public_html / var / log] # date Czw 31 stycznia 11:55:49 WST 2013
ProxiBlue