Gestión de tareas programadas con crontab real frente a WP-Cron simulado

Gestión de tareas programadas con crontab real frente a WP-Cron simulado

En hosting compartido conviven limitaciones técnicas y la necesidad de ejecutar tareas programadas de WordPress (copias de seguridad, publicaciones programadas, limpiezas, syncs). Aquí comparo el WP-Cron simulado con un crontab real, explico cuándo y cómo migrar, y doy ejemplos prácticos y seguros adaptados a entornos compartidos.

Qué es WP-Cron simulado y por qué existe

WordPress implementa un sistema de pseudo-cron conocido como WP-Cron que se activa en cada carga de página para comprobar y ejecutar trabajos programados. Esto evita depender de un cron del sistema en instalaciones donde no hay acceso a «cron» o a tareas programadas del servidor.

WP-Cron es útil en entornos sin acceso a crontab, pero tiene limitaciones visibles:

  • Dependencia del tráfico: las tareas sólo se ejecutan cuando hay visitas.
  • Imprecisión: los tiempos pueden retrasarse minutos u horas.
  • Impacto en rendimiento: ejecución en proceso web puede incrementar tiempos de respuesta.
  • Acumulación y picos: tareas demoradas pueden dispararse simultáneamente.

Para entender el concepto general de «cron» a nivel de sistema, consulte la página de referencia: Cron en Wikipedia.

Ventajas del crontab real frente a WP-Cron

Un crontab real, ya sea gestionado por el panel del hosting (cPanel, Plesk) o por un administrador del servidor, ofrece:

  • Fiabilidad temporal: ejecución puntual y repetible.
  • Desacoplamiento: procesa tareas fuera del ciclo de petición HTTP.
  • Control y monitoreo: salida, logs y notificaciones.
  • Menor carga en el front-end: evita latencia en páginas por ejecuciones largas.

En entornos compartidos esto reduce picos de uso de CPU en ejecución de php-fpm y evita que las visitas asuman la carga de mantenimiento.

Limitaciones del crontab en hosting compartido

No todo hosting compartido permite libertad total. Entre las restricciones habituales están:

  • Límites en la frecuencia mínima (p. ej. mínimo 15 minutos).
  • Sin acceso SSH o sin la extensión PHP CLI disponible.
  • Políticas que prohíben scripts de larga duración o procesos en segundo plano.

Antes de planificar migrar, verifique el soporte de cron en su panel o consulte al soporte técnico del proveedor.

Cómo migrar: pasos prácticos y seguros

El proceso consiste en desactivar WP-Cron y programar un crontab que ejecute las tareas regularmente. Paso a paso:

1) Desactivar WP-Cron

Edite el archivo wp-config.php y añada:

define('DISABLE_WP_CRON', true);

Con esto evita la ejecución en cada carga de página.

2) Elegir método de ejecución en crontab

En hosting compartido normalmente hay tres alternativas prácticas:

  • Invocar la URL /wp-cron.php con wget o curl (actúa como visitante).
  • Usar PHP CLI para ejecutar un script que incluya wp-load.php (si PHP CLI está disponible).
  • Usar un servicio externo o Cron Trigger (por ejemplo, Cloudflare Workers) si el hosting limita cron.

3) Ejemplos de crontab útiles

Ejemplo típico en cPanel (cada 15 minutos):

*/15 * * * * /usr/bin/wget -q -O - "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

Si curl está disponible y prefiere más control:

*/15 * * * * /usr/bin/curl -s "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

Si dispone de PHP CLI (ver documentación de PHP CLI):

*/15 * * * * /usr/bin/php -q /home/usuario/public_html/wp-cron-cli.php >/dev/null 2>&1

Donde wp-cron-cli.php contiene un require de wp-load.php y validaciones de seguridad antes de ejecutar tareas.

4) Añadir seguridad: proteger la invocación

No deje /wp-cron.php accesible sin restricciones si lo invoca por web. Recomendaciones:

  • Agregar un token secreto en la URL y validarlo en un archivo personalizado que incluya wp-load.php antes de ejecutar acciones.
  • Restringir por IP vía .htaccess si su crontab usa un host fijo.
  • Usar HTTPS siempre para evitar exposición de parámetros.

Alternativas al crontab local en hosting compartido

Si su host no permite cron confiables, considere:

  • Servicios externos de cron (health checks, ping cron) que llaman su endpoint en intervalos regulares.
  • Cloudflare Cron Triggers o Workers para ejecutar tareas programadas desde la CDN; documentación en Cloudflare Docs.
  • Tareas programadas con WP-CLI en un servidor remoto si dispone de acceso cron a otro servidor.

Buenas prácticas operativas

Para garantizar robustez y facilidad de mantenimiento en hosting compartido:

  • Registre la salida: redirija stdout/stderr a archivos de log para depuración.
  • No programe intervalos demasiado cortos: en compartidos 5 minutos suele ser excesivo; 15 minutos es un compromiso.
  • Monitoree tiempos de ejecución y tasas de fallos; si detecta errores repetidos, revise plugins y hooks que se ejecutan en cron.
  • Evite ejecutar tareas intensivas (backups completos, exportaciones grandes) en horarios de pico; externalícelas o prográmelas en ventana nocturna.
  • Compruebe compatibilidad: algunos plugins asumen ejecución desde contexto HTTP; pruebe en staging antes de cambiar producción.

Ejemplo práctico: script seguro para cron con PHP CLI

Un enfoque robusto es crear un archivo cron-runner.php en una carpeta no accesible públicamente. Ejemplo esquemático:

<?php
// validar token opcional
require_once '/home/usuario/public_html/wp-load.php';
// Ejecutar hooks que WordPress programó
wp_maybe_auto_update(); // ejemplo: no es un patrón general
// Mejor: invocar funciones que disparen eventos o usar WP-CLI para mayor control
?>

Nota: la carga directa de WordPress por CLI puede comportarse distinto en comparación con ejecución web. Para correr tareas de cron específicas, WP-CLI ofrece comandos más seguros (instale en entorno que lo permita).

Monitoreo y resolución de problemas

Si las tareas no se ejecutan:

  • Verifique que DISABLE_WP_CRON esté activo y que el crontab esté creado correctamente.
  • Revise permisos de archivos y rutas absolutas en crontab.
  • Compruebe que PHP CLI exista y su versión sea compatible con WordPress; vea PHP CLI.
  • Analice logs del servidor y de su crontab; capture la salida para diagnosticar errores.

Resumen: cuándo elegir cada opción

  • Use WP-Cron simulado cuando no tenga acceso a cron y la precisión no sea crítica (sitios pequeños con tráfico regular).
  • Opte por crontab real cuando precise puntualidad, menor carga en peticiones web y control operativo (hosting que lo permita).
  • Si el hosting limita cron, combine cron externo seguro o servicios CDN con triggers como alternativa (vea la opción de Cloudflare Cron Triggers).

Consideraciones finales

En hosting compartido, la decisión entre WP-Cron y crontab real depende de acceso, tolerancia a la latencia y políticas del proveedor. Movilizar a un crontab real mejora la fiabilidad y el rendimiento, pero exige implementar medidas de seguridad y monitorización. Empiece por desactivar WP-Cron en staging, pruebe la invocación por URL o CLI, registre salidas y ajuste la frecuencia según las restricciones del proveedor.

Lecturas y referencias

Para profundizar en la operación de cron a nivel de sistema y herramientas relacionadas, consulte la documentación oficial de Cron y la guía de PHP CLI. Para alternativas basadas en la CDN y la nube, la guía de Cloudflare Cron Triggers es una buena referencia.

Conclusión

La mejor práctica en hosting compartido es priorizar la fiabilidad: cuando el entorno lo permite, desactive WP-Cron y programe un crontab real (o use alternativas externas controladas). Este cambio reduce la carga en las peticiones HTTP, mejora la puntualidad de las tareas y facilita el monitoreo. Si su hosting restringe cron, evalúe soluciones híbridas—invocaciones seguras por URL, scripts CLI o triggers externos—y siempre implemente logs y tokens de seguridad para proteger sus endpoints.

Tags: