Carrinho soltando todos os itens / sessão do carrinho limpa

Um site que eu gerencio repentinamente (potencialmente duas semanas atrás - a partir das estatísticas do GA e relatado apenas agora) começou a soltar os itens do carrinho quando você o visualiza ou faz o checkout.

O 'minicarrinho' superior mostra os itens no menu suspenso, até que você navegue até o carrinho / faça o checkout e acabe no carrinho com a mensagem 'Não há itens no carrinho'.

Parece um problema de sessão. Isso não acontece quando conectado.

Removeu todas as opções de validação de sessão em 'sistema-> web-> configurações de validação de sessão' e ativou a opção 'Usar SID no Frontend'. Isso resolveu o problema, mas como essas configurações não foram alteradas nos últimos três meses, sei que há algum problema subjacente.

Isso aponta para um problema com o ID de dor? De alguma forma, o site está perdendo em qual ID da loja está e descartando os dados da sessão / carrinho? Talvez algum observador / evento / reescrito por algum módulo.

Não consigo replicar o problema no desenvolvedor local ou no servidor UAT. O banco de dados no UAT é de duas semanas com data de exibição, portanto isso pode indicar um problema / configuração de banco de dados?

O que estou tentando: estou ocupado transferindo o banco de dados ao vivo atual para o UAT para atualizá-lo, para ver se consigo replicar o problema lá. será atualizado quando isso for feito.

Depois que eu puder replicar o problema em uma área não ativa, desabilitarei sistematicamente os módulos, verificando se algo está mexendo nos IDs da loja (começando com MageMonkey e sweettooth, desde que eles foram atualizados há 2 semanas)

A pergunta é: o que mais posso tentar? Algum ponteiro para onde eu possa acertar alguns pontos de interrupção e passar o código para ver se consigo rastrear esse problema?

não há sistemas de cache extras como verniz ou memcache instalado. O servidor é uma instalação cpanel padrão. testando em uat eu desabilitei todo o cache.

atualização adicional: parece que, quando eu passo para o tema padrão, não consigo reproduzir. Estou movendo sistematicamente as pastas de substituição de tema de volta.

Também usei o git para retroceder o código e o problema permanece com todos os hash.

Atualização: Já faz um tempo desde que eu tive tempo para gastar com isso. Carga de trabalho alta.

Mudei as sessões para arquivo com base e o problema desapareceu. Como o cliente não pretende usar vários servidores em um futuro próximo, e devido à minha carga de trabalho, isso foi deixado assim. Provavelmente voltará para me morder mais tarde.

O suporte do magento sugeriu que o problema está relacionado ao módulo guloso estendendo as classes de sessão, mas desativei esse módulo e o problema permaneceu.

será atualizado quando eu tiver mais resultados.

Nas caixas do cPanel, os ativos ausentes estavam sendo veiculados em toda a página do Magento.

O padrão do cPanel é, ErrorDocument 404 /404.shtmlmas /404.shtmlnão existe, na raiz do documento do Magento, portanto o .htaccess é executado novamente e redirecionado /404.shtmlpara index.php(usando mod_rewrite).

O .htaccess padrão do Magento deve especificar explicitamente 404, 500 e outros manipuladores de erro.

Para corrigir esse problema, adicionamos o seguinte ao nosso .htaccess:

ErrorDocument 404 /errors/404.php

Provavelmente também devemos adicionar 500s:

ErrorDocument 500 /errors/500.php

Você está usando o Varnish no servidor?

Vimos várias implementações em que as pessoas extraem o cookie ANTES de buscar conteúdo estático (images / css / js) - portanto, se a imagem / js / css não existir; ele carrega o bootstrap e o 404 do Magento - eliminando completamente a sessão de cookies e sites.

Um problema pode ser que o Magento não está salvando os dados da sessão ao mudar de HTTP para HTTPS . Verifique se as configurações necessárias para SSL etc. estão definidas corretamente.

Outro problema pode ser que o ISP do cliente esteja alterando o endereço IP, conforme documentado aqui .

Para corrigir este problema:

Altere as configurações de Validação de sessão no Magento Admin, encontradas em Sistema> Configurações> Web , para 'não' em tudo, exceto em " Validar HTTP_USER_AGENT ". Depois de fazer isso, vá para Sistema> Gerenciamento de cache e atualize o cache de configuração para aplicar as alterações.

Observamos esse problema quando há uma imagem ausente em uma página, especialmente se a imagem estiver ausente em todas as páginas, por exemplo, em um cabeçalho ou rodapé. Parece que a página 404 que o Magento ou o servidor da web retorna quebra o cookie da sessão de front-end, levando à perda de sessão. Está em nossa lista de itens a corrigir, mas a solução alternativa é garantir que não haja imagens ausentes ...

Esse pode ser um problema de data do cookie / servidor. A primeira coisa a verificar são os cabeçalhos dos cookies. Inspecione os cabeçalhos (usando algo como Firebug, Charles ou Fiddler).

Você deve ver algo como o seguinte:

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

Se o valor do campo expirar estiver no passado, é possível que o tempo esteja errado no servidor. Isso pode acontecer quando serviços como o ntpd falham ao iniciar. Se for esse o caso, verifique a hora no servidor. Se o tempo estiver esgotado, verifique o status do ntpd (ou qualquer outro serviço daemon para manter a hora do servidor atualizada).

A coleta de lixo do PHP está limpando as sessões prematuramente. Eu mesmo já vi isso em sites de alto tráfego .

Algumas dicas para solução de problemas:

• Qual a idade da sua sessão mais antiga? Para descobrir: ls -laht [mageroot]/var/session/ | tail- se você não tiver sessões por mais de duas semanas, é provável que a coleta de lixo seja responsável
• Mova as sessões para outro repositório de dados temporariamente - MySQL ou Memcached, por exemplo. O problema foi resolvido?
• Isso está acontecendo em um servidor de desenvolvimento? Se não, e todas as coisas são iguais, pode ser que os níveis de tráfego estejam acionando a vencimento prematuro da sessão ou a coleta de lixo

Corrigi isso de uma de duas maneiras:

1. No seu .htaccess, adicione php_value session.gc_maxlifetime 2592000
2. No seu php.ini, defina session.gc_maxlifetime

Mais informações: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Tivemos um problema semelhante. No nosso caso, era a configuração de verniz (como Ben Lessani - sugeria). Configuramos o nosso verniz para armazenar em cache 404s por 120s, para que nossos servidores não sejam prejudicados quando houver um erro 404 em uma página.

Portanto, o problema é que o 404s Magento estava respondendo com um Set-Cookie no cabeçalho para cookies frontend e frontend_cid, que redefinem a sessão do cliente.

Nossa solução para este é retirar todos os Set-Cookies para respostas 404,

unset beresp.http.set-cookie;

Coisas estúpidas que quebraram sessões de PHP para mim no passado e podem valer a pena conferir:

• um disco completo
• tempo impreciso do servidor