PS PrestaShop PrestaShop Iniciante

Alertas de Erro 500, 404 e Checkout PrestaShop (DataFirefly Site Alerts)

Instalar o módulo, escolher os destinatários, configurar os alertas 404 e o cron, ler cada tipo de alerta.

Atualizado 26 Outubro 2026 Versão do módulo 1.0.0

O DataFirefly Site Alerts envia um e-mail para os endereços que escolher quando a sua loja PrestaShop 8 ou 9 devolve um erro 500, acumula erros 404, ou quando um cliente chega ao checkout sem nenhuma transportadora ou sem nenhum método de pagamento disponível. Esta documentação abrange a instalação, as definições, o conteúdo de cada alerta e a resolução de problemas.

Instalação

No back office, abra Módulos > Gestor de Módulos, clique em Carregar um módulo e envie o ficheiro dfsitealerts-1.0.0.zip.
O módulo cria a sua tabela e um separador Parâmetros Avançados > Alertas de erros e checkout. O botão Configurar do módulo leva diretamente até lá.
Na instalação, o endereço de e-mail da loja é usado como destinatário e as quatro deteções ficam ativas.
Clique em Enviar um e-mail de teste para verificar se os alertas chegam.

O módulo é compatível com PrestaShop 8.0 a 9.x e com multiloja. Não utiliza nenhuma dependência Composer. Os e-mails passam pela configuração de Parâmetros Avançados > E-mail: se os e-mails estiverem aí desativados, é apresentado um aviso no topo da página do módulo.

Painel

O topo da página mostra o número de problemas distintos detetados nas últimas 24 horas, por tipo: erro 500, erro 404, sem transportadora, sem método de pagamento, site inacessível. O mesmo URL ou o mesmo erro conta uma única vez. Abaixo encontram-se os destinatários atuais, o URL do cron e os botões Enviar um e-mail de teste, Executar a tarefa agendada agora e Esvaziar o registo.

Destinatários

Endereços de e-mail: um endereço por linha (vírgulas e pontos e vírgulas também são aceites). Cada endereço recebe o seu próprio e-mail. Um endereço inválido é recusado ao guardar.
Idioma dos alertas: idioma dos e-mails, independente do idioma dos visitantes. Por predefinição, o idioma predefinido da loja.

O que desencadeia um alerta

Cada deteção pode ser ativada ou desativada separadamente.

Erros de servidor (500)

No fim de cada pedido do front office, o módulo captura os erros fatais de PHP, as exceções não capturadas e qualquer página que responda com um estado 5xx. O modo de manutenção (503) é ignorado. O e-mail contém:

a mensagem de erro e a pilha de chamadas, com o caminho do servidor removido;
o tipo de erro PHP, o ficheiro e a linha em caminho relativo;
o URL, a página de origem, o método HTTP, o controlador e o user agent;
o pico de memória e as versões do PrestaShop e do PHP.

Quando o PrestaShop interceta uma PrestaShopException e apresenta a sua página de erro, não há nenhuma mensagem PHP disponível: o módulo retoma a última entrada do ficheiro var/logs/AAAAMMDD_exception.log do dia. Os erros idênticos são agrupados, sendo os números variáveis (identificadores, tamanhos de memória) ignorados no agrupamento.

Páginas não encontradas (404)

Os 404 são agrupados por caminho de URL. Os parâmetros que identificam uma página (controller, id_product…) são mantidos, os parâmetros de rastreamento (utm_*, gclid, fbclid, msclkid…) são ignorados. É enviado um alerta de acordo com as definições da secção seguinte.

Checkout sem transportadora

A deteção é desencadeada quando um cliente chega à etapa de envio com uma morada de entrega e um carrinho não vazio e não virtual, e nenhuma transportadora é proposta. Os problemas são agrupados por país e por distrito/estado. O e-mail contém:

o ID do carrinho e do cliente, o país, o distrito/estado, o código postal e a zona;
o peso e o total do carrinho, a lista de produtos e o grupo do cliente;
Transportadoras ativas para esta zona e grupo, com o motivo da ausência de cada uma: fora dos intervalos de peso, fora dos intervalos de preço, dimensões da embalagem demasiado grandes, excluída por restrições de produtos ou divisão de embalagens, ou não devolvida para este carrinho (módulo de transportadora ou portes indisponíveis);
Produtos limitados a algumas transportadoras: os produtos do carrinho que têm transportadoras selecionadas no separador Envio.

Se nenhuma transportadora ativa estiver associada à zona e ao grupo do cliente, o alerta indica-o diretamente.

Checkout sem método de pagamento

A deteção é desencadeada quando um cliente chega à etapa de pagamento com um carrinho a pagar e nenhum módulo de pagamento propõe uma opção. Um carrinho gratuito (total 0) não é abrangido. Os problemas são agrupados por país, moeda, transportadora e grupo. O e-mail contém o país, a moeda, a transportadora selecionada, o total, o grupo do cliente e depois:

Módulos de pagamento ativos: todos os módulos de pagamento instalados e ativados;
Módulos de pagamento permitidos para este país, moeda, grupo e transportadora: os que as restrições de Pagamento > Preferências deixam passar para este cliente.

Se a segunda lista estiver vazia, a causa está nas restrições. Se contiver módulos, esses módulos estão permitidos mas não devolveram nenhuma opção: a causa está na sua própria configuração (montante mínimo, conta não ligada, modo de teste).

Definições 404

Limiar de alerta: é enviado um alerta quando o mesmo URL atinge este número de visitas desde o último alerta. 5 por predefinição, 1 para alertar logo na primeira visita.
Alerta imediato para ligações internas quebradas: quando a página de origem pertence à sua loja, o alerta é enviado logo na primeira visita, independentemente do limiar.
Ignorar bots: motores de pesquisa, crawlers de SEO, scripts e user agents vazios.
Ignorar ficheiros estáticos: imagens, CSS, JS, tipos de letra e vídeos.
URLs a ignorar: um caminho por linha, * corresponde a qualquer sequência de caracteres. A lista predefinida ignora os scans habituais: /wp-*, /wordpress/*, /xmlrpc.php, */.env, */.git/*, /cgi-bin/*, *phpmyadmin*, /.well-known/*, /apple-touch-icon*.

Limites de envio e resumo diário

Intervalo entre dois alertas para o mesmo problema: 60 minutos por predefinição. As ocorrências registadas durante esse intervalo são contadas e indicadas no alerta seguinte, na linha «Ocorrências desde o último alerta».
Máximo de alertas por hora: 20 por predefinição, 0 para nenhum limite. Os problemas acima do limite continuam registados e constam do resumo.
Resumo diário: um e-mail por dia à hora escolhida (8:00 por predefinição), que lista cada problema registado desde o resumo anterior, incluindo os que ficaram abaixo do limiar de alerta. Não é enviado se nada tiver acontecido.
Manter o registo durante: 30 dias por predefinição, de 1 a 365.

Tarefa agendada

Os alertas 500, 404 e de checkout são enviados em tempo real. A tarefa agendada envia o resumo diário à hora prevista, reprocessa os alertas que não puderam ser gravados na base de dados, limpa o registo e executa a verificação de disponibilidade. Uma execução a cada 15 minutos é suficiente.

Cron por URL

*/15 * * * * curl -fsS "https://a-sua-loja.pt/module/dfsitealerts/cron?token=…" > /dev/null

O URL exato, com o respetivo token, é apresentado na página do módulo com um botão Copiar. Responde em JSON e funciona também em modo de manutenção. Um token inválido devolve um erro 403.

Cron pela linha de comandos

*/15 * * * * php /caminho/para/prestashop/modules/dfsitealerts/cron.php > /dev/null

O comando processa todas as lojas ativas em multiloja.

Sem cron

Após uma visita normal à loja, o módulo executa a manutenção no máximo uma vez a cada 15 minutos. O resumo é, portanto, enviado após a primeira visita que se segue à hora prevista. A verificação de disponibilidade não é executada neste modo.

Verificação de disponibilidade

Alguns erros 500 ocorrem antes do arranque do PrestaShop (falha do PHP-FPM, ficheiro de configuração danificado): nenhum módulo os consegue então capturar. A verificação de disponibilidade carrega a partir do servidor, em cada execução do cron, os URLs indicados em URLs a testar (10 no máximo, a página inicial se a lista estiver vazia). Uma resposta 5xx ou uma ligação impossível desencadeia o alerta A verificação de disponibilidade falhou, com o código HTTP, o tempo de resposta e o erro de ligação. Um 503 é ignorado quando a loja está em modo de manutenção.

Adicione uma página de categoria e uma página de produto para uma melhor cobertura. Para uma falha total do servidor, que também impede o cron de ser executado, utilize adicionalmente um serviço externo de monitorização de disponibilidade.

Registo de alertas

A lista no fundo da página mostra cada problema registado: tipo, localização (URL, ou país / moeda / transportadora para o checkout), mensagem ou página de origem, número de ocorrências, primeira e última ocorrência, data do último alerta. Pode ser filtrada por tipo e exportada em CSV. O botão Ver abre uma ficha com o mesmo conteúdo do e-mail e os dados brutos em JSON. Eliminar uma entrada repõe o seu contador a zero.

Dados e privacidade

Os alertas de checkout contêm o ID do carrinho e do cliente, o país, o distrito/estado, o código postal, o peso e o conteúdo do carrinho. Não contêm nome, morada, e-mail nem telefone.
O caminho do servidor é removido das mensagens de erro e das pilhas de chamadas.
O registo é limpo após o período de conservação escolhido.
Quando a base de dados recusa a escrita, o alerta é guardado num ficheiro em var/logs (2 MB no máximo) e reprocessado na execução seguinte da manutenção.

Limitações conhecidas

Só o front office é monitorizado. Os erros do back office não desencadeiam alertas.
Uma falha total do servidor ou do PHP impede qualquer envio de e-mail: utilize um serviço externo de monitorização de disponibilidade.
As deteções de checkout baseiam-se no processo de encomenda nativo do PrestaShop. Com um módulo de checkout numa só página de terceiros, o alerta de transportadora depende da chamada ao hook displayBeforeCarrier e o alerta de pagamento só é avaliado depois de escolhida uma transportadora.
O envio após a apresentação da página requer PHP-FPM ou LiteSpeed. Com outro modo de execução do PHP, o e-mail é enviado antes do fim do pedido.

Resolução de problemas

O e-mail de teste não chega

Verifique Parâmetros Avançados > E-mail e envie um e-mail de teste a partir dessa página. Verifique também a pasta de spam: adicione o endereço de envio da loja aos seus contactos.

Recebo demasiados alertas 404

Aumente o Limiar de alerta, adicione os caminhos em causa a URLs a ignorar, ou crie os redirecionamentos 301 em falta: um URL redirecionado deixa de devolver 404.

Nenhum alerta de checkout apesar de um cliente se ter queixado

Verifique se as duas deteções de checkout estão ativas e se o cliente chegou de facto à etapa em causa com uma morada. Com um módulo de checkout numa só página de terceiros, consulte a secção Limitações conhecidas.