Parece que WordPress dispara innecesariamente WP CRON en cada carga de página. Estoy pensando, en lugar de ejecutarlo en cada visita, ¿por qué no simplemente programarlo para que se ejecute cada 5 minutos a través del servidor? ¿Podría simplemente activar wp-cron.php cada cinco minutos y lograr el resultado deseado?
¿Hay alguna desventaja en esto?
Respuestas:
No hay inconvenientes para ejecutar WP CRON utilizando los trabajos cron del servidor. De hecho, esta es la práctica recomendada.
Según el documento oficial de desarrollo de plugins de WordPress :
WP-Cron no se ejecuta continuamente, lo que puede ser un problema si hay tareas críticas que deben ejecutarse a tiempo. Hay una solución fácil para esto. Simplemente configure el programador de tareas de su sistema para que se ejecute en los intervalos que desee (o en el momento específico necesario).
Para hacer esto, primero debe deshabilitar el comportamiento cron predeterminado en wp-config.php:
define('DISABLE_WP_CRON', true);Luego, programe wp-cron.phpdesde su servidor. Para Linux, eso significa:
crontab -eSin embargo, en lugar de ejecutarlo en la línea de comandos (CLI), ejecútelo como una solicitud HTTP. Para eso puedes usar wget:
*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cronWordPress carga todos los archivos principales necesarios, complementos, etc. wp-cron.phpcon el siguiente CÓDIGO:
if ( !defined('ABSPATH') ) {
/** Set up WordPress environment */
require_once( dirname( __FILE__ ) . '/wp-load.php' );
}Así que no se preocupe si WordPress no carga características importantes.
define('DISABLE_WP_CRON', true);desactiva solo esa parte del proceso cron y luego llama al script cron con un código como: */5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cronen el servidor se asegura de que se ejecuten los trabajos cron. Cualquier complemento de programación ni siquiera sabrá la diferencia.
Hay un par de inconvenientes: en primer lugar, cuando se usa wp-cron.php como cli, no se establecen cosas como las variables $ _SERVER. La gente supera esta limitación mediante el uso de una solicitud curl para wp-cron.php.
En segundo lugar, porque WP no está cargado con wp-cron.php; si usa un complemento de envío SMTP, este no se cargará cuando llame a wp-cron. Nuevamente, el uso de una llamada curl anula este problema. Curl parece ser el método más utilizado.
Sin embargo; Prefiero usar wp-cli después de configurar los ajustes de correo en postfix y (para nginx) php-fpm config correctamente y configurar un crontab como
*/5 * * * * wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1(Enumere todos los crons con campos específicos en formato csv: el gancho es el nombre del cron, la próxima ejecución relativa es el momento. Elimine los que muestran 'ahora' como la próxima ejecución (los que vencen ahora) usando AWK, pase esa lista a xargs a llame wp cron event run $HOOKa cada cron.) El uso de wp-cli carga WordPress correctamente (elijo omitir complementos al enumerar los crons, ya que los errores de código y las advertencias de php arruinarán la salida con script; pero no los omitiré cuando ejecute el cron con xargs, como el cron puede necesitar que se carguen los complementos)
Espero que esto te dé algunos consejos sobre qué buscar.
Hay muchas razones para no deshabilitar el wp-cron. De hecho, es casi imposible encontrar un caso de uso para hacer esto. No ralentiza su sitio y se usa para cosas de las que puede no estar al tanto.
Muchos complementos usan el WP-Cron para programar cosas. Pueden confundirse si apaga el programador.
Hay una proliferación de tutoriales sobre este tema porque es confuso y porque no hace mucho a su sitio cuando lo deshabilita. Lo que hará es causar dolor de cabeza al desarrollador que tiene que solucionar el misterioso problema que crea en seis meses.
Además, WP Heartbeat se dispara cada 15 segundos en el área de administración, resolviendo este problema para el 99% de las personas que piensan que lo tienen.
Todavía tengo que encontrar una verdadera desventaja para descargar wp-cron a un servicio externo. Haciendo esto por muchos años ahora.
Especialmente en el mundo de hoy donde puede ejecutar aplicaciones como microservicios.
Utilizo contenedores Docker separados para cada componente de WordPress: php, web, db, crontab, redis, etc. Tener crontab como contenedor separado, llamar a wp-cron a través de http utilizando la red local, ejecutándose solo cuando lo necesito.
Esto reduce el estrés en los nodos del backend y mejora la seguridad al tener una superficie de ataque más pequeña.
Si el desarrollador no puede descubrir cómo hacer cosas sin tener que llamar a wp-cron en cada carga de la página, diablos, esto solo habla de inexperiencia en su nombre. "Dejarlo solo", porque no entiendes cómo funcionan las cosas, no es una buena razón para mantenerlo.
wget http://YOUR_SITE_URL/wp-cron.phpsin agregar?doing_wp_cron¿Entonces, uno es mejor que el otro? ¿Qué hace la adición de?doing_wp_cronque la no versión no lo hace?