Tüm ürün bırakan sepet / sepet oturumu temizlenir


27

Birdenbire yönettiğim bir site (potansiyel olarak 2 hafta önce - GA istatistiklerinden ve yalnızca şimdi bildirildi), sepeti görüntülediğinizde veya kullanıma başladığınızda sepet öğelerini atmaya başladı.

En üstteki 'mini-cart', sepete / çıkışa göz atıncaya kadar açılır menüdeki öğeleri gösterir ve daha sonra 'Sepetinizde hiç ürün yok' mesajı olan sepete girersiniz.

Bir oturum sorunu gibi görünüyor. Giriş yapıldığında olmaz.

'Sistem-> web-> oturum doğrulama ayarları'ndaki tüm oturum doğrulama seçenekleri kaldırıldı ve' Ön uçta SID kullan 'yazan seçeneği etkinleştirin. Bu sorunu çözdü, ancak bu ayarlar son 3 ay içinde değişmediğinden, bazı temel sorunların olduğunu biliyorum.

Bu daha sonra boğaz kimliği sorunu ile işaret ediyor? Bir şekilde site, hangi mağaza kimliğini kaybettiğini ve oturum / alışveriş sepetindeki verileri bıraktığını mı söylüyor? Belki bazı modül tarafından gözlemci / olay / yeniden yazma.

Bu sorunu yerel dev veya UAT sunucusunda çoğaltamıyorum. UAT'taki DB, canlı yayından 2 hafta sonra, bu bir db sorununa / ayarına işaret edebilir mi?

Çalıştığım şeyler: Güncel olanı bulmak için UAT'a güncel db'yi çekmekle meşgulüm, sorunu orada çoğaltabilecek miyim diye. bu yapıldığında güncellenecektir.

Bu sorunu canlı olmayan bir alanda çoğaltabildiğimde, sistematik olarak modülleri devre dışı bırakacağım, mağaza kimlikleriyle ilgili bir şey olup olmadığını göreceğim (MageMonkey ve sweettooth ile başlayarak, 2 hafta önce güncellendiğinden beri)

Soru - başka ne deneyebilirim? Bazı kesme noktalarını kırabileceğim ve bu sorunu takip edip edemediğimi görmek için kodu adım atabilecek herhangi bir işaretçi var mı?

yüklü vernik veya memcache gibi ekstra önbellek sistemleri yoktur. Sunucu standart bir cpanel kurulumudur. UAT üzerinde test tüm önbelleği devre dışı bıraktım.

daha fazla güncelleme: Görünüşe göre varsayılan temaya girdiğimde çoğalamıyorum. Sistematik olarak tema geçersiz kılma klasörlerini geri taşıyorum.

Ayrıca, kodu geri almak için git'i kullandım ve sorun her karmaşada kalıyor.

Güncelleme: Bir süredir bunun için harcayacak vaktim vardı. Yüksek iş yükü.

Oturumları dosya tabanlı olarak taşıdım ve sorun çözüldü. İstemci yakın gelecekte birden fazla sunucu kullanmaya niyetli olmadığından ve iş yüküm nedeniyle bu kaldı. Büyük olasılıkla daha sonra beni ısırmaya gelecek.

magento desteği, sorunun seans sınıflarını genişleten tatlı diş modülü ile ilgili olduğunu ileri sürdü, ancak ben bu modülü devre dışı bıraktım ve sorun devam etti.

daha fazla sonuç aldığımda güncellenecek.


'Frontend'de SID Kullan' aslında sorunu çözmedi. Sorun rastgele görünüyor. Bazı oturumlarda işe yarar, diğerleri için düşer.
ProxiBlue

Bunu şimdi UAT'de güvenilir bir şekilde çoğaltabilirim. Görünüşe göre bu 8/10 sepete ekleme denemeleri var. Sonra oturumu 'sopa' ve her şey normal olarak çalışır. SweetTooth ve MageMonkey nedenlerini ortadan kaldırdılar (yükseltildikten sonra) Bir oturum sorunu olduğunu onayladılar. Sepete eklediğimde, bir kimliği olan bir oturumum var, alışveriş sepetine gittiğimde yeni oturum kimliği alıyorum.
ProxiBlue

Bazı meslektaşlarımız neredeyse özdeş bir sorunla karşılaştı. Soruna neyin neden olduğunu tam olarak bilmiyorum (bunun memcache ve / veya cila ile ilgili olduğunu biliyorum), ancak çözüm, sunucu (lar) için bir yük dengeleyici kuruyordu. Bu yüzden sunucu yöneticinizle bunun hakkında konuşmalısınız.
Vlad Preda

1
Magento versiyonu nedir? Ayrıca oturum depolaması olarak ne kullanıyorsunuz? Sırasıyla dosyalara veya veritabanına geçmek bir fark yaratır mı?
Fooman'daki Kristof,

@Fooman Merhaba, EE 1.11.2.0, DB oturumunu kullanarak, dosyalara geçmeyi denemedi, ne sonuç verdiğini geri rapor edecek.
ProxiBlue

Yanıtlar:


8

CPanel kutularımızda, eksik varlıklar Magento sayfasının tamamına hizmet ediyordu.

için cPanel varsayılan ErrorDocument 404 /404.shtmlancak /404.shtml.htaccess tekrar yönlendirme yürütülür alır böylece Magento'nın belge kök yok /404.shtmletmek index.php(mod_rewrite kullanarak).

Magento'nun varsayılan .htaccess özelliği açıkça 404, 500 ve diğer hata işleyicilerini belirtmelidir.

Bu beahviour'u düzeltmek için, .htaccess dosyasına aşağıdakileri ekledik:

ErrorDocument 404 /errors/404.php

Muhtemelen 500'leri de eklemeliyiz:

ErrorDocument 500 /errors/500.php


@ ProxiBlue kabul edilen cevap olduğundan bu sorunu çözdü mü? Neredeyse aynı sorun var. Buna neyin sebep olduğuna hala emin değilim.
dchayka

9

Sunucuda Varnish kullanıyor musunuz?

İnsanların çerezi statik içeriğe (ÇEKİMLER / css / js) çekmeden ÖNCE çerezi çıkardığı bazı uygulamalar gördük - eğer / js / css görüntüsü yoksa; Magento açılış bandını ve 404'leri yükler - bu çerez ve site oturumunu tamamen sıyırır.


Cila yok, keşke bu kadar basit olsaydı: '(
ProxiBlue

Merhaba aynı sorunu var ne çözüm olduğunu biliyor muyum?
Kandarp B Patel,

@Ben Lütfen bu konuda ayrıntılı bilgi verebilir misiniz.
burntblark

6

Bir problem geçildiğinde Magento oturum verilerini kaydetme olmadığını olabilir , HTTP için HTTPS . SSL vb. İçin gerekli ayarların doğru yapıldığından emin olun.

Başka bir sorun, müşterinin ISS'nin burada belirtildiği gibi ip adreslerini değiştirmesi olabilir .

Bu sorunu çözmek için:

Sistem> Konfigürasyonlar> Web altında bulunan Magento Yöneticisi'ndeki Oturum Doğrulama ayarlarını “ HTTP_USER_AGENT Doğrula ” dışındaki her şeyde “hayır” olarak değiştirin . Bunu yaptıktan sonra, Sistem> Önbellek Yönetimi'ne gidin ve değişiklikleri uygulamak için yapılandırma önbelleğini yenileyin.


El arabası hala http içerisindeyse, http-> https sorunu da yok.
ProxiBlue

1
UAT ortamımızda da bize oluyor ve sabit bir ipimiz var. Önerileri takdir et.
ProxiBlue

5

Bir sayfada eksik bir görüntü olduğunda, özellikle de görüntü, örneğin tüm başlıklarda veya altbilgide eksikse, bu sorunu gözlemledik. Görünüşe göre, Magento veya web sunucusunun döndürdüğü 404 sayfasının ön uç oturum çerezini kırması, oturum kaybına neden oluyor. Düzeltilmesi gerekenler listemizde yer almaktadır, ancak geçici çözüm eksik görüntü olmamasını sağlamaktır ...


Bazı müşterilerimiz için olmadığına sevindim. Kabul ettiğimden daha fazla 404.
Philwinkle

2
@ jonathanday Magento bunu yapmayacak, ama kötü yapılandırılmış Vernik yapacak.
Ben Lessani - Sonassi

@sonassi, kötü yapılandırılmış Varnish pls üzerinde genişletebilir misiniz? Aynı sorunu yaşıyoruz. 404 sayfasını düzeltmek sorunu çözdü, ancak Varnish'i daha iyi yapılandırabilirsek bilmek isteriz!
jmlnik

Bu aslında olan şeydi. Bir şekilde bu cevabı kaçırdım! Gerçek şu ki, magento 404 sayfasının kontrol ünitesini değil, statik bir 404 sayfasını zorlamalıdır.
ProxiBlue

1
Bunu açıklayan bir cevap gönderdim.
Ben Lessani - Sonassi

1

Bu bir çerez / sunucu tarihi sorunu olabilir. İlk kontrol edilecek şey çerez başlıklarıdır. Başlıkları inceleyin (Firebug, Charles veya Fiddler gibi bir şey kullanarak).

Aşağıdaki gibi bir şey görmelisiniz:

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

Sona erme alanı değeri geçmişte kaldıysa, olasılıkla sunucunuzdaki zaman yanlış olabilir. Bu, ntpd gibi hizmetler başlatılamadığında olabilir. Bu durumda, sunucudaki saati kontrol edin. Süre kapalıysa ntpd (veya sunucunun saatini güncel tutmak için hangi günlük servis) durumunu kontrol edin.


Kontrol edildi, sunucu tarihi / saati uygunsa, çerez tarihi / saati
uygunsa

1

PHP çöp toplama , oturumları erken temizliyor. Bunu kendimi yoğun trafik çeken sitelerde gördüm .

Bazı sorun giderme ipuçları:

  • En eski oturumunuz kaç yaşında? Öğrenmek için: ls -laht [mageroot]/var/session/ | tail- birkaç haftadan daha uzun süren oturumlarınız yoksa, çöp toplanması suçlanabilir
  • Oturumları geçici olarak başka bir veri deposuna taşıyın - örneğin, MySQL veya Memcached. Sorun çözüldü mü?
  • Bu bir geliştirme sunucusunda mı oluyor? Hayır ise ve her şey eşitse, trafik seviyelerinin erken oturum sona erme veya çöp toplama işlemini tetiklemesi olabilir

Bunu iki yoldan biriyle düzelttim:

  1. .Htaccess'inize ekleyin php_value session.gc_maxlifetime 2592000
  2. Php.ini dosyasında session.gc_maxlifetime değerini ayarlayın.

Daha fazla okuma: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime


1
İyi öneriler. Birkaç gün içinde deneyecek
ProxiBlue

1

Benzer bir sorunumuz vardı. Bizim durumumuzda, Varnish konfigürasyonuydu (Ben Lessani gibi - öneriyordu). Varnish'i 404'leri önbelleğe alacak şekilde 120'ler boyunca yapılandırdık, böylece bir sayfada 404 hatası olduğunda sunucularımız kötü bir şekilde dövülmeyecek.

Bu yüzden mesele 404'ler için Magento, müşteri oturumunu yeniden başlatan, ön uç ve frontend_cid çerezleri başlığında Set-Cookie ile yanıt veriyordu.

Bunun için çözümümüz, 404 yanıt için herhangi bir Set-Cookies'i soymaktır.

unset beresp.http.set-cookie;

0

Geçmişte benim için PHP oturumları kırdı ve kontrol etmeye değer aptal şeyler:

  • tam bir disk
  • yanlış sunucu süresi

:) ilk diski kontrol ettim, hepsi tamam.
ProxiBlue

tarih para cezası :( o kadar basit değil, ugh [~ / public_html / var / log] # tarih Perşembe 31 Ocak 11:55:49 WST 2013
ProxiBlue
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.