Antes de chamar alguém: o que copiar da tela
A primeira coisa não é recarregar a página nem pedir para limpar cache. É guardar o que a tela mostra, porque algumas mensagens mudam ou somem quando alguém mexe no servidor:
- print da tela inteira, com a barra de endereço aparecendo;
- o número do registro, quando houver (a linha Error log record number);
- data e horário com fuso, por exemplo 25/09 às 14h12, horário de Brasília;
- onde acontece: só no checkout, só numa categoria, na loja inteira, também no admin;
- o que mudou nas últimas horas: deploy, extensão instalada, aviso da hospedagem.
As telas de erro do Magento, uma por uma
Os textos abaixo são os padrões, conferidos no código do Magento 2.4.9 e, na linha do Varnish, na configuração padrão do próprio Varnish. Uma loja personalizada pode trocar o visual, mas a lógica é a mesma.
| O que aparece | O que costuma indicar | Quem normalmente resolve | A loja vende? |
|---|---|---|---|
| There has been an error processing your request, com a linha Error log record number | Falha dentro do Magento: código de extensão, configuração, banco que não respondeu | Suporte Magento (com a hospedagem, se o banco caiu) | Não na página afetada; pode ser uma página só ou a loja toda |
| Service Temporarily Unavailable | Modo de manutenção ligado, em geral por atualização ou deploy em andamento ou interrompido | Quem fez o deploy ou o suporte Magento | Não, para quem não está na lista de IPs liberados |
| Error 503 Backend fetch failed, com Guru Meditation e XID | O Varnish, que fica na frente da loja, não conseguiu resposta do servidor da aplicação | Hospedagem ou infraestrutura, junto com o suporte Magento | Parcialmente: páginas já guardadas no cache podem abrir; carrinho e checkout não |
| An error has happened during application run. See exception log for details. em texto puro | Erro grave antes de o Magento conseguir montar a página de erro padrão | Suporte Magento | Não |
| Página totalmente em branco | Erro fatal do PHP que nem o Magento conseguiu capturar, como falta de memória | Suporte Magento e hospedagem | Não |
| Loja sem CSS e sem imagens, com o layout desmontado | Arquivos estáticos ausentes depois de deploy ou atualização, ou endereço de CDN errado | Suporte Magento ou quem configura a CDN | Mal: o checkout do Magento depende de JavaScript |
| 404 error: Page not found. em tela crua, sem o visual da loja | O Magento não conseguiu abrir a loja pedida, por exemplo uma visão de loja desativada | Suporte Magento | Não naquela loja |
| Aviso no admin: One or more indexers are invalid. Make sure your Magento cron job is running. | Índices desatualizados; a própria mensagem manda conferir o cron | Suporte Magento | Sim, mas preço, estoque e categoria podem aparecer errados |
Atenção às duas telas de 404. A página com o visual da loja (no texto padrão, Whoops, our bad...) é o 404 normal de um endereço que não existe. A tela crua, só com 404 error: Page not found., é outra coisa: o Magento nem chegou a montar a loja.
Service Temporarily Unavailable: manutenção do Magento ou recado do servidor?
O modo de manutenção do Magento aceita uma lista de IPs liberados. Pela documentação da Adobe, se o arquivo var/.maintenance.flag existe, a loja devolve a página de manutenção; se o IP de quem acessa está em var/.maintenance.ip, a página é ignorada para aquele acesso.
Daí a confusão: quem fez o deploy abre a loja e vê tudo funcionando, enquanto o cliente vê Service Temporarily Unavailable. Se alguém da equipe diz que "aqui está normal", peça para testar de uma conexão de celular, fora da rede do escritório. A loja só está no ar quando abre para todo mundo.
Um detalhe para não mandar o chamado errado: a página do Magento traz o título e um parágrafo sobre maintenance downtime or capacity problems. Se a tela mostra 503 Service Temporarily Unavailable, com a palavra nginx embaixo, ela é a página padrão do servidor web, e não do Magento. Ela aparece, por exemplo, quando o servidor recusa acessos por limite de requisições. Aí a hospedagem entra primeiro.
Error log record number: o que mandar ao suporte
O número que aparece em Error log record number identifica um arquivo de relatório gravado pelo Magento na pasta var/report do servidor. É ali que está a mensagem técnica e o caminho do erro. Fora do modo de desenvolvedor, o Magento registra o erro em arquivo e não mostra os detalhes ao visitante; a tela avisa isso com a frase Exception printing is disabled by default for security reasons.
Não peça para ligar a exibição do erro na tela em produção: ela expõe caminhos e detalhes internos para qualquer visitante. Mande ao suporte o número completo, o horário e a URL. Com esses três dados, quem tem acesso ao servidor acha o relatório certo sem adivinhar.
Hospedagem, CDN ou suporte Magento: para quem mandar primeiro
A regra prática que eu uso é seguir a camada que a tela aponta:
- Tela com texto do Magento (erro de processamento, texto puro de erro, 404 cru, aviso de índice): suporte Magento primeiro.
- Tela do Varnish (Backend fetch failed, Guru Meditation): a aplicação atrás do cache não respondeu. Suporte Magento e hospedagem juntos, porque a causa pode estar no servidor ou no código.
- Loja desmontada, sem CSS: suporte Magento, e a CDN se a loja usa uma.
- Manutenção: quem estava mexendo na loja, antes de qualquer outra pessoa.
E um cuidado que evita estrago: não rode comando nem limpe cache às cegas. Limpar cache não conserta a causa. Se a loja parou, fale comigo pelo suporte técnico de urgência e mande junto o print, o número do registro e o horário.
Perguntas frequentes
O que significa There has been an error processing your request no Magento?
É a tela padrão que o Magento mostra quando acontece uma falha que ele não conseguiu tratar: código de extensão, configuração ou banco que não respondeu. O detalhe técnico fica gravado num relatório no servidor, identificado pelo número em Error log record number. Quem resolve normalmente é o suporte Magento.
Service Temporarily Unavailable na loja Magento é problema da hospedagem?
Em geral, não. A página do Magento com esse título é a do modo de manutenção, ligado durante atualização ou deploy; se ficou ligada, um deploy pode ter parado no meio. A exceção é a tela com 503 antes da frase e a palavra nginx embaixo: essa vem do servidor web, e aí a hospedagem entra primeiro.
O que mandar ao suporte junto com o Error log record number?
O número completo, a data e o horário com fuso, a URL onde o erro aparece e um print da tela. Diga também se o erro acontece na loja toda ou em uma página só e o que mudou nas últimas horas. Com isso, quem tem acesso ao servidor encontra o relatório certo rapidamente.
Por que a loja Magento ficou sem CSS depois de uma atualização?
Em modo de produção, o Magento serve os arquivos de estilo, script e imagem do tema a partir da pasta pub/static, gerada no deploy. Se essa etapa falhou ou não rodou, a loja abre desmontada. Também pode ser o endereço da CDN configurado errado. O suporte Magento confere e refaz o deploy dos arquivos.
O que causa página em branco na loja Magento?
Normalmente um erro fatal do PHP que acontece antes de o Magento conseguir montar qualquer página de erro, como falta de memória. Como o modo de produção não exibe detalhes, o visitante vê só a tela branca. Os detalhes costumam ficar nos logs do PHP e do servidor web, que o suporte Magento e a hospedagem conseguem consultar.
Fontes oficiais
- Enable or disable maintenance mode (Adobe Experience League)
- Application modes (Adobe Experience League)