推车丢弃所有项目 /购物车会话清除

magento.stackexchange https://magento.stackexchange.com/questions/385

  •  16-10-2019
  •  | 
  •  

题

我突然管理的一个网站（可能是2周前 - 从GA统计数据，并且仅报告）在您查看购物车或进行结帐时开始丢弃购物车。

顶部的“迷你卡特”显示了下拉列表中的项目，直到您浏览购物车/结帐为止，然后您最终进入购物车，并带有“购物车中没有项目”的消息。

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

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

然后这指出了疼痛ID问题的问题？以某种方式，该网站正在丢失它在哪个店里，并删除会话/购物车数据？也许是某个模块的观察者/事件/重写。

我无法在本地开发人员或UAT服务器上复制问题。 UAT上的DB是Live的2周，所以这可能指向DB问题/设置？

我正在尝试的事情：我正忙于将当前的直播DB拖到UAT上，以使该问题最新，以查看我是否可以在那里复制问题。完成后将更新。

一旦我可以在非寿命区域中复制问题，我将系统地禁用模块，看看是否有商店ID的东西（从Magemonkey和Sweettooth开始），因为它们在2周前进行了更新）

问题是 - 我还能尝试什么？我可以在哪里打破一些断点，然后踩下代码以查看是否可以追踪此问题？

没有安装清漆或memcache的额外缓存系统。服务器是标准CPANEL安装。在UAT上测试我禁用所有缓存。

进一步更新：看来，当我跌入默认主题时，我无法复制。我正在系统地移动主题覆盖文件夹。

我还使用git进行回溯代码，每个哈希都存在问题。

更新：自从我有时间花钱以来已经有一段时间了。高工作负载。

我将会话移至基于文件，问题已经消失。由于客户不打算在不久的将来使用多个服务器，并且由于我的工作负载，因此剩下的。以后很可能会回来咬我。

Magento的支持表明，该问题与延长会话类的甜食模块有关，但我已禁用该模块，并且问题仍然存在。

当我获得更多结果时会更新。

有帮助吗？

解决方案

在我们的CPANEL盒子上，缺少资产提供整个Magento页面。

CPanel的默认为 ErrorDocument 404 /404.shtml 但 /404.shtml Magento的文档root中不存在，因此.htaccess再次执行并重定向 /404.shtml 至 index.php （使用mod_rewrite）。

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

为了修复此Beahviour，我们将以下内容添加到.htaccess：

ErrorDocument 404 /errors/404.php

我们可能还应该添加500秒：

ErrorDocument 500 /errors/500.php

其他提示

您在服务器上使用清漆吗？

我们已经看到了许多实现，人们在获取静态内容（图像/css/js）之前将cookie剥离了 - 因此，如果不存在image/js/css；它加载了Magento Bootstrap和404的加载 - 这完全剥离了Cookie和网站会话。

一个问题可能是Magento在从中切换时不会保存会话数据 http 至 https. 。确保正确设置了SSL等的必要设置。

另一个问题可能是客户的ISP正在更改其IP地址，如有记录 这里.

解决此问题：

更改Magento管理员中的会话验证设置， 系统>配置> Web, ，除了“不”除外验证http_user_agent。”这样做之后，去 系统>缓存管理 并刷新配置缓存以应用更改。

当页面上有缺少图像时，我们已经观察到了这个问题，尤其是当所有页面中缺少图像时，例如，标题或页脚中的图像。似乎Magento或Web服务器返回的404页破坏了前端会话cookie，从而导致会话丢失。这是我们要修复的事情列表，但是解决方法是确保没有丢失的图像...

这可能是cookie/服务器日期问题。首先要检查的是Cookie标题。检查标题（使用Firebug，Charles或Fiddler之类的内容）。

您应该看到以下内容：

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

如果过去的到期字段的值是过去的时间，那么您的服务器上的时间是错误的。当NTPD之类的服务无法启动时，这可能会发生。如果是这样，请检查服务器上的时间。如果有时间的时间，请检查NTPD的状态（或任何守护程序服务以保持服务器的时间更新）。

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

我们也有类似的问题。在我们的情况下，这是清漆配置（如Ben Lessani所建议）。我们已经将清漆配置为120s的CACHE 404s，因此当页面上有404错误时，我们的服务器不会严重锤击。

我们的解决方案是剥离404个响应的任何套餐，

unset beresp.http.set-cookie;

过去对我来说，愚蠢的事情对我来说，可能值得检查：

  • 完整的磁盘
  • 服务器时间不正确
许可以下： CC-BY-SA 和 归因
scroll top