カートのすべてのアイテムのドロップ/カートセッションのクリア

私が突然管理するサイト（2週間前-GA統計から、現在のみ報告されている）が、カートを表示するか、チェックアウトに行くと、カートのアイテムをドロップし始めました。

一番上の「ミニカート」には、カート/チェックアウトを参照し、「カートにアイテムがありません」というメッセージが表示されるまで、ドロップダウンにアイテムが表示されます。

セッションの問題のようです。ログインしても発生しません。

「システム->ウェブ->セッション検証設定」のすべてのセッション検証オプションを削除し、「フロントエンドでSIDを使用」というオプションを有効にしました。これで問題は解決しましたが、これらの設定は過去3か月間変更されていないため、根本的な問題があることがわかります。

これは、sore-id問題の問題を示していますか？どういうわけか、サイトはどのストアIDを失い、セッション/カートデータをドロップしていますか？たぶん、いくつかのモジュールによるいくつかのオブザーバー/イベント/書き換え。

ローカルdevまたはUATサーバーで問題を再現できません。UAT上のDBはライブから2週間であるため、これはdbの問題/設定を指している可能性がありますか？

私がやろうとしていること：現在のライブデータベースをUATに移動して最新の状態にして、そこで問題を再現できるかどうかを確認しています。それが完了すると更新されます。

非ライブ領域で問題を再現できるようになったら、モジュールを体系的に無効にし、ストアIDに問題があるかどうかを確認します（2週間前に更新されたため、MageMonkeyとsweettoothで始まります）

質問は-他に何ができますか？いくつかのブレークポイントを叩き、コードをステップ実行してこの問題をトレースできるかどうかを確認できる場所へのポインターはありますか？

ニスやmemcacheのような追加のキャッシュシステムはインストールされていません。サーバーは標準のcpanelインストールです。uatでテストすると、すべてのキャッシュが無効になりました。

さらに更新：デフォルトのテーマにドロップすると、再現できないようです。テーマオーバーライドフォルダーを体系的に移動しています。

また、コードをバックトラックするためにgitを使用しましたが、すべてのハッシュに問題が残っています。

更新：これに時間を費やしてからしばらく経ちました。高い作業負荷。

セッションをファイルベースに移動し、問題はなくなりました。クライアントは近い将来に複数のサーバーを使用するつもりはないので、私の作業負荷のために、これは残されました。後で私に噛み付く可能性が高いでしょう。

magentoサポートは、この問題がセッションクラスを拡張するスイートトゥースモジュールに関連していることを示唆しましたが、そのモジュールを無効にしましたが、問題は残りました。

より多くの結果が得られたら更新されます。

cPanelボックスでは、不足しているアセットがMagentoページ全体に配信されていました。

cPanelのデフォルト値ErrorDocument 404 /404.shtmlが、/404.shtml.htaccessファイルを再度実行するとリダイレクトされますので、Magentoののドキュメントルートに存在しない/404.shtmlとindex.php（のmod_rewriteを使用）。

Magentoのデフォルトの.htaccessでは、404、500、およびその他のエラーハンドラを明示的に指定する必要があります。

この動作を修正するために、.htaccessに次を追加しました。

ErrorDocument 404 /errors/404.php

おそらく500も追加する必要があります。

ErrorDocument 500 /errors/500.php

サーバーでVarnishを使用していますか？

静的コンテンツ（images / css / js）でフェッチする前にCookieを削除する実装が多数見られました。そのため、image / js / cssが存在しない場合、Magentoブートストラップと404をロードします。これにより、Cookieとサイトセッションが完全に削除されます。

1つの問題は、MagentoがHTTPからHTTPSに切り替えるときにセッションデータを保存しないことです。SSLなどに必要な設定が適切に設定されていることを確認してください。

別の問題は、ここに記載されているように、顧客のISPがIPアドレスを変更していることです。

この問題を修正するには：

System> Configurations> Webの下にあるMagento AdminのSession Validation設定を「Validate HTTP_USER_AGENT」以外のすべてで「no」に変更します。これを行った後、System> Cache Managementに移動し、設定キャッシュを更新して変更を適用します。

ページに画像がない場合、特にヘッダーやフッターなどのすべてのページに画像がない場合に、この問題が確認されています。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

expiresフィールドの値が過去の場合、サーバーの時間が間違っている可能性があります。これは、ntpdなどのサービスの開始に失敗した場合に発生する可能性があります。その場合は、サーバーの時刻を確認してください。時間がオフの場合は、ntpd（またはサーバーの時間を更新するデーモンサービス）のステータスを確認します。

PHPガベージコレクションは、セッションを早期にクリアします。私は自分でこれをトラフィックの多いサイトで見ました。

トラブルシューティングのヒント：

• 最も古いセッションは何歳ですか？確認するには：ls -laht [mageroot]/var/session/ | tail-数週間以上のセッションがない場合、ガベージコレクションが原因である可能性が高い
• セッションを一時的に別のデータストア（MySQLやMemcachedなど）に移動します。問題は解決しましたか？
• これは開発サーバーで発生していますか？いいえ、すべてが等しい場合、トラフィックレベルがセッションの早期終了またはガベージコレクションをトリガーしている可能性があります

これを次の2つの方法のいずれかで修正しました。

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

同様の問題がありました。私たちの場合、それはワニス構成でした（ベン・レッサニのように-提案していました）。120秒間404をキャッシュするようにVarnishを設定し、ページで404エラーが発生したときにサーバーがひどく打撃を受けないようにしました。

そのため、問題は404の場合です。Magentoは、フロントエンドCookieとfrontend_cid CookieのヘッダーにSet-Cookieを使用して応答し、顧客セッションをリセットしました。

これに対する私たちの解決策は、404応答のSet-Cookieを削除することです。

unset beresp.http.set-cookie;

過去にPHPセッションが壊れており、チェックする価値があるかもしれない愚かなこと：

• フルディスク
• 不正確なサーバー時間