Come funzionano esattamente gli aggiornamenti automatici?

Questa mattina ho ricevuto un'e-mail in cui si afferma che il mio sito Wordpress è stato aggiornato automaticamente all'ultima versione. Conoscevo la funzionalità ma mi sono sempre chiesto esattamente come funziona.

PHP non è un processo in esecuzione permanente: viene eseguito solo su richiesta. Per quanto ne so, Wordpress può aggiornarsi solo quando qualcuno carica una pagina web. Ma il processo di aggiornamento non è istantaneo, quindi sicuramente un utente che visita il sito avrebbe un caricamento della pagina molto lento.

C'è un trucco diverso che usano per gli aggiornamenti automatici? Ho cercato dappertutto ma non ho trovato alcuna spiegazione.

PHP non è un processo in esecuzione permanente: viene eseguito solo su richiesta. Per quanto ne so, Wordpress può aggiornarsi solo quando qualcuno carica una pagina web. Ma il processo di aggiornamento non è istantaneo, quindi sicuramente un utente che visita il sito avrebbe un caricamento della pagina molto lento.

C'è un trucco diverso che usano per gli aggiornamenti automatici? Ho cercato dappertutto ma non ho trovato alcuna spiegazione.

Il sistema che stai cercando qui si chiama "WP Cron". È un sistema di processo in background in WordPress che consente agli eventi di verificarsi al di fuori della normale elaborazione. Hanno ancora bisogno di un trigger per iniziare, ma non interferiscono con il caricamento della pagina a causa del processo in background.

Quindi sì, qualcuno deve caricare la tua pagina. Off nel file default-filters.php, troverai questa riga di codice:

add_action( 'init', 'wp_cron' );

Quindi, ad ogni caricamento della pagina, viene eseguita la funzione wp_cron. Questa funzione è finita in wp-Includes / cron.php e ciò che fa è controllare gli eventi programmati nel database. Se sono presenti processi da eseguire in background, chiama la funzione spawn_cron.

Spawn cron ha due possibili metodi operativi, ma il primo e più comune è chiamare la funzione wp_remote_post per stabilire una connessione a se stessa, sull'URL di wp-cron.php. Effettuando questa richiesta HTTP aggiuntiva, avvia un altro processo PHP per eseguire tutto il lavoro effettivo. La richiesta che effettua qui non è bloccante, con un timeout di 0,01 secondi. Quindi, in realtà non ottiene alcun risultato qui. Lo scopo della richiesta è semplicemente quello di avviare un nuovo processo in background. Fatto ciò, ritorna semplicemente, quindi l'utente che visualizza non ha mai alcun ritardo.

Il processo wp-cron.php è ciò che funziona effettivamente, l'aggiornamento e tutto il resto. Molti processi in WordPress sono gestiti dal sistema cron. Pubblicazione post programmata, elaborazione di ping, controlli di aggiornamento, tutto ciò che deve accadere al di fuori del normale flusso può essere programmato e quindi eseguito secondo necessità.

Ma sì, un colpo normale al sito deve effettivamente capitare di dare il via al processo. E no, WordPress.org non contatta direttamente il tuo sito per dare il via alle cose, il tuo sito deve ricevere una qualche forma di traffico per avviarlo. Qualsiasi forma di traffico farà.

In realtà, viene aggiornato l'aggiornamento automatico wp.org. Il processo di aggiornamento viene ancora eseguito sul tuo sito, ma in background tramite wp-cron.

Quando viene rilasciato un nuovo aggiornamento minore, i ragazzi di WordPress iniziano a distribuire l'aggiornamento. Il processo di aggiornamento effettivo viene avviato dopo che il sito ha verificato la presenza wp.orgdi aggiornamenti, un aggiornamento è teoricamente disponibile e il sito è scelto a caso per essere aggiornato.

(Grazie @otto per aver sottolineato la mia formulazione sbagliata :))

Poiché ogni sito verifica la presenza wp.orgdi nuove versioni (di solito due volte al giorno wp-cron), il rolloutserver sa quanti siti necessitano di un aggiornamento.

Quindi il lancio inizia, iniziando lentamente: 1 su 128 siti viene aggiornato automaticamente. Questo viene monitorato e se la percentuale di successi non indica problemi con l'implementazione, molti siti ottengono l'aggiornamento automatico (di solito il passaggio successivo sarà 1 su 64 e continuerà ad aumentare in quel modo) fino a quando non vengono consegnati tutti gli aggiornamenti automatici.

Ciò consente agli sviluppatori di interrompere l'implementazione in caso di problemi, ma l'ultimo aggiornamento da 3.8a 3.8.1ha avuto un tasso di successo del 100%.

I siti selezionati da 1 out of 128sono in realtà casuali. Bene, non proprio, ma se vuoi sapere, funziona così:

L'URL del sito che necessita di un aggiornamento viene sottoposto a hash usando MD5. Utilizzando solo i primi tre caratteri di questo hash e convertendolo in base10, si ottengono 4096 possibilità. L'aggiornamento è iniziato per i siti con un numero calcolato compreso tra 0 e 31 (4096/32 = 128).

Okay, suppongo sia abbastanza casuale dopo tutto;)

Nel mio caso, poiché gestisco molti siti WordPress, gli aggiornamenti hanno richiesto 1 giorno - è stato abbastanza divertente vedere quando tutte le pagine sono state aggiornate.

Nel caso ti stavi chiedendo: D

a proposito, ecco un articolo su make.wordpress.org che descrive il processo, come è successo.

In termini molto generali, quando un utente visita il sito wordpress controlla la scadenza del timer e se viene rilevata una scadenza, un'altra richiesta viene inviata al server per "eseguire" le azioni associate all'evento scaduto. Questo è il motivo per cui l'utente non avverte alcun notevole ritardo nel caricamento della pagina, poiché il server sta eseguendo l'azione effettiva (in questo caso l'aggiornamento) in un processo separato.

Funziona ma i tempi non sono molto precisi. Più traffico ha il tuo sito, più preciso sarà.

Le persone che desiderano ottenere prestazioni migliori e un tempismo più accurato possono bloccare il "processo" cron interno di wordpress e utilizzare il processo cron OS per attivare il controllo dei timer.