Der Warenkorb lässt alle Artikel fallen / die Warenkorbsitzung wird gelöscht

Question

Eine Website, die ich verwalte, hat plötzlich (möglicherweise vor 2 Wochen – laut GA-Statistiken und erst jetzt gemeldet) damit begonnen, die Warenkorbartikel zu löschen, wenn Sie den Warenkorb anzeigen oder zur Kasse gehen.

Im oberen „Mini-Warenkorb“ werden die Artikel im Dropdown-Menü angezeigt, bis Sie zum Warenkorb/zur Kasse navigieren und dann im Warenkorb landen und die Meldung „Es sind keine Artikel in Ihrem Warenkorb“ angezeigt wird.

Scheint ein Sitzungsproblem zu sein.Dies geschieht nicht, wenn Sie angemeldet sind.

Alle Sitzungsvalidierungsoptionen unter „System->Web->Sitzungsvalidierungseinstellungen“ wurden entfernt und die Option „SID im Frontend verwenden“ aktiviert.Dadurch wurde das Problem zwar gelöst, aber da sich diese Einstellungen in den letzten drei Monaten nicht geändert haben, weiß ich, dass ein zugrunde liegendes Problem vorliegt.

Das deutet dann auf ein Problem mit der Wund-ID hin?Irgendwie verliert die Website die Store-ID, auf der sie sich befindet, und die Sitzungs-/Warenkorbdaten?Vielleicht ein Beobachter/Ereignis/Umschreiben durch ein Modul.

Ich kann das Problem nicht auf einem lokalen Entwickler oder einem UAT-Server reproduzieren.DB auf UAT ist seit 2 Wochen in Betrieb, das könnte also auf ein DB-Problem/eine DB-Einstellung hinweisen?

Dinge, die ich versuche:Ich bin damit beschäftigt, die aktuelle Live-Datenbank zu UAT zu übertragen, um sie auf den neuesten Stand zu bringen und zu sehen, ob ich das Problem dort reproduzieren kann.wird aktualisiert, wenn das erledigt ist.

Sobald ich das Problem in einem nicht aktiven Bereich reproduzieren kann, werde ich Module systematisch deaktivieren und prüfen, ob mit den Store-IDs etwas nicht stimmt (beginnend mit MageMonkey und Sweettooth, da sie vor zwei Wochen aktualisiert wurden).

Die Frage ist: Was kann ich sonst noch versuchen?Gibt es Hinweise darauf, wo ich einige Haltepunkte aktivieren und den Code schrittweise ausführen kann, um zu sehen, ob ich dieses Problem zurückverfolgen kann?

Es sind keine zusätzlichen Cache-Systeme wie Lack oder Memcache installiert.Server ist eine Standard-Cpanel-Installation.Beim Testen auf uat habe ich den gesamten Cache deaktiviert.

weiteres Update:Es scheint, dass ich es nicht reproduzieren kann, wenn ich zum Standarddesign zurückkehre.Ich verschiebe systematisch Theme-Override-Ordner nach hinten.

Ich habe auch Git verwendet, um den Code zurückzuverfolgen, und das Problem bleibt bei jedem Hash bestehen.

Aktualisieren:Es ist schon eine Weile her, seit ich Zeit dafür hatte.Hohe Arbeitsbelastung.

Ich habe die Sitzungen auf dateibasiert umgestellt und das Problem ist behoben.Da der Kunde in naher Zukunft nicht beabsichtigt, mehrere Server zu nutzen, und aufgrund meiner Arbeitsbelastung, wurde dies dabei belassen.Werde höchstwahrscheinlich später noch einmal zurückkommen, um mich zu beißen.

Der Magento-Support hat vorgeschlagen, dass das Problem mit dem Sweet-Tooth-Modul zur Erweiterung der Sitzungsklassen zusammenhängt, aber ich habe dieses Modul deaktiviert und das Problem blieb bestehen.

Ich werde es aktualisieren, sobald ich weitere Ergebnisse erhalte.

Answer 1

Auf unseren cPanel-Boxen stellten fehlende Assets die gesamte Magento-Seite bereit.

Die Standardeinstellung von cPanel ist ErrorDocument 404 /404.shtml Aber /404.shtml existiert nicht im Dokumentstammverzeichnis von Magento, daher wird die .htaccess-Datei erneut ausgeführt und umgeleitet /404.shtml Zu index.php (mit mod_rewrite).

Magentos Standard-.htaccess sollte 404, 500 und andere Fehlerhandler explizit angeben.

Um dieses Verhalten zu beheben, haben wir Folgendes zu unserer .htaccess hinzugefügt:

ErrorDocument 404 /errors/404.php

Wir sollten wahrscheinlich auch 500er hinzufügen:

ErrorDocument 500 /errors/500.php

Answer 2

Verwenden Sie Varnish auf dem Server?

Wir haben eine Reihe von Implementierungen gesehen, bei denen Leute das Cookie entfernen, BEVOR sie statische Inhalte (images/css/js) abrufen – wenn also das image/js/css nicht existiert;Es lädt den Magento-Bootstrap und 404, wodurch das Cookie und die Site-Sitzung vollständig entfernt werden.

Answer 3

Ein Problem könnte sein, dass Magento die Sitzungsdaten beim Wechsel nicht speichert HTTP Zu HTTPS.Stellen Sie sicher, dass die notwendigen Einstellungen für SSL etc.richtig eingerichtet sind.

Ein weiteres Problem könnte sein, dass der ISP des Kunden, wie dokumentiert, seine IP-Adresse ändert Hier.

Um dieses Problem zu beheben:

Ändern Sie die Sitzungsvalidierungseinstellungen im Magento Admin, zu finden unter System > Konfigurationen > Web, zu „Nein“ bei allem außer „Validieren Sie HTTP_USER_AGENT. ““ Danach gehen Sie zu System > Cache-Verwaltung und aktualisieren Sie den Konfigurationscache, um die Änderungen zu übernehmen.

Answer 4

Wir haben dieses Problem beobachtet, wenn auf einer Seite ein Bild fehlt, insbesondere wenn das Bild auf allen Seiten fehlt, z. B.in einer Kopf- oder Fußzeile.Es scheint, dass die 404-Seite, die entweder Magento oder der Webserver zurückgibt, das Frontend-Sitzungscookie unterbricht, was zu einem Sitzungsverlust führt.Es steht auf unserer Liste der zu behebenden Probleme, aber die Problemumgehung besteht darin, sicherzustellen, dass keine Bilder fehlen ...

Answer 5

Dies könnte ein Problem mit dem Cookie/Serverdatum sein.Als erstes sollten Sie die Cookie-Header überprüfen.Überprüfen Sie die Header (mit etwas wie Firebug, Charles oder Fiddler).

Sie sollten etwa Folgendes sehen:

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

Wenn der Wert für das Ablauffeld in der Vergangenheit liegt, ist die Zeit auf Ihrem Server wahrscheinlich falsch.Dies kann passieren, wenn Dienste wie ntpd nicht gestartet werden können.Überprüfen Sie in diesem Fall die Uhrzeit auf dem Server.Wenn die Zeit abgelaufen ist, überprüfen Sie den Status von ntpd (oder dem Daemon-Dienst, der die Serverzeit auf dem neuesten Stand hält).

Answer 6

PHP-Garbage Collection räumt die Sitzungen vorzeitig ab.Ich habe das selbst gesehen stark frequentierte Websites.

Einige Tipps zur Fehlerbehebung:

• Wie alt ist Ihre älteste Sitzung?Herausfinden: ls -laht [mageroot]/var/session/ | tail - Wenn Sie keine Sitzungen haben, die länger als ein paar Wochen dauern, ist wahrscheinlich die Speicherbereinigung dafür verantwortlich
• Verschieben Sie Sitzungen vorübergehend in einen anderen Datenspeicher – zum Beispiel MySQL oder Memcached.Ist das Problem gelöst?
• Passiert das auf einem Entwicklungsserver?Wenn nein, und alle Dinge gleich sind, kann es sein, dass das Verkehrsaufkommen einen vorzeitigen Sitzungsablauf oder eine Speicherbereinigung auslöst

Ich habe dies auf eine von zwei Arten behoben:

1. Fügen Sie in Ihrem .htaccess Folgendes hinzu: php_value session.gc_maxlifetime 2592000
2. Legen Sie in Ihrer php.ini session.gc_maxlifetime fest

Mehr Lektüre: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Answer 7

Wir hatten ein ähnliches Problem.In unserem Fall war es die Lackkonfiguration (wie Ben Lessani vorschlug).Wir haben unseren Varnish so konfiguriert, dass 404-Fehler 120 Sekunden lang zwischengespeichert werden, damit unsere Server nicht stark belastet werden, wenn auf einer Seite ein 404-Fehler auftritt.

Das Problem liegt also bei 404s. Magento hat mit einem Set-Cookie im Header für Frontend- und frontend_cid-Cookies geantwortet, das die Kundensitzung zurücksetzt.

Unsere Lösung für dieses Problem besteht darin, alle Set-Cookies für 404-Antworten zu entfernen.

unset beresp.http.set-cookie;

Answer 8

Dumme Dinge, die bei mir in der Vergangenheit PHP-Sitzungen kaputt gemacht haben und die es wert sein könnten, überprüft zu werden:

• eine volle Festplatte
• Ungenaue Serverzeit