Cesta cayendo todos los artículos / borra carrito de sesión

Question

Un sitio me las arreglo repente (hace potencialmente 2 semanas - a partir de las estadísticas de GA, y sólo informó hoy) comenzó a dejar caer los artículos carrito cuando ve el carro, o ir a la caja.

La parte superior 'mini-cart' muestra los elementos en el menú desplegable, hasta que navega a carro / pagar, y luego termina en el carro, con 'No hay artículos en su cesta' mensaje.

Parece un problema de sesión. Esto no sucede cuando se haya identificado.

Se ha quitado todas las opciones de validación de la sesión en 'configuración Sistema-> web-> validación de sesión', y ha permitido el que dice 'Uso de SID en frontend'. Esto ha solucionado el problema, pero ya que estos valores no cambiaron en los últimos 3 meses, sé que hay algún problema subyacente.

Esto entonces apunta a problema con tema delicado-id? De alguna manera el sitio está perdiendo lo que tienda-id está encendido, y colocar los datos de sesión / compra? Tal vez algún observador / eventos / reescribir por algún módulo.

No se puede reproducir el problema en dev local o en el servidor UAT. DB en UAT es de 2 semanas a partir de fecha en vivo, así que esto podría apuntar a un / db entorno tema?

Las cosas que trato: Estoy ocupado tirando db vivo actual a la UAT para conseguir que la fecha de puesta al, para ver si puedo reproducir el problema existe. actualizará cuando se hace eso.

Una vez que puedo reproducir el problema en un área no-vivo, voy a módulos sistemáticamente deshabilitar, ver si algo se curioseaba con la tienda de Identificación (a partir de MageMonkey y sweettooth, desde que se actualizaron hace 2 semanas)

La pregunta es - ¿qué más puedo intentar? Cualquier punteros a donde puedo golpear a algunos puntos de interrupción y el código para ver si puedo rastrear este problema?

no hay sistemas de caché adicionales como barniz o Memcache instalado. Servidor es un estándar cPanel instalar. pruebas en UAT I inhabilitó toda caché.

nueva actualización: parecería que cuando se me cae al diseño por defecto no puedo reproducir. Estoy moviendo sistemáticamente carpetas tema de anulación posterior.

También utiliza git al código de dar marcha atrás y los restos de emisión con todos los hash.

Actualización: Ha pasado un tiempo desde que tuve tiempo para dedicar a esto. alta carga de trabajo.

Me trasladó a las sesiones de archivos basado en el tema y se ha ido. Puesto que el cliente no tiene la intención de utilizar varios servidores en un futuro próximo, y debido a mi carga de trabajo, esto fue dejado en eso. Lo más probable es que volver a morder más tarde.

Soporte Magento sugirió que el problema está relacionado con módulo de diente dulce extender las clases de sesión, pero he deshabilitado ese módulo, y la cuestión se mantuvo.

actualizará cuando consigo más resultados.

Answer 1

On our cPanel boxes, missing assets were serving the entire Magento page.

cPanel's defaults to ErrorDocument 404 /404.shtml but /404.shtml doesn't exist in Magento's document root, so the .htaccess gets executed again and redirects /404.shtml to index.php (using mod_rewrite).

Magento's default .htaccess should specify 404, 500, and other error handlers explicitly.

To fix this beahviour, we added the following to our .htaccess:

ErrorDocument 404 /errors/404.php

We probably should also add 500s as well:

ErrorDocument 500 /errors/500.php

Answer 2

Are you using Varnish on the server?

We've seen a number of implementations where people strip the cookie BEFORE fetching on static content (images/css/js) - so if the image/js/css doesn't exist; it loads the Magento bootstrap and 404's - this stripping the cookie and site session entirely.

Answer 3

One problem might be that Magento is not saving the session data when switching from HTTP to HTTPS. Make sure that the necessary settings for SSL etc. are set up properly.

Another problem it might be that the customer's ISP is changing their ip address, as documented here.

To fix this issue:

Change the Session Validation settings in the Magento Admin, found under System > Configurations > Web, to ‘no’ on everything except “Validate HTTP_USER_AGENT.” After doing this, go to System > Cache Management and refresh the configuration cache to apply the changes.

Answer 4

We have observed this issue when there is a missing image on a page, especially if the image is missing from all pages e.g. in a header or footer. It seems that the 404 page that either Magento or the webserver returns breaks the frontend session cookie, leading to loss of session. It is on our list of things to fix, but the workaround is to ensure there are no missing images...

Answer 5

This could be a cookie/server date issue. First thing to check are the cookie headers. Inspect the headers (using something like Firebug, Charles or Fiddler).

You should see something like the following:

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

If the value for the expires field is in the past, then chances are the time on your server is wrong. This can happen when services like ntpd fail to start. If that's the case, check the time on the server. If the time is off check the status of ntpd (or whichever daemon service to keep the server's time updated).

Answer 6

PHP garbage collection is clearing out the sessions prematurely. I have seen this myself on high-traffic sites.

Some troubleshooting tips:

• How old is your oldest session? To find out: ls -laht [mageroot]/var/session/ | tail - if you don't have sessions longer than a couple of weeks or so, garbage collection is likely to blame
• Move sessions to another data store temporarily - MySQL or Memcached, for instance. Is the problem resolved?
• Is this happening on a development server? If no, and all things are equal, it could be that traffic levels are triggering premature session expiration or garbage collection

I have fixed this in one of two ways:

1. In your .htaccess, add php_value session.gc_maxlifetime 2592000
2. In your php.ini, set session.gc_maxlifetime

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

Answer 7

We had a similar issue. In our case, it was the Varnish configuration (Like Ben Lessani - was suggesting). We have configured our Varnish to cache 404s for 120s so that our servers won't get hammered badly when there is a 404 error on a page.

So the issue is for 404s Magento was responding with a Set-Cookie in the header for frontend and frontend_cid cookies, that resets the customer session.

Our solution for this one is to strip any Set-Cookies for 404 responses,

unset beresp.http.set-cookie;

Answer 8

Dumb things that have broken PHP sessions for me in the past and might be worth checking:

• a full disk
• inaccurate server time