La pesadilla que es wp-cron.php

Una queja importante que tengo con WordPress es la implementación por defecto de wp-cron.php. Si usted está familiarizado con la forma en que WordPress utiliza wp-cron.php por defecto, es posible que desee saltar a la siguiente sección de este artículo.

El archivo wp-cron.php es la parte de WordPress que maneja los eventos programados dentro de un sitio de WordPress. Todo lo que tiene que ver con la programación de entradas o publicaciones y realmente cualquier cosa orientada a la fecha/hora se rige por el archivo wp-cron.php.

Para que wp-cron.php funcione correctamente, necesita ser ejecutado con frecuencia, pero no más de una vez por minuto. Sin embargo, el comportamiento por defecto no requiere que usted configure un verdadero trabajo cron a nivel de sistema en su servidor. En lugar de ello, utiliza un método de «piggyback» en cada solicitud entrante. Cuando una petición entra en el sitio, WordPress generará una petición adicional de sí mismo al archivo wp-cron.php a través de HTTP(S). Eso suena bastante inocuo, ¿verdad?

¿Por qué el comportamiento por defecto de wp-cron.php es una pesadilla?

El método por defecto funciona perfectamente bien en un sitio pequeño con muy pocos visitantes por hora. Sin embargo, cuando se implementa en un sitio mediano o más grande o incluso un sitio que está siendo escaneado por bots (que es muy común en estos días), esto significa que usted obtiene el doble de cualquier tráfico que está manejando actualmente. Se convierte en un rudimentario ataque DDoS contra ti mismo. Esto se debe a que el cron se ejecuta varias veces por minuto mediante una petición HTTP. La petición HTTP genera una sobrecarga adicional al tener que generar, negociar y establecer la conexión a través de un socket de red. Incluso afecta a la capacidad efectiva de su servidor web subyacente. Esta solución no funciona bien en la mayoría de las situaciones, y honestamente, debería ser eliminada como comportamiento por defecto debido a su propensión a ser abusada o convertida en un vector de ataque en un servidor sólo por el tráfico regular.

Bueno, ¿cuáles son las alternativas?

La única alternativa real y la solución mucho mejor es configurar un cronjob regular del sistema que ejecute el script wp-cron.php directamente a través de PHP cada minuto. Esto asegura que cualquier tarea programada se ejecute efectivamente a su hora programada. Tampoco debe hacerse a través de una petición HTTP sino una ejecución directa de PHP para evitar entorpecer la capacidad del servidor web o generar una sobrecarga de memoria adicional en la capa de red.

¿Cómo desactivo el comportamiento predeterminado de wp-cron.php?

Esto es bastante universal y sencillo de hacer. Necesita actualizar su archivo wp-cronfig.php para incluir la siguiente configuración:

define('DISABLE_WP_CRON', true);

• Normalmente puede encontrar su archivo wp-config.php en el directorio public_html de su sitio.
• Este nuevo ajuste debe ser puesto en el archivo justo después de la línea de base de datos DB_COLLATE que se parece a lo siguiente

define('DB_COLLATE', '');

¿Cómo puedo configurar un trabajo de cron del sistema?

Esto es simple en cPanel, suponiendo que su proveedor de alojamiento ha habilitado la función de trabajo cron en su cuenta. La documentación de cPanel Cron Jobs entra en mayores detalles, pero esencialmente usted hace:

1. Ingrese a cPanel para su dominio: sudominio.tld/cpanel
2. Ingrese «cron» en el cuadro de búsqueda rápida cerca de la parte superior de la página.
3. Haga clic en el icono «Cron Jobs» que aparece.

• Si no aparece, su cuenta no tiene activada la función Cron Jobs y tendrá que hablar con su proveedor de alojamiento para que le ayude a configurar el cron o a cambiar a un paquete que incluya la función Cron Jobs.

1. Preste atención a la página Cron Jobs, le proporcionará la ubicación exacta de su binario PHP. Tendrá que copiar esa ruta en el cuadro de comandos en la parte inferior de la página y alterar el archivo que se ejecuta por PHP para ser su /home/nombre_de_usuario/public_html/wp-cron.php archivo en su lugar. Usando la ruta completa.
2. Seleccione la primera entrada («*») para cada parámetro. Esto ejecutará el archivo wp-cron.php cada minuto.
3. Pulsa ese botón de añadir cron y listo.

¿Por qué eres tan duro con esta práctica, parece razonable y fácil de arreglar?

Creo que corresponde a los ingenieros de software que desarrollan nuestro mundo digital inculcarse un sentido de responsabilidad por sus productos. WordPress es omnipresente en estos días y con el software de instalación automática, como Softaculous, WordPress se instala en una gran mayoría de sitios. Se instalan con el comportamiento por defecto activado, que es esencialmente un vector de ataque en cualquier servidor. Ahora que la industria del hosting está tan presente en nuestras vidas, mucha gente tiene sitios de WordPress y no sabe de este problema hasta que paraliza su sitio. La integración por defecto es muy inadecuada y debería ser eliminada. Hoy, en un solo servidor, he encontrado más de 500 instalaciones diferentes de WordPress y he visto cómo un bot atacaba cada sitio del servidor. Cada uno de esos sitios se convirtió repentinamente en una carga para la estabilidad del servidor.

Se que este problema se maneja caso por caso. Sin embargo, con tantas instalaciones en todo el mundo, sería mejor que lo solucionara WordPress en lugar de cada proveedor de alojamiento que tiene que establecer condiciones especiales en su servidor para protegerse del agujero que genera este software. El coste de eliminar este comportamiento y obligar a los propietarios de sitios a generar un cron del sistema debería ser la línea de base y colocar un aviso dentro de la interfaz de administración de WordPress de que las tareas programadas no se ejecutarán hasta que se cree un trabajo cron del sistema correctamente. Esto está dentro de mis habilidades de programación, así que sé que está bien dentro de los suyos.

WordPress tiene como objetivo la facilidad de uso, por lo que sus consumidores objetivo son aquellos que normalmente saben poco acerca de las advertencias de alojamiento. Creo que la responsabilidad aquí es enteramente de WordPress para arreglar y han tomado la postura en contra. Mientras tanto, los administradores de sistemas en la industria del alojamiento tienen que sufrir esta terrible «característica» al examinar los servidores que han caído fuera de control debido a un bot que se ejecuta sobre una instalación de WordPress por defecto.