Probablemente no conozcas, si no eres muy experto en informática, qué es un cron. La razón es que no es algo que se suela dejar editar de forma sencilla desde el CMS y en muchos casos, además, ni siquiera existe esa necesidad. Los crones son tareas que el gestor de contenidos ejecuta automáticamente cada cierto tiempo y que son vitales para el correcto mantenimiento del mismo y su actualización.
¿No estás contento con tu CMS? ¿Deseas migrar a uno mejor y ahorrar costes?¿No consigues la audiencia que deseas?
Está claro: necesitas un experto digital
Mediante el cron se puede configurar una larga lista de tareas, como puede ser la comprobación de actualizaciones cada cierto tiempo, comprobar si hay artículos que hay que publicar o despublicar cuando llegue una determinada fecha, realizar copias de seguridad y un largo etcétera.
Es fácil entender que los crones mal configurados en el gestor de contenidos pueden llevar a sobrecarga del servidor, retrasos en publicaciones y actualizaciones y a la producción los famosos errores de servidor, por lo que hay muchos artículos que recomiendan optimizarlo.
Hay que recordar igualmente, si trabajas con un CMS de código abierto u open source, que no solo el núcleo cuenta con crones. También las extensiones y plugins se subirán al carro y consumirán recursos. Sin duda es una nueva razón de peso para pensarse bien qué instalamos. Eso sí, los crones se ejecutan en segundo plano y, por otro lado, existen sistemas de caché que pueden minimizar su impacto.
El problema del cron en WordPress
El principal problema que puede aparecer en WordPress es la configuración por defecto: el cron se dispara cada vez que la web recibe una visita. Esto significa que si este humilde blog llega a recibir 1.000 visitas por minuto, el cron se ejecuta y revisa todas las tareas 1.000 veces por minuto, lo que supone una paliza en toda regla para el servidor si no está bien dimensionado. Cuando se habla de que WordPress no es muy escalable de serie probablemente es por detalles como éste.
En WordPress el cron se dispara cada vez que la web recibe una visita
Aunque en muchos sitios se asegura que esta configuración por defecto es absurda, lo cierto es que tiene bastante sentido. WordPress es responsable de un grandísimo número de instalaciones y la inmensa mayoría de ellas son de bajo tráfico y con esta configuración, todo funciona siempre correctamente. A partir de un buen nivel de tráfico, el webmaster debería saber y poder controlar el cron a su gusto y necesidades. Además, no confía en el servidor y maneja los crones por sí mismo.
Si buscas información sobre el Cron de WordPress en Google, encuentras miles de artículos recomendando desactivar este comportamiento y activar la ejecución en el servidor del cron cada X tiempo, a tu elección, pero siempre dentro de un intervalo entre 5 y no más 30 minutos, dependiendo de tu tráfico y nivel de actualización.
Este proceso de optimización, mil veces explicado, aunque no es muy complicado, cuenta con varios inconvenientes, como por ejemplo que hay que acordarse de revertirlo cuando cambiemos de hosting.
Los crones en Drupal
Mientras que para la inmensa mayoría de usuarios de WordPress el cron es el gran desconocido y, de hecho, a nadie le importa, Drupal, siempre más profesional y riguroso, lo ofrece en su configuración.
Y las opciones ahí son abrumadoras con respecto a su rival, ya que permite hacer funcionar el cron cuando se desee, ya sea dentro del backend o desde fuera mediante url con clave secreto, conseguir un registro del cron y decidir el plazo de ejecución del cron. ¡Y todo ello sin acudir al servidor!
Drupal, siempre más profesional y riguroso, ofrece diversas opciones de configuración en el core
Eso sí, el funcionamiento es similar al de WordPress y solo se ejecuta si hay tráfico en el site. Para crones y tareas importantes, es mejor confiar en la configuración del servidor.
Mi experiencia con los crones
Mientras trabajaba en Bitban recibí algunas peticiones de ajustes de crones. La que mejor recuerdo es la petición que nos hicieron para asegurarse de que la barra de “breaking news”, es decir, noticias urgentes, tardaba 5 minutos en aparecer y necesitaban que se activara inmediatamente al publicarla.
En este caso la solución fue tocar la prioridad de los crones y poner dicha barra entre las más prioritarias del CMS, las que en condiciones de igualdad, el sistema elegirá ejecutar antes que las otras.