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

  

PHP no es un proceso en 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ía una carga de página realmente lenta.

     

¿Hay algún truco diferente que usen para las actualizaciones automáticas? He   Buscó 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 desencadenante para lanzarlos, pero no interfieren con las cargas de la página debido al proceso en segundo plano.

Así que sí, alguien debe cargar tu página. Desactivado en el archivo default-filters.php, encontrará esta línea de código:

add_action( 'init', 'wp_cron' );

Por lo tanto, en cada carga de página, se ejecuta la función wp_cron. Esta función termina 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, entonces llama a la función spawn_cron.

Spawn cron tiene dos métodos de operación posibles, pero el primero y el más común es llamar a la función wp_remote_post para hacer una conexión de nuevo a sí misma, en la URL de wp-cron.php. Al realizar esta solicitud HTTP adicional, inicia otro proceso de PHP para realizar todo el trabajo real. La solicitud que realiza aquí es sin bloqueo, con un tiempo de espera de 0,01 segundos. Por lo tanto, en realidad no hay ningún resultado aquí. El propósito de la solicitud es simplemente iniciar un nuevo proceso en segundo plano. Una vez hecho esto, simplemente vuelve, por lo que el usuario que lo ve nunca tiene ningún retraso.

El proceso wp-cron.php es lo que hace el trabajo real, la actualización y todo lo demás. Muchos procesos en WordPress son manejados por el sistema cron. La publicación posterior programada, el procesamiento de pings, las comprobaciones de actualización, cualquier cosa que deba suceder fuera del flujo normal puede programarse y luego ejecutarse según sea necesario.

Pero sí, un golpe normal al sitio debe suceder para iniciar el proceso. Y no, WordPress.org no se comunica directamente con su sitio 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 verifique wp.org en busca de actualizaciones, en teoría hay una actualización disponible y su sitio es elegido al azar para ser actualizado.

  

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

A medida que todos los sitios verifican con wp.org para las nuevas versiones (generalmente dos veces al día con wp-cron ), el rolloutserver sabe cuántos sitios necesitan una actualización.

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

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

Los sitios seleccionados por 1 out of 128 son en realidad aleatorios. Bueno, no realmente, pero si quieres saberlo, funciona así:

La URL del sitio que necesita una actualización se oculta utilizando 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 los 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 tardaron 1 día, fue bastante divertido ver cuándo se actualizaron todas las páginas.

En caso de que te lo preguntes: D

btw, aquí es 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. . Por esta razón, el usuario no siente ningún retraso notable en la carga de la página, ya que el servidor está ejecutando la acción real (actualización en este caso) en un proceso separado.

Esto funciona pero el tiempo 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" interno de "wordpress" del cron y usar el proceso cron del sistema operativo para activar la verificación de los temporizadores.