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

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.

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

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.

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.

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 ...

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).

Ś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

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;

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