购物车删除所有商品/购物车会话清除


27

当您查看购物车或去结帐时,我突然管理的一个网站(可能是2周前-根据GA统计信息,现在才报告)开始放下购物车物品。

顶部的“迷你购物车”会在下拉菜单中显示商品,直到您浏览到购物车/结帐,然后您最终在购物车上看到“购物车中没有商品”消息。

似乎是一个会话问题。登录时不会发生。

删除了“系统->网络->会话验证设置”中的所有会话验证选项,并启用了“在前端使用SID”选项。这确实解决了问题,但是由于这些设置在过去3个月中没有更改,因此我知道存在一些潜在问题。

那么这指向带有酸痛问题的问题吗?该网站以某种方式失去了它所在的商店ID,并删除了会话/购物车数据?也许是某些模块的某些观察者/事件/重写。

我无法在本地开发人员或UAT服务器上复制该问题。UAT上的数据库是从生效日期算起的2周,因此这可能指向数据库问题/设置吗?

我正在尝试的事情:我正忙于将当前的实时数据库移至UAT以获取最新信息,以查看是否可以在此处复制该问题。完成后将更新。

一旦我可以在非活动区域复制问题,就可以系统地禁用模块,看看商店ID是否有问题(从MageMonkey和sweettooth开始,因为它们是在2周前更新的)

问题是-我还能尝试什么?是否有任何指向我可以在其中闯入一些断点并逐步执行代码的指针,以查看是否可以跟踪此问题?

没有安装额外的缓存系统,例如清漆或内存缓存。服务器是标准的cpanel安装。在uat上测试我禁用了所有缓存。

进一步更新:当我使用默认主题时,似乎无法复制。我正在系统地将主题覆盖文件夹移回。

我还使用git来回溯代码,每个哈希都存在问题。

更新:自从我有时间花时间以来,已经有一段时间了。高工作量。

我将会话移至基于文件的会话,问题已消失。由于客户端不打算在不久的将来使用多台服务器,并且由于我的工作量,该留在那儿了。以后很可能会再咬我。

magento支持建议该问题与扩展会话类的甜食模块有关,但是我已禁用了该模块,并且问题仍然存在。

当我得到更多结果时将更新。


实际上,“在前端使用SID”并不能解决问题。似乎问题是随机的。对于某些会话效果很好,对于其他会话效果很好。
ProxiBlue

我现在可以在UAT上可靠地复制它。似乎有8/10次尝试添加到购物车的过程中出现了此问题。然后会话“粘滞”,一切正常。消除了SweetTooth和MageMonkey的原因(升级后)确认这是会话问题。当我添加到购物车时,我有一个具有一个ID的会话,当我查看购物车时,我得到了新的会话ID。
ProxiBlue

一些同事遇到了几乎相同的问题。我不知道是什么引起了问题(我知道这与内存缓存和/或清漆有关),但是解决方案是为服务器设置负载均衡器。因此,您应该与服务器管理员联系。
Vlad Preda

1
magento版本是什么?您还用什么作为会话存储?分别切换到文件或数据库有区别吗?
克里斯托夫在Fooman,2013年

@Fooman您好,EE 1.11.2.0使用DB会话,尚未尝试交换到文件,将报告返回的结果。
ProxiBlue

Answers:


8

在我们的cPanel框上,缺少的资产正服务于整个Magento页面。

cPanel的默认值为,ErrorDocument 404 /404.shtml/404.shtml在Magento的文档根目录中不存在,因此.htaccess会再次执行并重定向/404.shtmlindex.php(使用mod_rewrite)。

Magento的默认.htaccess应该明确指定404、500和其他错误处理程序。

为了解决这个问题,我们在.htaccess文件中添加了以下内容:

ErrorDocument 404 /errors/404.php

我们可能还应该加上500:

ErrorDocument 500 /errors/500.php


@ProxiBlue是否已解决您的问题,因为这是公认的答案?我有几乎相同的问题。仍然不确定是什么原因造成的。
dchayka

9

您在服务器上使用Varnish吗?

我们已经看到了许多实现,人们可以在获取静态内容(images / css / js)之前剥离cookie-因此,如果image / js / css不存在;它会加载Magento引导程序和404,这会完全剥离Cookie和站点会话。


没有清漆,希望它是如此简单:'(
ProxiBlue

嗨,我有同样的问题,我知道解决方案是什么?
Kandarp B Patel

@Ben请您详细说明一下。
burntblark

6

一个问题可能是Magento从HTTP切换到HTTPS时没有保存会话数据。确保正确设置了SSL等的必要设置。

另一个问题可能是客户的ISP正在更改其ip地址,如此处所述

要解决此问题:

在“ 系统>配置> Web ” 下的Magento Admin中,将“会话验证”设置更改为“否”,除了“ Validate HTTP_USER_AGENT ” 之外的所有内容都设置为“ no” 。执行此操作后,转到“ 系统”>“缓存管理”并刷新配置缓存以应用更改。


购物车仍在http中,因此不是http-> https问题。
ProxiBlue

1
它在我们的UAT环境中也正在发生,并且我们有固定的ip。欣赏建议。
ProxiBlue

5

当页面上缺少图像时,尤其是在所有页面(例如,页眉或页脚)中都缺少图像时,我们已经观察到此问题。看来,Magento或Web服务器返回的404页面破坏了前端会话cookie,从而导致会话丢失。它在我们要修复的事情上,但是解决方法是确保没有丢失的图像...


我很高兴某些客户没有发生这种情况。404数量超出了我的意愿。
philwinkle

2
@jonathanday Magento不会这样做,但是配置错误的Varnish会这样做。
Ben Lessani-索纳西

@sonassi,可以扩展配置错误的Varnish pls吗?我们一直遇到同样的问题。修复404页面已解决了问题,但很想知道我们是否可以更好地配置Varnish!
jmlnik

实际上这就是正在发生的事情。我莫名其妙地错过了这个答案!事实是magento不应推送404页面的控制器版本,而应推送静态404页面。
ProxiBlue 2013年

1
我发布了一个解释它的答案。
Ben Lessani-Sonassi

1

这可能是Cookie /服务器日期问题。首先要检查的是cookie标头。检查标题(使用诸如Firebug,Charles或Fiddler之类的东西)。

您应该看到类似以下的内容:

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

如果expires字段的值是过去的,则可能是服务器上的时间错误。当ntpd之类的服务无法启动时,可能会发生这种情况。如果是这种情况,请检查服务器上的时间。如果时间不对,请检查ntpd的状态(或使用任何守护程序服务来更新服务器的时间)。


检查,服务器日期/时间是否正确,cookie日期/时间是否
合适

1

PHP垃圾回收会过早清除会话。我本人已经在人流量大的站点上看到了这一点。

一些故障排除提示:

  • 您最老的课程多大了?要了解以下内容:ls -laht [mageroot]/var/session/ | tail-如果您的会话时间不超过几周左右,则可能是垃圾回收的原因
  • 将会话临时移动到另一个数据存储-例如MySQL或Memcached。问题解决了吗?
  • 这是在开发服务器上发生的吗?如果否,并且所有条件都相等,则可能是流量水平触发了会话过早过期或垃圾回收

我已通过以下两种方法之一解决了此问题:

  1. 在您的.htaccess中,添加 php_value session.gc_maxlifetime 2592000
  2. 在您的php.ini中,设置session.gc_maxlifetime

更多阅读:http : //www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime


1
好建议。将在几天内尝试
ProxiBlue

1

我们有一个类似的问题。在我们的案例中,它是Varnish的配置(就像Ben Lessani一样)。我们已将Varnish配置为可将404缓存120秒,以便当页面上出现404错误时,我们的服务器不会受到严重影响。

因此,问题出在404s上,Magento在前端和frontend_cid cookie的标头中使用Set-Cookie进行响应,从而重置了客户会话。

我们针对这一问题的解决方案是剥离任何Set-Cookies以获得404响应,

unset beresp.http.set-cookie;

0

过去曾为我破坏了PHP会话的愚蠢的事情,可能值得检查:

  • 完整的磁盘
  • 服务器时间不正确

:)检查磁盘第一件事,一切正常。
ProxiBlue

日期好:(不是那么简单,嗯[〜/ public_html / var / log]#date 2013
ProxiBlue
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.