Il carrello fa cadere tutti gli articoli / la sessione del carrello viene cancellata

Un sito che gestisco improvvisamente (potenzialmente 2 settimane fa - dalle statistiche di GA, e riportato solo ora) ha iniziato a eliminare gli articoli del carrello quando lo visualizzi o vai alla cassa.

Il "mini-carrello" in alto mostra gli articoli nel menu a discesa, fino a quando non si passa al carrello / alla cassa e si finisce sul carrello con il messaggio "Non ci sono articoli nel carrello".

Sembra un problema di sessione. Non succede quando si è connessi.

Rimosso tutte le opzioni di convalida della sessione in "sistema-> web-> impostazioni di convalida della sessione" e abilitato quello che dice "Usa SID sul frontend". Ciò ha risolto il problema, ma poiché queste impostazioni non sono cambiate negli ultimi 3 mesi, so che c'è qualche problema di fondo.

Questo indica quindi un problema con il problema dell'ID irritato? In qualche modo il sito sta perdendo su quale ID negozio si trova e rilasciando i dati di sessione / carrello? Forse qualche osservatore / evento / riscrivere da qualche modulo.

Non riesco a replicare il problema sullo sviluppatore locale o sul server UAT. DB su UAT è datato 2 settimane dal vivo, quindi questo potrebbe indicare un problema / impostazione db?

Cose che sto provando: sono impegnato a trasferire l'attuale db live su UAT per aggiornarlo, per vedere se riesco a replicare il problema lì. aggiornerà quando ciò sarà fatto.

Una volta che potrò replicare il problema in un'area non live, disabiliterò sistematicamente i moduli, vedo se qualcosa sta confondendo con l'ID dello store (a partire da MageMonkey e sweettooth, poiché sono stati aggiornati 2 settimane fa)

La domanda è: cos'altro posso provare? Qualche suggerimento su dove posso colpire alcuni punti di interruzione e passare il codice per vedere se riesco a rintracciare questo problema?

non ci sono sistemi di cache extra come varnish o memcache installati. Il server è un'installazione standard di cpanel. test su uat ho disabilitato tutta la cache.

ulteriore aggiornamento: sembrerebbe che quando passo al tema predefinito non riesco a riprodurre. Sto sistematicamente spostando indietro le cartelle di override del tema.

Ho anche usato git per rintracciare il codice e il problema rimane con ogni hash.

Aggiornamento: è passato un po 'di tempo da quando ho avuto tempo da dedicare a questo. Carico di lavoro elevato.

Ho spostato le sessioni in base al file e il problema è scomparso. Dal momento che il client non intende utilizzare più server nel prossimo futuro e, a causa del mio carico di lavoro, questo è rimasto. Molto probabilmente tornerà a mordermi più tardi.

il supporto di magento ha suggerito che il problema è legato al modulo per i più piccoli che estende le classi di sessione, ma ho disabilitato quel modulo e il problema è rimasto.

aggiornerò quando avrò più risultati.

Sulle nostre scatole cPanel, le risorse mancanti servivano l'intera pagina di Magento.

L'impostazione predefinita di cPanel è ErrorDocument 404 /404.shtmlma /404.shtmlnon esiste nella radice del documento di Magento, quindi .htaccess viene eseguito di nuovo e reindirizza /404.shtmla index.php(usando mod_rewrite).

Il .htaccess predefinito di Magento dovrebbe specificare esplicitamente 404, 500 e altri gestori di errori.

Per risolvere questo problema, abbiamo aggiunto quanto segue al nostro .htaccess:

ErrorDocument 404 /errors/404.php

Probabilmente dovremmo anche aggiungere 500:

ErrorDocument 500 /errors/500.php

Stai usando Varnish sul server?

Abbiamo visto una serie di implementazioni in cui le persone spogliano il cookie PRIMA di recuperare contenuto statico (images / css / js) - quindi se l'immagine / js / css non esiste; carica il bootstrap di Magento e i 404, eliminando completamente la sessione di cookie e sito.

Un problema potrebbe essere che Magento non sta salvando i dati della sessione quando si passa da HTTP a HTTPS . Assicurarsi che le impostazioni necessarie per SSL ecc. Siano configurate correttamente.

Un altro problema potrebbe essere che l'ISP del cliente sta modificando il proprio indirizzo IP, come documentato qui .

Per risolvere questo problema:

Modifica le impostazioni di convalida della sessione nell'Amministratore Magento, che si trova in Sistema> Configurazioni> Web , su "no" su tutto tranne " Convalida HTTP_USER_AGENT ". Dopo aver fatto ciò, vai su Sistema> Gestione cache e aggiorna la cache di configurazione per applicare le modifiche.

Abbiamo riscontrato questo problema quando è presente un'immagine mancante in una pagina, soprattutto se l'immagine manca da tutte le pagine, ad esempio in un'intestazione o piè di pagina. Sembra che la pagina 404 restituita da Magento o dal server Web rompa il cookie della sessione frontend, portando alla perdita della sessione. È nel nostro elenco di cose da risolvere, ma la soluzione è quella di garantire che non ci siano immagini mancanti ...

Potrebbe trattarsi di un problema relativo alla data del cookie / server. La prima cosa da controllare sono le intestazioni dei cookie. Ispeziona le intestazioni (usando qualcosa come Firebug, Charles o Fiddler).

Dovresti vedere qualcosa di simile al seguente:

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

Se il valore per il campo di scadenza è passato, è probabile che l'ora sul tuo server sia errata. Questo può accadere quando i servizi come ntpd non si avviano. In tal caso, controlla l'ora sul server. Se il tempo è scaduto, controllare lo stato di ntpd (o qualsiasi altro servizio daemon per mantenere aggiornato il tempo del server).

PHP Garbage Collection sta eliminando prematuramente le sessioni. L'ho visto anch'io su siti ad alto traffico .

Alcuni suggerimenti per la risoluzione dei problemi:

• Quanti anni ha la tua sessione più vecchia? Per scoprire: ls -laht [mageroot]/var/session/ | tail- se non si hanno sessioni più lunghe di un paio di settimane circa, è probabile che la raccolta dei rifiuti sia la causa
• Spostare temporaneamente le sessioni in un altro archivio di dati, ad esempio MySQL o Memcached. Il problema è stato risolto?
• Sta succedendo su un server di sviluppo? Se no, e tutte le cose sono uguali, è possibile che i livelli di traffico stiano innescando la scadenza prematura della sessione o la garbage collection

Ho risolto questo problema in due modi:

1. Nel tuo .htaccess, aggiungi php_value session.gc_maxlifetime 2592000
2. Nel tuo php.ini, imposta session.gc_maxlifetime

Altre letture: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Abbiamo avuto un problema simile. Nel nostro caso, era la configurazione di vernice (come suggeriva Ben Lessani). Abbiamo configurato il nostro Varnish per memorizzare nella cache 404s per 120s in modo che i nostri server non vengano maltrattati in caso di errore 404 su una pagina.

Quindi il problema è per 404s Magento stava rispondendo con un Set-Cookie nell'intestazione per i cookie frontend e frontend_cid, che reimposta la sessione del cliente.

La nostra soluzione per questo è di eliminare qualsiasi Set-Cookies per 404 risposte,

unset beresp.http.set-cookie;

Cose stupide che hanno interrotto le sessioni PHP per me in passato e potrebbe valere la pena verificarle:

• un disco completo
• tempo del server impreciso