Comment fonctionnent exactement les mises à jour automatiques?

J'ai reçu un e-mail ce matin indiquant que mon site Wordpress avait été automatiquement mis à jour vers la dernière version. Je connaissais la fonctionnalité, mais je me suis toujours demandé comment cela fonctionne.

PHP n'est pas un processus permanent: il ne s'exécute que sur demande. Pour autant que je sache, Wordpress ne peut se mettre à jour que lorsque quelqu'un charge une page Web. Mais le processus de mise à jour n'est pas instantané, donc un utilisateur visitant le site aurait sûrement un chargement de page très lent.

Y a-t-il une astuce différente qu'ils utilisent pour les mises à jour automatiques? J'ai cherché partout mais je n'ai trouvé aucune explication.

PHP n'est pas un processus permanent: il ne s'exécute que sur demande. Pour autant que je sache, Wordpress ne peut se mettre à jour que lorsque quelqu'un charge une page Web. Mais le processus de mise à jour n'est pas instantané, donc un utilisateur visitant le site aurait sûrement un chargement de page très lent.

Y a-t-il une astuce différente qu'ils utilisent pour les mises à jour automatiques? J'ai cherché partout mais je n'ai trouvé aucune explication.

Le système que vous recherchez ici s'appelle "WP Cron". C'est un système de processus d'arrière-plan dans WordPress qui permet aux événements de se produire en dehors du traitement normal. Ils ont toujours besoin d'un déclencheur pour les lancer, mais ils n'interfèrent pas avec le chargement des pages en raison du processus d'arrière-plan.

Alors oui, quelqu'un doit charger votre page. Dans le fichier default-filters.php, vous trouverez cette ligne de code:

add_action( 'init', 'wp_cron' );

Ainsi, à chaque chargement de page, la fonction wp_cron s'exécute. Cette fonction est terminée dans wp-includes / cron.php et ce qu'elle fait est de vérifier les événements planifiés dans la base de données. S'il y a des processus à exécuter en arrière-plan, il appelle la fonction spawn_cron.

Spawn cron a deux méthodes de fonctionnement possibles, mais la première et la plus courante consiste à appeler la fonction wp_remote_post pour se reconnecter, sur l'URL de wp-cron.php. En faisant cette demande HTTP supplémentaire, il démarre un autre processus PHP pour faire tout le travail réel. La requête qu'il fait ici est non bloquante, avec un timeout de 0,01 seconde. Donc, cela n'obtient aucun résultat ici. Le but de la demande est simplement de démarrer un nouveau processus en arrière-plan. Après cela, il revient simplement, de sorte que l'utilisateur qui regarde n'a jamais de retard.

Le processus wp-cron.php est ce qui fait le travail réel, la mise à jour et tout le reste. De nombreux processus dans WordPress sont gérés par le système cron. La post-publication planifiée, le traitement des pings, les vérifications de mise à jour, tout ce qui doit se produire en dehors du flux normal peut être planifié, puis exécuté selon les besoins.

Mais oui, un coup normal sur le site doit en effet arriver pour lancer le processus. Et non, WordPress.org ne contacte pas votre site directement pour lancer les choses, votre site doit recevoir une certaine forme de trafic pour le démarrer. N'importe quelle forme de trafic fera l'affaire.

En fait, la mise à jour automatique est poussée à partir de wp.org. Le processus de mise à jour s'exécute toujours sur votre site, mais en arrière-plan via wp-cron.

Lorsqu'une nouvelle mise à jour mineure est publiée, les gars de WordPress commencent à déployer la mise à jour. Le processus de mise à jour proprement dit démarre après que votre site a vérifié les wp.orgmises à jour, une mise à jour est théoriquement disponible et votre site est choisi au hasard pour être mis à jour.

(Merci @otto d'avoir signalé ma mauvaise formulation :))

Comme chaque site recherche wp.orgde nouvelles versions (généralement deux fois par jour wp-cron), le serveur de déploiement sait combien de sites ont besoin d'une mise à jour.

Ensuite, le déploiement commence, démarrant lentement - 1 site sur 128 est mis à jour automatiquement. Cela est surveillé et si le taux de réussite n'indique aucun problème avec le déploiement, davantage de sites obtiennent la mise à jour automatique (généralement la prochaine étape serait 1 sur 64 et continuer à augmenter de cette façon) jusqu'à ce que toutes les mises à jour automatiques soient livrées.

Cela permet aux développeurs d'arrêter le déploiement en cas de problème, mais la dernière mise à jour de 3.8à 3.8.1a eu un taux de réussite de 100%.

Les sites sélectionnés par le 1 out of 128sont en fait aléatoires. Eh bien, pas vraiment, mais si vous voulez savoir, cela fonctionne comme ceci:

L'URL du site nécessitant une mise à jour est hachée à l'aide MD5. En utilisant uniquement les trois premiers caractères de ce hachage et en le convertissant base10, cela donne 4096 possibilités. La mise à jour a commencé pour les sites ayant un nombre calculé compris entre 0 et 31 (4096/32 = 128).

D'accord, je suppose que c'est assez aléatoire après tout;)

Dans mon cas, comme je gère beaucoup de sites WordPress, les mises à jour ont pris 1 jour - c'était assez drôle de voir quand toutes les pages ont été mises à jour.

Juste au cas où vous vous demanderiez: D

btw, voici un article sur make.wordpress.org décrivant le processus, tel qu'il s'est produit.

En termes très généraux, lorsqu'un utilisateur visite le site wordpress vérifie l'expiration de la minuterie et si une expiration est détectée, une autre demande est envoyée au serveur pour «exécuter» les actions associées à l'événement expiré. C'est pourquoi l'utilisateur ne ressent aucun retard notable dans le chargement des pages, car le serveur exécute l'action réelle (mise à niveau dans ce cas) dans un processus distinct.

Cela fonctionne mais le timing n'est pas très précis. Plus votre site est fréquenté, plus il sera précis.

Les personnes qui souhaitent obtenir de meilleures performances et un timing plus précis peuvent bloquer le "processus" interne de cron wordpress, et utiliser le processus cron du système d'exploitation pour déclencher la vérification des minuteurs.