Panier supprimant tous les articles / la session du panier s'efface

Un site que je gère soudainement (il y a peut-être 2 semaines - d'après les statistiques GA, et qui n'a été signalé que maintenant) a commencé à supprimer les articles du panier lorsque vous affichez le panier ou passez à la caisse.

Le `` mini-panier '' supérieur affiche les articles dans la liste déroulante, jusqu'à ce que vous accédiez au panier / à la caisse, puis vous vous retrouviez sur le panier, avec le message `` Il n'y a pas d'articles dans votre panier ''.

Cela ressemble à un problème de session. Cela ne se produit pas lors de la connexion.

Suppression de toutes les options de validation de session dans 'système-> web-> paramètres de validation de session', et activé celle qui dit 'Utiliser SID sur Frontend'. Cela a résolu le problème, mais comme ces paramètres n'ont pas changé au cours des 3 derniers mois, je sais qu'il y a un problème sous-jacent.

Cela pointe alors vers un problème avec le problème sore-id? D'une manière ou d'une autre, le site perd l'ID de magasin sur lequel il se trouve et supprime les données de session / panier? Peut-être un observateur / événement / réécriture par un module.

Je ne peux pas répliquer le problème sur le développeur local ou sur le serveur UAT. La base de données sur UAT est datée de 2 semaines, donc cela pourrait indiquer un problème / paramètre db?

Choses que j'essaie: je suis occupé à tirer la base de données en direct actuelle vers UAT pour la mettre à jour, pour voir si je peux reproduire le problème là-bas. mettra à jour lorsque cela sera fait.

Une fois que je peux reproduire le problème dans une zone non active, je désactiverai systématiquement les modules, voir si quelque chose est en train de bouger avec les identifiants de magasin (en commençant par MageMonkey et sweettooth, car ils ont été mis à jour il y a 2 semaines)

La question est - que puis-je essayer d'autre? Des pointeurs vers où je peux supprimer certains points d'arrêt et parcourir le code pour voir si je peux suivre ce problème?

il n'y a pas de système de cache supplémentaire comme le vernis ou memcache installé. Le serveur est une installation cpanel standard. test sur uat j'ai désactivé tout le cache.

mise à jour supplémentaire: il semblerait que lorsque je passe au thème par défaut, je ne peux pas reproduire. Je recule systématiquement les dossiers de substitution de thème.

J'ai également utilisé git pour revenir sur le code et le problème persiste à chaque hachage.

Mise à jour: Cela fait un moment que j'ai eu le temps de passer à ce sujet. Charge de travail élevée.

J'ai déplacé les sessions vers un fichier et le problème a disparu. Étant donné que le client n'a pas l'intention d'utiliser plusieurs serveurs dans un avenir proche, et en raison de ma charge de travail, cela n'a pas été réglé. Reviendra très probablement me mordre plus tard.

Le support de magento a suggéré que le problème est lié au module Sweet tooth qui étend les classes de session, mais j'ai désactivé ce module et le problème est resté.

mettra à jour quand j'obtiens plus de résultats.

Sur nos boîtes cPanel, les actifs manquants servaient la totalité de la page Magento.

La valeur par défaut de cPanel est ErrorDocument 404 /404.shtmlmais /404.shtmln'existe pas dans la racine du document de Magento, donc le .htaccess est à nouveau exécuté et redirigé /404.shtmlvers index.php(en utilisant mod_rewrite).

Le .htaccess par défaut de Magento devrait spécifier explicitement 404, 500 et autres gestionnaires d'erreurs.

Pour résoudre ce problème, nous avons ajouté ce qui suit à notre .htaccess:

ErrorDocument 404 /errors/404.php

Nous devrions probablement aussi ajouter 500s:

ErrorDocument 500 /errors/500.php

Utilisez-vous Varnish sur le serveur?

Nous avons vu un certain nombre d'implémentations où les gens suppriment le cookie AVANT d'aller chercher du contenu statique (images / css / js) - donc si l'image / js / css n'existe pas; il charge le bootstrap Magento et les 404 - ce qui supprime entièrement le cookie et la session du site.

Un problème pourrait être que Magento n'enregistre pas les données de session lors du passage de HTTP à HTTPS . Assurez-vous que les paramètres nécessaires pour SSL, etc. sont correctement configurés.

Un autre problème pourrait être que le FAI du client modifie son adresse IP, comme indiqué ici .

Pour résoudre ce problème:

Modifiez les paramètres de validation de session dans l'administrateur Magento, trouvés sous Système> Configurations> Web , à «non» sur tout sauf « Valider HTTP_USER_AGENT ». Après cela, allez dans Système> Gestion du cache et actualisez le cache de configuration pour appliquer les modifications.

Nous avons observé ce problème lorsqu'il manque une image sur une page, en particulier si l'image manque dans toutes les pages, par exemple dans un en-tête ou un pied de page. Il semble que la page 404 renvoyée par Magento ou le serveur Web casse le cookie de session frontale, entraînant une perte de session. C'est sur notre liste de choses à corriger, mais la solution consiste à s'assurer qu'il n'y a pas d'images manquantes ...

Cela pourrait être un problème de date de cookie / serveur. La première chose à vérifier sont les en-têtes des cookies. Inspectez les en-têtes (en utilisant quelque chose comme Firebug, Charles ou Fiddler).

Vous devriez voir quelque chose comme ceci:

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

Si la valeur du champ expire est dans le passé, il est probable que l'heure sur votre serveur soit incorrecte. Cela peut se produire lorsque des services comme ntpd ne démarrent pas. Si tel est le cas, vérifiez l'heure sur le serveur. Si l'heure est désactivée, vérifiez l'état de ntpd (ou du service démon pour garder l'heure du serveur à jour).

Le garbage collection PHP efface les sessions prématurément. Je l'ai vu moi-même sur des sites très fréquentés .

Quelques conseils de dépannage:

• Quel âge a votre plus ancienne session? Pour savoir: ls -laht [mageroot]/var/session/ | tail- si vous n'avez pas de sessions de plus de quelques semaines, la collecte des ordures est susceptible de blâmer
• Déplacez temporairement les sessions vers un autre magasin de données - MySQL ou Memcached, par exemple. Le problème est-il résolu?
• Est-ce que cela se produit sur un serveur de développement? Si non, et toutes choses égales par ailleurs, il se peut que les niveaux de trafic déclenchent une expiration de session prématurée ou une récupération de place

J'ai corrigé cela de deux manières:

1. Dans votre .htaccess, ajoutez php_value session.gc_maxlifetime 2592000
2. Dans votre php.ini, définissez session.gc_maxlifetime

Plus de lecture: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Nous avons eu un problème similaire. Dans notre cas, c'était la configuration Varnish (comme Ben Lessani - le suggérait). Nous avons configuré notre Varnish pour mettre en cache les 404 pendant 120 afin que nos serveurs ne soient pas mal martelés en cas d'erreur 404 sur une page.

Le problème concerne donc les 404 Magento répondait avec un Set-Cookie dans l'en-tête des cookies frontend et frontend_cid, qui réinitialise la session client.

Notre solution pour celui-ci est de supprimer tout Set-Cookies pour 404 réponses,

unset beresp.http.set-cookie;

Bêtises qui ont cassé des sessions PHP pour moi dans le passé et qui méritent d'être vérifiées:

• un disque plein
• heure imprécise du serveur