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


27

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.


O 'Usar SID no Frontend' de fato não corrigiu o problema. Parece que o problema é aleatório. Funciona bem para algumas sessões, cai para outros.
ProxiBlue

Agora, posso replicar isso com segurança no UAT. Parece que 8/10 tentativas de adicionar ao carrinho têm esse problema. Em seguida, a sessão 'fica' e tudo funciona normalmente. Eliminado o SweetTooth e o MageMonkey como motivos (após a atualização) Confirmado que é um problema de sessão. Quando adiciono ao carrinho, tenho uma sessão com um ID, quando vou ao carrinho, recebo um novo ID de sessão.
ProxiBlue

Alguns colegas encontraram um problema quase idêntico. Não sei exatamente o que causou o problema (sei que estava relacionado ao memcache e / ou verniz), mas a solução foi configurar um balanceador de carga para o (s) servidor (es). Portanto, você deve conversar com o administrador do servidor sobre isso.
precisa saber é o seguinte

11
Qual é a versão magento? Além disso, o que você está usando como armazenamento de sessão? A mudança para arquivos ou banco de dados, respectivamente, faz a diferença?
Kristof at Fooman

@Fooman Olá, o EE 1.11.2.0, usando a sessão de banco de dados, não tentou trocar para arquivos, relatará qual resultado isso dará.
ProxiBlue

Respostas:


8

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


@ProxiBlue resolveu o seu problema, pois é a resposta aceita? Eu tenho problema quase idêntico. Ainda não tenho certeza do que está causando isso.
Dchayka

9

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.


Sem verniz, gostaria que fosse assim tão simples: '(
ProxiBlue 31/01

Oi tenho o mesmo problema posso saber qual é a solução?
Kandarp B Patel

@ Ben Por favor, você pode elaborar sobre isso.
Burntblark 22/10/2015

6

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.


O carrinho ainda está no http, portanto não no problema http-> https.
ProxiBlue

11
Isso está acontecendo conosco, em nosso ambiente UAT, e temos um IP fixo. Aprecie as sugestões.
ProxiBlue

5

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 ...


Fico feliz que isso não esteja acontecendo para alguns de nossos clientes. Mais 404 do que eu gostaria de admitir.
Philwinkle

2
@jonathanday Magento não fará isso, mas o Varnish mal configurado.
Ben Lessani - Sonassi

@sonassi, você pode expandir o verniz mal configurado pls? Temos tido o mesmo problema. A correção da página 404 corrigiu o problema, mas gostaria de saber se podemos configurar melhor o Varnish!
jmlnik

Isso era de fato o que estava acontecendo. De alguma forma eu perdi essa resposta! O fato é que o magento não deve empurrar a versão do controlador da página 404, mas uma página 404 estática.
ProxiBlue

11
Eu postei uma resposta que explica isso.
Ben Lessani - Sonassi

1

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).


Verificado, data / hora do servidor, se estiver bem, data / hora do cookie está bem :(
ProxiBlue 31/01

1

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


11
Boas sugestões. Vai tentar em alguns dias
ProxiBlue

1

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;

0

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

:) verificado disco primeira coisa, tudo ok.
ProxiBlue

date fine :( não é tão simples assim, ugh [~ / public_html / var / log] # date Qui 31/01 11:55:49 WST 2013
ProxiBlue 31/01
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.