¿Cómo funcionan exactamente las actualizaciones automáticas?

Esta mañana recibí un correo electrónico indicando que mi sitio de Wordpress se había actualizado automáticamente a la última versión. Conocía la función, pero siempre me he preguntado exactamente cómo funciona.

PHP no es un proceso de ejecución permanente: solo se ejecuta cuando se solicita. Por lo que puedo decir, Wordpress solo puede actualizarse cuando alguien carga una página web. Pero el proceso de actualización no es instantáneo, por lo que seguramente un usuario que visite el sitio tendrá una carga de página realmente lenta.

¿Hay algún truco diferente que usan para las actualizaciones automáticas? He buscado por todo el lugar pero no he encontrado ninguna explicación.

PHP no es un proceso de ejecución permanente: solo se ejecuta cuando se solicita. Por lo que puedo decir, Wordpress solo puede actualizarse cuando alguien carga una página web. Pero el proceso de actualización no es instantáneo, por lo que seguramente un usuario que visite el sitio tendrá una carga de página realmente lenta.

¿Hay algún truco diferente que usan para las actualizaciones automáticas? He buscado por todo el lugar pero no he encontrado ninguna explicación.

El sistema que está buscando aquí se llama "WP Cron". Es un sistema de proceso en segundo plano en WordPress que permite que los eventos ocurran fuera del procesamiento normal. Todavía necesitan un disparador para iniciarlos, pero no interfieren con la carga de páginas debido al proceso en segundo plano.

Entonces sí, alguien debe cargar su página. Apagado en el archivo default-filters.php, encontrará esta línea de código:

add_action( 'init', 'wp_cron' );

Entonces, en cada carga de página, se ejecuta la función wp_cron. Esta función ha terminado en wp-includes / cron.php y lo que hace es verificar los eventos programados en la base de datos. Si hay algún proceso que necesite ejecutar en segundo plano, llama a la función spawn_cron.

Spawn cron tiene dos posibles métodos de operación, pero el primero y más común es llamar a la función wp_remote_post para que se conecte de nuevo a sí mismo, en la URL de wp-cron.php. Al hacer esta solicitud HTTP adicional, inicia otro proceso PHP para hacer todo el trabajo real. La solicitud que hace aquí no es de bloqueo, con un tiempo de espera de 0.01 segundos. Entonces, en realidad no obtiene ningún resultado aquí. El propósito de la solicitud es simplemente iniciar un nuevo proceso en segundo plano. Una vez hecho esto, simplemente regresa, por lo que el usuario que lo ve nunca tiene demoras.

El proceso wp-cron.php es lo que hace el trabajo real, la actualización y todo lo demás. El sistema cron maneja muchos procesos en WordPress. La publicación posterior programada, el procesamiento de pings, las comprobaciones de actualización, cualquier cosa que deba ocurrir fuera del flujo normal se puede programar y luego ejecutar según sea necesario.

Pero sí, un golpe normal al sitio debe suceder para iniciar el proceso. Y no, WordPress.org no se pone en contacto con su sitio directamente para comenzar, su sitio tiene que recibir algún tipo de tráfico para iniciarlo. Cualquier forma de tráfico servirá.

En realidad, la actualización automática se empuja desde wp.org. El proceso de actualización aún se ejecuta en su sitio, pero en segundo plano a través de wp-cron.

Cuando se lanza una nueva actualización menor, los chicos de WordPress comienzan a implementar la actualización. El proceso de actualización real se inicia después de que su sitio verificó las wp.orgactualizaciones, una actualización está teóricamente disponible y su sitio se elige al azar para actualizarse.

(Gracias @otto por señalar mi redacción incorrecta :))

Como cada sitio busca wp.orgnuevas versiones (generalmente dos veces al día wp-cron), el servidor de despliegue sabe cuántos sitios necesitan una actualización.

Luego comienza la implementación, comenzando lentamente: 1 de cada 128 sitios se actualiza automáticamente. Esto se está monitoreando, y si el éxito indica que no hay problemas con el lanzamiento, más sitios obtienen la actualización automática (por lo general, el siguiente paso sería 1 de 64 y continuaría aumentando de esa manera) hasta que se entreguen todas las actualizaciones automáticas.

Esto permite a los desarrolladores para detener la ejecución si se produce algún problema, pero la última actualización desde 3.8que 3.8.1ha tenido una tasa de éxito del 100%.

Los sitios seleccionados por el 1 out of 128es realmente aleatorio. Bueno, en realidad no, pero si quieres saber, funciona así:

La URL del sitio que necesita una actualización se utiliza en hash MD5. Usando solo los primeros tres caracteres de este hash y convirtiéndolo a base10, esto da como resultado 4096 posibilidades. La actualización comenzó para sitios que tienen un número calculado entre 0 y 31 (4096/32 = 128).

Bien, supongo que es bastante aleatorio después de todo;)

En mi caso, como ejecuto muchos sitios de WordPress, las actualizaciones tomaron 1 día, fue bastante divertido ver cuándo se actualizaron todas las páginas.

Por si te lo preguntabas: D

Por cierto, aquí hay un artículo en make.wordpress.org que describe el proceso, tal como sucedió.

En términos muy generales, cuando un usuario visita el sitio, WordPress comprueba la caducidad del temporizador y si se detecta una caducidad, se envía otra solicitud al servidor para "ejecutar" las acciones asociadas con el evento caducado. Es por eso que el usuario no siente ningún retraso notable en la carga de la página, ya que el servidor ejecuta la acción real (actualización en este caso) en un proceso separado.

Esto funciona pero el momento no es muy preciso. Cuanto más tráfico tenga su sitio, más preciso será.

Las personas que desean obtener un mejor rendimiento y una sincronización más precisa pueden bloquear el "proceso" cron de WordPress interno y utilizar el proceso cron del sistema operativo para activar la verificación de los temporizadores.