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

27

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.

ProxiBlue
la source
'Utiliser SID sur Frontend' n'a en fait pas résolu le problème. Il semble que le problème soit aléatoire. Fonctionne bien pour certaines sessions, gouttes pour d'autres.
ProxiBlue
Je peux répliquer de manière fiable sur UAT maintenant. Il semble que 8/10 tentatives d'ajout au panier aient ce problème. Ensuite, la session «colle» et tout fonctionne comme d'habitude. Élimination de SweetTooth et MageMonkey comme raisons (après leur mise à niveau) Confirmé qu'il s'agit d'un problème de session. Quand j'ajoute au panier, j'ai une session avec un ID, quand je vais voir le panier, j'obtiens un nouvel identifiant de session.
ProxiBlue
Certains collègues ont rencontré un problème presque identique. Je ne sais pas exactement ce qui a causé le problème (je sais qu'il était lié au memcache et / ou au vernis), mais la solution mettait en place un équilibreur de charge pour le ou les serveurs. Vous devriez donc en parler à votre administrateur de serveur.
Vlad Preda
1
Qu'est-ce que la version magento? De plus, qu'utilisez-vous comme stockage de session? Le passage à des fichiers ou à une base de données respectivement fait-il une différence?
Kristof à Fooman le
@Fooman Salut, EE 1.11.2.0, en utilisant une session DB, n'a pas essayé de permuter vers des fichiers, rendra compte du résultat que cela donne.
ProxiBlue

Réponses:

8

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

jmlnik
la source
@ProxiBlue est-ce que cela a résolu votre problème puisque c'est la réponse acceptée? J'ai un problème presque identique. Je ne sais toujours pas ce qui en est la cause.
dchayka
9

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.

Ben Lessani - Sonassi
la source
Pas de vernis,
j'aurais
Salut j'ai le même problème, puis-je savoir quelle est la solution?
Kandarp B Patel
@Ben Pouvez-vous nous en dire plus?
burntblark
6

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.

pzirkind
la source
Le panier est toujours en http, donc pas en question http-> https.
ProxiBlue
1
Cela nous arrive, dans notre environnement UAT également, et nous avons une adresse IP fixe. Appréciez les suggestions.
ProxiBlue
5

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

Jonathan Day
la source
Je suis heureux que cela ne se produise pas pour certains de nos clients. Plus de 404 que je ne veux l'admettre.
philwinkle
2
@jonathanday Magento ne le fera pas, mais Varnish mal configuré le fera.
Ben Lessani - Sonassi
@sonassi, pouvez-vous développer les pls de Varnish mal configurés? Nous avons eu le même problème. La correction de la page 404 a résolu le problème, mais j'aimerais savoir si nous pouvons mieux configurer Varnish!
jmlnik
C'était en fait ce qui se passait. J'ai en quelque sorte raté cette réponse! Le fait est que magento ne devrait pas pousser la version contrôleur de la page 404, mais une page 404 statique.
ProxiBlue
1
J'ai posté une réponse qui l'explique.
Ben Lessani - Sonassi
1

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

beeplogic
la source
Vérifié, la date / heure du serveur est
correcte
1

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

philwinkle
la source
1
Bonnes suggestions. Va essayer dans quelques jours
ProxiBlue
1

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;
Que toi
la source
0

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
xyphoïde
la source
:) vérifié d'abord le disque, tout va bien.
ProxiBlue
date fine :( pas si simple que ça, ugh [~ / public_html / var / log] # date jeu 31 jan 11:55:49 WST 2013
ProxiBlue