Cron do PrestaShop que não funciona: a avaria invisível

A avaria de que ninguém dá conta

Um cron do PrestaShop que não funciona não provoca nenhum erro visível. A loja funciona, as encomendas chegam. Mas o feed de produtos enviado aos comparadores tem três semanas, os stocks deixaram de sincronizar com o ERP, os lembretes de carrinho abandonado não saem e a exportação contabilística do mês está vazia.

O comerciante descobre o problema por terceiros: um cliente que encomenda um produto esgotado, ou um contabilista que reclama um ficheiro. Entretanto, acumularam-se várias semanas de estragos.

O equívoco de partida

O módulo ps_cronjobs é um agendador interno, não um disparador. Mantém a lista das tarefas e sabe qual delas deve ser executada, mas não acorda sozinho: é preciso que uma tarefa agendada real, configurada no seu alojamento, chame o URL dele a intervalos regulares.

Muitas instalações ficam por aqui: as tarefas são criadas no back-office, tudo parece correto e nada será alguma vez executado. O módulo propõe por vezes apoiar-se no tráfego dos visitantes para se disparar, o que é imprevisível e inutilizável para uma tarefa que tem de correr a horas fixas.

As cinco causas reais

1. Nenhuma tarefa agendada do lado do alojamento. Verifique no painel de administração do alojamento, secção «tarefas agendadas» ou «cron». Se a lista estiver vazia, já encontrou.

2. A versão errada do PHP. É a armadilha do alojamento partilhado. As tarefas agendadas correm com o PHP de linha de comandos, cuja versão é muitas vezes diferente da que o site usa. O script apanha então um PHP antigo e falha de imediato, sem que ninguém leia a saída. É preciso indicar o caminho absoluto do interpretador certo:

/usr/local/php8.2/bin/php /home/compte/site/modules/ps_cronjobs/cron.php

3. Um token inválido. O URL das tarefas contém um token de segurança. Muda quando o módulo é reinstalado ou quando a configuração é alterada. Todas as tarefas registadas no alojamento passam então a devolver um erro de autorização, em silêncio.

4. Uma chamada bloqueada. Uma loja protegida por autenticação HTTP, por uma regra de firewall aplicacional ou por uma restrição de acesso por endereço IP devolve um erro antes mesmo de chegar ao PrestaShop.

5. Um tempo de execução ultrapassado. Uma tarefa pesada, como a reindexação da pesquisa ou uma exportação de catálogo volumosa, ultrapassa o limite permitido e interrompe-se a meio. O pior cenário: deixa dados processados apenas em parte.

O diagnóstico em três minutos

Teste 1: a tarefa funciona em HTTP? Copie o URL completo da tarefa, token incluído, e abra-o numa janela de navegação privada. Se for executada, o problema não está no PrestaShop, mas no disparo externo.

Teste 2: a linha de comandos funciona? Execute-a por SSH com o caminho absoluto do interpretador de PHP. Uma mensagem de erro de sintaxe indica uma versão de PHP inadequada.

Teste 3: o que diz o registo? Acrescente sempre um redirecionamento da saída na sua tarefa agendada:

wget -q -O - "https://boutique.fr/modules/ps_cronjobs/cron.php?token=XXXX" >> /home/compte/logs/cron.log 2>&1

Sem registo, está a diagnosticar às escuras. É a alteração mais rentável de todo este artigo.

A configuração recomendada

Prefira a chamada HTTP à execução por linha de comandos nas tarefas do PrestaShop. Com o wget ou o curl, o script corre no mesmo contexto do site: mesma versão de PHP, mesmas variáveis de ambiente, mesmas permissões. É a primeira fonte de divergências eliminada.

Espace as tarefas. Três exportações de catálogo disparadas no mesmo minuto saturam o servidor e fazem-se falhar umas às outras. Desfase-as em alguns minutos.

Escolha as horas de menor tráfego para os processamentos pesados, tendo em conta os seus horários reais de venda.

Defina um limite de tempo para os scripts pesados e divida-os por lotes. Uma exportação de 50 000 referências tem de ser processada por blocos, com um ponto de retoma.

Monitorizar, ou nada feito

Um cron mudo continua a ser uma avaria invisível, mesmo bem configurado. A única proteção é monitorizar a sua execução.

O princípio é simples: no fim da execução, a sua tarefa chama um URL de controlo fornecido por um serviço de supervisão. Se a chamada não chegar dentro da janela prevista, recebe um alerta. Fica a saber que a execução não aconteceu, e não apenas que houve um erro — é exatamente isso que falta aqui.

Na falta de uma ferramenta externa, um controlo semanal chega para limitar os estragos: verificar a data do último feed gerado, a data da última exportação contabilística e a atualidade da sincronização de stock.

Sobre o mesmo tema, os e-mails de lembrete que não saem devem-se muitas vezes a um cron mudo e não a um problema de envio: veja o diagnóstico dos e-mails do PrestaShop.

Fiabilizar as suas tarefas agendadas

Auditamos as suas tarefas, corrigimos o respetivo disparo e implementamos a monitorização. Veja a nossa oferta de gestão de loja online.