कार्ट सभी आइटम / कार्ट सत्र को साफ़ करता है


27

एक साइट जिसे मैं अचानक प्रबंधित करता हूं (संभवतः 2 सप्ताह पहले - जीए आँकड़ों से, और केवल अब रिपोर्ट की गई है) जब आप गाड़ी देखते हैं, या चेकआउट पर जाते हैं, तो कार्ट आइटम को छोड़ना शुरू कर देते हैं।

शीर्ष 'मिनी-कार्ट' ड्रॉपडाउन में आइटम दिखाता है, जब तक कि आप कार्ट / चेकआउट के लिए ब्राउज़ नहीं करते हैं, और आप तब कार्ट पर समाप्त होते हैं, जिसमें 'आपके कार्ट में कोई आइटम नहीं हैं' संदेश है।

एक सत्र मुद्दे की तरह लगता है। लॉग इन करने पर ऐसा नहीं होता है।

'सिस्टम-> वेब-> सत्र सत्यापन सेटिंग्स' में सभी सत्र सत्यापन विकल्पों को हटा दिया गया, और 'सीआईडी ​​पर फ्रंट का उपयोग करें' कहने वाले को सक्षम किया। इससे समस्या हल हो गई, लेकिन चूंकि ये सेटिंग्स पिछले 3 महीनों में नहीं बदली हैं, मुझे पता है कि कुछ अंतर्निहित मुद्दा है।

यह तो पीड़ादायक मुद्दे के साथ जारी करने के लिए अंक? किसी तरह साइट खो रही है कि यह किस स्टोर-आईडी पर है, और सत्र / कार्ट डेटा को छोड़ रहा है? हो सकता है कि कुछ मॉड्यूल द्वारा कुछ पर्यवेक्षक / घटना / फिर से लिखना।

मैं स्थानीय देव या UAT सर्वर पर समस्या को दोहरा नहीं सकता। UAT पर DB लाइव से 2 सप्ताह की अवधि है, इसलिए यह db इश्यू / सेटिंग की ओर इशारा कर सकता है?

जो चीजें मैं कोशिश कर रहा हूं: मैं उस अप-टू-डेट को प्राप्त करने के लिए यूएटी पर वर्तमान लाइव डीबी को खींचने में व्यस्त हूं, यह देखने के लिए कि क्या मैं इस मुद्दे को दोहरा सकता हूं। जब किया जाएगा तो अद्यतन करेगा।

एक बार जब मैं एक गैर-लाइव क्षेत्र में इस मुद्दे को दोहरा सकता हूं, तो मैं व्यवस्थित रूप से मॉड्यूल को अक्षम कर दूंगा, देखें कि क्या स्टोर आईडी के साथ कुछ गड़बड़ हो रही है (MageMonkey और Sweettooth के साथ शुरू, क्योंकि वे 2 सप्ताह पहले अपडेट हो गए थे)

प्रश्न है - मैं और क्या प्रयास कर सकता हूं? किसी भी संकेत जहां मैं कुछ विराम बिंदुओं को मिटा सकता हूं और यह देखने के लिए कि क्या मैं इस समस्या का पता लगा सकता हूं, कोड को चरणबद्ध करता हूं?

कोई अतिरिक्त कैश सिस्टम नहीं हैं जैसे वार्निश या मेमेचे इंस्टॉल किए गए हैं। सर्वर एक मानक cpanel स्थापित है। uat पर परीक्षण मैंने सभी कैश को अक्षम कर दिया।

आगे का अद्यतन: ऐसा लगता है कि जब मैं डिफ़ॉल्ट विषय को छोड़ता हूं तो मैं पुन: पेश नहीं कर सकता। मैं व्यवस्थित रूप से थीम को ओवरराइड कर रहा हूं फ़ोल्डर वापस ले रहा हूं।

मैंने git को backtrack कोड का भी उपयोग किया और यह मुद्दा हर हैश के साथ बना हुआ है।

अद्यतन: जब से मेरे पास इस पर खर्च करने का समय था, तब से। उच्च काम का बोझ।

मैंने सत्र आधारित फाइल करने के लिए स्थानांतरित किया और समस्या दूर हो गई। चूंकि ग्राहक निकट भविष्य में कई सर्वरों का उपयोग करने का इरादा नहीं कर रहा है, और मेरे काम के बोझ के कारण, यह उस पर छोड़ दिया गया था। बाद में मुझे काटने के लिए सबसे अधिक संभावना होगी।

मैगेंटो समर्थन ने सुझाव दिया कि समस्या सत्र वर्गों को बढ़ाने वाले मीठे दांत मॉड्यूल से संबंधित है, लेकिन मैंने उस मॉड्यूल को अक्षम कर दिया है, और यह मुद्दा बना हुआ है।

जब मुझे और परिणाम मिलेंगे तो अपडेट करेंगे।


'फ्रंट पर फ्रंट का उपयोग करें' ने वास्तव में इस मुद्दे को ठीक नहीं किया। लगता है कि समस्या यादृच्छिक है। कुछ सत्रों के लिए ठीक काम करता है, दूसरों के लिए बूँदें।
3

मैं अब इसे UAT पर मज़बूती से दोहरा सकता हूं। कार्ट में जोड़ने के 8/10 प्रयासों की तरह यह मुद्दा है। फिर सत्र 'स्टिक्स' और सब कुछ सामान्य के अनुसार काम करता है। SweetTooth और MageMonkey को कारण के रूप में हटा दिया गया (बाद में उन्हें अपग्रेड कर दिया गया) इसकी पुष्टि एक सत्र का मुद्दा है। जब मैं कार्ट में जोड़ता हूं, मेरे पास एक आईडी के साथ सत्र होता है, जब मैं कार्ट देखने जाता हूं, तो मुझे नया सत्र आईडी मिलता है।
अप्रैल को प्रोग्लीब्यू

कुछ सहकर्मियों को लगभग समान मुद्दे का सामना करना पड़ा। मुझे ठीक से पता नहीं है कि क्या समस्या हुई (मुझे पता है कि यह मेमेचे और / या वार्निश से संबंधित था), लेकिन समाधान सर्वर (एस) के लिए एक लोड बैलेंसर स्थापित कर रहा था। तो आपको इस बारे में अपने सर्वर एडमिनिस्ट्रेटर से बात करनी चाहिए।
व्लाद प्रेडा

1
Magento संस्करण क्या है? सत्र भंडारण के रूप में भी आप क्या उपयोग कर रहे हैं? क्या फाइलों या डेटाबेस पर स्विच करने से क्रमशः फर्क पड़ता है?
फोमन में क्रिस्टोफ

@Fooman हाय, EE 1.11.2.0, DB सत्र का उपयोग करते हुए, फ़ाइलों को स्वैप करने की कोशिश नहीं की है, जो परिणाम देता है वापस रिपोर्ट करेगा।
ProxiBlue

जवाबों:


8

हमारे cPanel बक्से पर, लापता संपत्ति पूरे Magento पृष्ठ की सेवा कर रही थी।

CPanel की चूक, ErrorDocument 404 /404.shtmlलेकिन /404.shtmlMagento के दस्तावेज़ रूट में मौजूद नहीं है, इसलिए .htaccess को फिर से निष्पादित किया जाता है और (mod_rewrite का उपयोग करके) रीडायरेक्ट /404.shtmlकिया जाता है index.php

Magento के डिफ़ॉल्ट .htaccess में स्पष्ट रूप से 404, 500 और अन्य त्रुटि हैंडलर निर्दिष्ट होने चाहिए।

इस beaviour को ठीक करने के लिए, हमने अपने .htaccess में निम्नलिखित को जोड़ा:

ErrorDocument 404 /errors/404.php

हमें संभवतः 500s भी जोड़ना चाहिए:

ErrorDocument 500 /errors/500.php


@ProxiBlue ने आपकी समस्या का समाधान किया क्योंकि यह स्वीकृत उत्तर है? मेरे पास लगभग समान मुद्दा है। अभी भी यकीन नहीं है कि यह क्या कारण है।
dchayka

9

क्या आप सर्वर पर वार्निश का उपयोग कर रहे हैं?

हमने कई कार्यान्वयन देखे हैं जहाँ लोग स्थिर सामग्री (चित्र / css / js) पर कुकी प्राप्त करना बंद कर देते हैं - इसलिए यदि छवि / js / css मौजूद नहीं है; यह Magento बूटस्ट्रैप और 404 लोड करता है - यह कुकी और साइट सत्र को पूरी तरह से अलग करता है।


वार्निश नहीं, काश यह इतना सरल होता: '(
प्रोज़ीब्यू

हाय एक ही मुद्दा है मुझे पता है कि समाधान क्या हो सकता है?
कंदरप बी पटेल 11

@ इस पर आप कृपया विस्तार से बता सकते हैं।
burntblark

6

एक समस्या यह हो सकती है कि HTTP से HTTPS पर स्विच करने पर Magento सत्र डेटा को सहेज नहीं रहा है । सुनिश्चित करें कि एसएसएल आदि के लिए आवश्यक सेटिंग्स ठीक से स्थापित हैं।

एक और समस्या यह हो सकती है कि ग्राहक का आईएसपी यहां अपना डाक पता बदल रहा है, जैसा कि यहां पर लिखा गया है

इस समस्या को हल करने के लिए:

सिस्टम> कॉन्फिगरेशन> वेब के तहत मिलने वाले सेगमेंट वैलिडेशन सेटिंग को " वैलिडेट HTTP_USER_AGENT " को छोड़कर हर चीज पर 'नहीं' में बदलें । ऐसा करने के बाद, सिस्टम> कैश मैनेजमेंट में जाएं और बदलावों को लागू करने के लिए कॉन्फिगरेशन कैश रीफ्रेश करें।


कार्ट अभी भी http में है, इस प्रकार http-> https समस्या नहीं है।
प्रोक्सीब्लू

1
यह हमारे साथ, हमारे UAT वातावरण में भी हो रहा है, और हमारे पास एक निश्चित आईपी है। सुझावों की सराहना करें।
प्रोक्सीब्लू

5

हमने इस मुद्दे को तब देखा है जब पृष्ठ पर एक लापता छवि है, खासकर अगर छवि सभी पृष्ठों से गायब है जैसे हेडर या पाद में। ऐसा लगता है कि 404 पृष्ठ जो या तो मैगेंटो या वेबसर्वर रिटर्न ने फ्रंटेंड सेशन कुकी को तोड़ दिया, जिससे सत्र का नुकसान हुआ। यह चीजों को ठीक करने की हमारी सूची में है, लेकिन यह सुनिश्चित करने के लिए कि कोई लापता चित्र नहीं है, यह सुनिश्चित करने के लिए ...


मुझे खुशी है कि हमारे कुछ ग्राहकों के लिए ऐसा नहीं हो रहा है। 404 से अधिक मैं मानता हूं।
13१३

2
@jonathanday Magento ऐसा नहीं करेंगे, लेकिन बुरी तरह से कॉन्फ़िगर वार्निश करेंगे।
बेन लेसानी - सोनासी

@sonassi, क्या आप बुरी तरह से कॉन्फ़िगर वार्निश pls पर विस्तार कर सकते हैं? हम एक ही मुद्दा रहा है। 404 पेज को ठीक करने से समस्या का समाधान हो गया है, लेकिन यह जानना अच्छा लगेगा कि क्या हम वार्निश को बेहतर तरीके से कॉन्फ़िगर कर सकते हैं!
jmlnik

यह वास्तव में क्या हो रहा था। मैं किसी तरह इस जवाब से चूक गया! तथ्य यह है कि मैगनेटो को 404 पृष्ठ के नियंत्रक संस्करण को धक्का नहीं देना चाहिए, लेकिन एक स्थिर 404 पृष्ठ।
ProxiBlue

1
मैंने एक उत्तर पोस्ट किया जो इसे समझाता है।
बेन लेसानी - सोनासी

1

यह एक कुकी / सर्वर दिनांक समस्या हो सकती है। सबसे पहले बात करते हैं कुकी हेडर की। हेडर का निरीक्षण करें (फायरबग, चार्ल्स या फ़िडलर जैसी किसी चीज़ का उपयोग करके)।

आपको निम्नलिखित जैसा कुछ देखना चाहिए:

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

यदि समय सीमा समाप्त हो रही फ़ील्ड के लिए मान अतीत में है, तो संभावना है कि आपके सर्वर पर समय गलत है। यह तब हो सकता है जब ntpd जैसी सेवाएं शुरू होने में विफल हो जाती हैं। यदि ऐसा है, तो सर्वर पर समय की जांच करें। यदि समय बंद है, तो ntpd की स्थिति जांचें (या सर्वर के समय को अपडेट रखने के लिए जो भी डेमन सेवा है)।


जाँच की गई, सर्वर दिनांक / समय यदि ठीक है, कुकी दिनांक / समय ठीक है :(
ProxiBlue

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

हमारे पास एक समान मुद्दा था। हमारे मामले में, यह वार्निश विन्यास था (जैसे बेन लेसानी - सुझाव दे रहा था)। हमने अपनी वार्निश को १२० के लिए ४०४ कैश करने के लिए कॉन्फ़िगर किया है ताकि हमारे सर्वर को किसी पृष्ठ पर ४०४ त्रुटि होने पर बुरी तरह से अंकित न किया जा सके।

तो समस्या 404 के लिए है Magento फ्रंटएंड और frontend_cid कुकीज़ के लिए हेडर में एक सेट-कुकी के साथ जवाब दे रहा था, जो ग्राहक सत्र को रीसेट करता है।

इसके लिए हमारा समाधान 404 प्रतिक्रियाओं के लिए किसी भी सेट-कुकीज़ को छीनना है,

unset beresp.http.set-cookie;

0

पिछले दिनों में मेरे लिए PHP सत्र को तोड़ने वाली गूंगी चीजें और जाँच के लायक हो सकती हैं:

  • एक पूर्ण डिस्क
  • गलत सर्वर समय

:) जाँच डिस्क पहली बात, सब ठीक है।
ProxiBlue

दिनांक ठीक :( उतनी सरल नहीं, ऊग [~ / public_html / var / log] # दिनांक थु जन 31 11:55:49 WST 2013
ProxiBlue
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.