El cron de PrestaShop no se ejecuta: la avería invisible

La avería de la que nadie se entera

Un cron de PrestaShop que no se ejecuta no provoca ningún error visible. La tienda funciona, los pedidos entran. Pero el feed de productos que se envía a los comparadores tiene tres semanas, el stock ya no se sincroniza con el ERP, los recordatorios de carrito abandonado no salen y la exportación contable del mes está vacía.

El comerciante descubre el problema por un tercero: un cliente que compra un producto agotado o un contable que reclama un archivo. Mientras tanto, se han acumulado varias semanas de daños.

El malentendido de partida

El módulo ps_cronjobs es un planificador interno, no un disparador. Lleva la lista de tareas y sabe cuál toca ejecutar, pero no se despierta solo: hace falta que una tarea programada real, configurada en su alojamiento, llame a su URL a intervalos regulares.

Muchas instalaciones se quedan ahí: las tareas se crean en el back-office, todo parece correcto y no se ejecutará nada jamás. El módulo propone a veces apoyarse en el tráfico de los visitantes para dispararse, algo imprevisible e inservible para una tarea que debe correr a hora fija.

Las cinco causas reales

1. No hay ninguna tarea programada en el alojamiento. Mírelo en el panel de administración de su alojamiento, en la sección «tareas programadas» o «cron». Si la lista está vacía, ya lo tiene.

2. La versión de PHP equivocada. Es la trampa de los alojamientos compartidos. Las tareas programadas se ejecutan con el PHP de línea de comandos, cuya versión suele ser distinta de la que usa el sitio. El script se topa entonces con un PHP antiguo y falla al instante, sin que nadie lea la salida. Hay que indicar la ruta absoluta del intérprete correcto:

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

3. Un token inválido. La URL de las tareas contiene un token de seguridad. Cambia al reinstalar el módulo o al modificar su configuración. Todas las tareas registradas en el alojamiento devuelven entonces un error de autorización, en silencio.

4. Una llamada bloqueada. Una tienda protegida con autenticación HTTP, una regla del cortafuegos de aplicaciones web o una restricción de acceso por dirección IP devuelve un error antes incluso de llegar a PrestaShop.

5. Un exceso del tiempo de ejecución. Una tarea pesada, como la reindexación del buscador o una exportación de catálogo voluminosa, supera el límite permitido y se corta a medias. En el peor de los casos, deja datos procesados solo en parte.

El diagnóstico en tres minutos

Prueba 1: ¿funciona la tarea por HTTP? Copie la URL completa de la tarea, token incluido, y ábrala en una ventana de navegación privada. Si se ejecuta, el problema no está en PrestaShop, sino en el disparo externo.

Prueba 2: ¿funciona por línea de comandos? Ejecútela por SSH con la ruta absoluta del intérprete de PHP. Un mensaje de error de sintaxis apunta a una versión de PHP inadecuada.

Prueba 3: ¿qué dice el registro? Añada siempre una redirección de la salida en su tarea programada:

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

Sin registro, diagnostica a ciegas. Es la modificación más rentable de todo este artículo.

La configuración recomendada

Prefiera la llamada HTTP a la ejecución por línea de comandos para las tareas de PrestaShop. Con wget o curl, el script se ejecuta en el mismo contexto que el sitio: misma versión de PHP, mismas variables de entorno, mismos permisos. Es la primera fuente de discrepancias que desaparece.

Espacie las tareas. Tres exportaciones de catálogo lanzadas en el mismo minuto saturan el servidor y se hacen fracasar entre ellas. Sepárelas unos minutos.

Elija las horas de menor actividad para los procesos pesados, teniendo en cuenta sus horarios reales de venta.

Ponga un límite de tiempo a sus scripts pesados y trocéelos por lotes. Una exportación de 50 000 referencias debe procesarse por tramos, con un punto de reanudación.

Vigilar o nada

Un cron mudo sigue siendo una avería invisible, por bien configurado que esté. La única protección consiste en vigilar su ejecución.

El principio es sencillo: al terminar, su tarea llama a una URL de control que le facilita un servicio de supervisión. Si esa llamada no llega dentro de la ventana prevista, usted recibe una alerta. Se entera de que la tarea no se ha ejecutado, no solo de que ha dado error: es justo lo que aquí falta.

A falta de una herramienta externa, una revisión semanal basta para limitar los daños: comprobar la fecha del último feed generado, la de la última exportación contable y la frescura de la sincronización de stock.

Sobre este mismo asunto: los correos de recordatorio que no salen suelen deberse a un cron mudo más que a un problema de envío. Consulte el diagnóstico de los correos de PrestaShop.

Ponga a punto sus tareas programadas

Auditamos sus tareas, corregimos su disparo e implantamos la vigilancia. Consulte nuestra oferta de gestión de tienda online.