รถเข็นวางรายการทั้งหมด / เซสชันรถเข็นล้าง

เว็บไซต์ที่ฉันจัดการโดยฉับพลัน (อาจเกิดขึ้นเมื่อ 2 สัปดาห์ที่ผ่านมา - จากสถิติของ GA และรายงานเฉพาะตอนนี้) เริ่มทิ้งรายการรถเข็นเมื่อคุณดูรถเข็นหรือไปชำระเงิน

'mini-cart' ด้านบนจะแสดงรายการในเมนูแบบเลื่อนลงจนกว่าคุณจะเรียกดูรถเข็น / เช็คเอาต์จากนั้นคุณก็จบลงที่ตะกร้าด้วยข้อความ 'ไม่มีรายการในรถเข็น'

ดูเหมือนว่าปัญหาเซสชัน มันจะไม่เกิดขึ้นเมื่อเข้าสู่ระบบ

ลบตัวเลือกการตรวจสอบความถูกต้องของเซสชันทั้งหมดใน 'system-> web-> การตั้งค่าการตรวจสอบความถูกต้องของเซสชัน' และเปิดใช้งานตัวเลือกที่ระบุว่า 'Use SID on Frontend' นี่เป็นการแก้ปัญหา แต่เนื่องจากการตั้งค่าเหล่านี้ไม่ได้เปลี่ยนแปลงในช่วง 3 เดือนที่ผ่านมาฉันจึงรู้ว่ามีปัญหาพื้นฐานบางอย่าง

หากเป็นเช่นนั้นจะทำให้เกิดปัญหาเกี่ยวกับปัญหา id-id? ยังไงก็ตามไซต์กำลังเปิดใช้งาน store-id ใดและปล่อยข้อมูลเซสชัน / ตะกร้าสินค้า บางทีผู้สังเกตการณ์ / เหตุการณ์ / เขียนใหม่โดยบางโมดูล

ฉันไม่สามารถทำซ้ำปัญหาบน dev ท้องถิ่นหรือบนเซิร์ฟเวอร์ UAT DB บน ​​UAT นั้นมีอายุ 2 สัปดาห์จากการถ่ายทอดสดดังนั้นสิ่งนี้อาจชี้ไปที่ปัญหา / การตั้งค่า db

สิ่งที่ฉันกำลังพยายาม: ฉันกำลังยุ่งอยู่กับการดึง db สดปัจจุบันไปที่ UAT เพื่อรับข้อมูลล่าสุดเพื่อดูว่าฉันสามารถทำซ้ำปัญหาได้หรือไม่ จะอัปเดตเมื่อเสร็จแล้ว

เมื่อฉันสามารถทำซ้ำปัญหาในพื้นที่ที่ไม่อยู่ฉันจะปิดการใช้งานโมดูลอย่างเป็นระบบดูว่ามีบางสิ่งที่ล้อเลียนเกี่ยวกับ Store id ของ (เริ่มต้นด้วย MageMonkey และ sweettooth เนื่องจากพวกเขาได้รับการปรับปรุง 2 สัปดาห์ที่ผ่านมา)

คำถามคือ - ฉันจะลองทำอะไรได้อีก พอยน์เตอร์ใดที่ฉันสามารถตีเบรกพอยต์บางส่วนและทำตามขั้นตอนของรหัสเพื่อดูว่าฉันสามารถติดตามปัญหานี้ได้หรือไม่

ไม่มีระบบแคชเพิ่มเติมเช่นวานิชหรือ memcache ติดตั้งอยู่ เซิร์ฟเวอร์คือการติดตั้ง cPanel มาตรฐาน การทดสอบบน uat ฉันปิดการใช้งานแคชทั้งหมด

อัปเดตเพิ่มเติม: ดูเหมือนว่าเมื่อฉันเปลี่ยนไปใช้ธีมเริ่มต้นฉันไม่สามารถทำซ้ำได้ ฉันกำลังย้ายชุดรูปแบบแทนที่โฟลเดอร์กลับ

ฉันยังใช้ git เพื่อโค้ดย้อนกลับและปัญหายังคงอยู่กับแฮชทุกครั้ง

อัปเดต: เคยผ่านไปซักพักแล้วตั้งแต่ฉันมีเวลา ภาระงานสูง

ฉันย้ายเซสชันไปยังไฟล์ตามและปัญหาหายไป เนื่องจากลูกค้าไม่ได้ตั้งใจที่จะใช้เซิร์ฟเวอร์หลายเครื่องในอนาคตอันใกล้และเนื่องจากภาระงานของฉันนี่จึงเหลืออยู่ที่ ส่วนใหญ่จะกลับมากัดฉันในภายหลัง

ฝ่ายสนับสนุนของวีโอไอพีแนะนำว่าปัญหาเกี่ยวข้องกับโมดูลฟันหวานขยายคลาสเซสชัน แต่ฉันได้ปิดใช้งานโมดูลนั้น

จะอัปเดตเมื่อฉันได้รับผลลัพธ์เพิ่มเติม

ในกล่อง cPanel สินทรัพย์ที่ขาดหายไปกำลังแสดงหน้า Magento ทั้งหมด

ค่าเริ่มต้นของ cPanel เป็นErrorDocument 404 /404.shtmlแต่/404.shtmlไม่มีอยู่ในรูทเอกสารของ Magento ดังนั้น. htaccess จะถูกดำเนินการอีกครั้งและเปลี่ยนเส้นทาง/404.shtmlไปที่index.php(โดยใช้ mod_rewrite)

htaccess ของค่าเริ่มต้นของ Magento ควรระบุตัวจัดการข้อผิดพลาด 404, 500 และอื่น ๆ อย่างชัดเจน

เพื่อแก้ไข beahviour นี้เราได้เพิ่มสิ่งต่อไปนี้ใน. htaccess ของเรา:

ErrorDocument 404 /errors/404.php

เราอาจเพิ่ม 500s ด้วย:

ErrorDocument 500 /errors/500.php

คุณใช้วานิชบนเซิร์ฟเวอร์หรือไม่?

เราได้เห็นการใช้งานหลายอย่างที่ผู้คนดึงคุกกี้ออกมาก่อนที่จะดึงเนื้อหาแบบสแตติก (ภาพ / css / js) - ดังนั้นหากไม่มีภาพ / js / css อยู่; มันโหลด bootstrap ของ Magento และ 404 ซึ่งเป็นการลบคุกกี้และเซสชันของไซต์ทั้งหมด

ปัญหาหนึ่งที่อาจเป็นไปได้ว่าวีโอไอพีไม่ได้บันทึกข้อมูลเซสชั่นเมื่อเปลี่ยนจากHTTPเพื่อHTTPS ตรวจสอบให้แน่ใจว่ามีการตั้งค่าที่จำเป็นสำหรับ SSL เป็นต้น

อีกปัญหาหนึ่งก็อาจเป็นไปได้ว่าลูกค้าของผู้ให้บริการอินเทอร์เน็ตที่มีการเปลี่ยนแปลงที่อยู่ IP ของพวกเขาเป็นเอกสารที่นี่

ในการแก้ไขปัญหานี้:

เปลี่ยนการตั้งค่าการตรวจสอบความถูกต้องของเซสชันในผู้ดูแลระบบ Magento ซึ่งอยู่ภายใต้ระบบ> การกำหนดค่า> เว็บเป็น 'ไม่' ในทุกสิ่งยกเว้น“ ตรวจสอบความถูกต้อง HTTP_USER_AGENT ” หลังจากทำเช่นนี้ให้ไปที่ระบบ> การจัดการแคชและรีเฟรชแคชการกำหนดค่า

เราได้ตรวจสอบปัญหานี้เมื่อมีภาพหายไปในหน้าโดยเฉพาะอย่างยิ่งหากภาพหายไปจากทุกหน้าเช่นในส่วนหัวหรือส่วนท้าย ดูเหมือนว่าหน้า 404 ที่ Magento หรือเว็บเซิร์ฟเวอร์ส่งกลับจะแบ่งคุกกี้เซสชันส่วนหน้าซึ่งนำไปสู่การสูญเสียเซสชัน มันอยู่ในรายการสิ่งที่เราต้องแก้ไข แต่วิธีแก้ไขคือเพื่อให้แน่ใจว่าไม่มีภาพหายไป ...

นี่อาจเป็นปัญหาเกี่ยวกับวันที่ของคุกกี้ / เซิร์ฟเวอร์ สิ่งแรกที่ต้องตรวจสอบคือส่วนหัวของคุกกี้ ตรวจสอบส่วนหัว (ใช้บางอย่างเช่น Firebug, Charles หรือ Fiddler)

คุณควรเห็นสิ่งต่อไปนี้:

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

หากค่าสำหรับเขตข้อมูลหมดอายุในอดีตโอกาสที่จะถึงเวลาบนเซิร์ฟเวอร์ของคุณจะไม่ถูกต้อง สิ่งนี้สามารถเกิดขึ้นได้เมื่อเซอร์วิสเช่น ntpd ไม่สามารถเริ่มต้นได้ หากเป็นกรณีนี้ให้ตรวจสอบเวลาบนเซิร์ฟเวอร์ หากเวลาปิดให้ตรวจสอบสถานะของ ntpd (หรือบริการ daemon ใดก็ตามที่จะทำให้เวลาของเซิร์ฟเวอร์อัปเดต)

การรวบรวมขยะ 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 - กำลังแนะนำ) เราได้กำหนดค่าวานิชของเราไปยังแคช 404 สำหรับ 120 วินาทีเพื่อให้เซิร์ฟเวอร์ของเราจะไม่ได้รับผลกระทบอย่างรุนแรงเมื่อมีข้อผิดพลาด 404 บนหน้าเว็บ

ดังนั้นปัญหาสำหรับ 404s Magento ก็ตอบสนองด้วย Set-Cookie ในส่วนหัวของ frontend และ frontend_cid cookies ที่รีเซ็ตเซสชั่นลูกค้า

ทางออกของเราสำหรับอันนี้คือการตัดคุกกี้ชุดใด ๆ สำหรับการตอบสนอง 404

unset beresp.http.set-cookie;

สิ่งที่โง่ที่มีการแบ่งช่วงเวลา PHP สำหรับฉันในอดีตและอาจคุ้มค่าการตรวจสอบ:

• ดิสก์เต็ม
• เวลาเซิร์ฟเวอร์ไม่ถูกต้อง