Découvrir updatronix

Mon compte

Les mises à jour automatiques en arrière-plan

Catégorie(s) :

Mis à jour le

|

Publié le :

10–14 minutes

|

2 276 mots

3.1 Le modèle du programme de mise à jour automatique

WP_Automatic_Updater applique les mises à jour selon un planning, sans identifiants interactifs. Ses décisions et ses résultats se crochètent séparément de l’usage manuel du moteur de mise à niveau.

Fonctionnement

Pendant le cron, wp_version_check() peut appeler do_action( 'wp_maybe_auto_update' ) quand on n’est pas déjà dans cette action. wp_maybe_auto_update() charge les inclusions d’administration, instancie WP_Automatic_Updater et appelle run(). La classe utilise Automatic_Upgrader_Skin, évalue is_disabled() et le should_update() de chaque élément, sélectionne les paquets dans les transients et lance les moteurs de mise à niveau.

Dans run(), après avoir acquis le verrou auto_updater, le cœur traite les mises à jour dans un ordre fixe : les extensions (depuis update_plugins, après wp_update_plugins()), puis les thèmes (update_themes, après wp_update_themes()), puis le cœur (wp_version_check() plus find_core_auto_update()), puis les paquets de traduction de wp_get_translation_updates().

Le crochet automatic_updates_complete se déclenche à la fin d’un lot uniquement si $update_results n’est pas vide. Si rien ne s’est exécuté ou si rien n’a enregistré de résultat, le crochet ne se déclenche pas. Voir §4.7 pour les e-mails et ce crochet.

Déroulement

  1. Le cron ou un déclencheur externe lance wp-cron.php.
  2. Les vérifications de mise à jour peuvent s’enchaîner vers wp_maybe_auto_update.
  3. run() vérifie is_disabled(). Si le contrôle passe, le programme parcourt la séquence extensions, thèmes, cœur, traductions.
  4. Chaque élément se télécharge et s’installe par la même pile de mise à niveau que les flux manuels, avec un habillage non interactif.
  5. Quand des résultats existent, la fin de lot déclenche les chemins de notification et automatic_updates_complete (partie 4).

Référence

ClasseFichierHérite deRôle
WP_Automatic_Updaterclass-wp-automatic-updater.php—Décisions et exécution en arrière-plan ; ordre de run() : extensions, thèmes, cœur, traductions

Ressources pour les développeurs

3.2 Les conditions de désactivation globale (is_disabled())

Le programme de mise à jour automatique se court-circuite quand le site ne peut pas ou ne doit pas modifier de fichiers, ou quand vous le désactivez explicitement.

Fonctionnement

WP_Automatic_Updater::is_disabled() renvoie vrai quand wp_is_file_mod_allowed( 'automatic_updater' ) est faux (par exemple si DISALLOW_FILE_MODS vaut vrai, sauf filtrage), quand wp_installing() renvoie vrai, ou quand AUTOMATIC_UPDATER_DISABLED vaut vrai ou que le filtre automatic_updater_disabled renvoie vrai. Désactiver le programme de mise à jour automatique supprime aussi ses e-mails de notification dans le comportement actuel du cœur.

Déroulement

  1. run() appelle is_disabled().
  2. Si la méthode renvoie vrai, aucune mise à jour automatique ne s’exécute.
  3. Les points d’entrée qui dépendent des mises à jour en arrière-plan devraient signaler cet état dans leurs diagnostics.

Remarque : should_update() appelle aussi is_disabled() en premier sur chaque élément, si bien qu’une désactivation globale s’applique à l’évaluation des offres dans find_core_auto_update() et ailleurs, et pas seulement au début de run().

Référence

ConditionEffet
wp_is_file_mod_allowed( 'automatic_updater' ) renvoie fauxMises à jour bloquées
wp_installing() renvoie vraiMises à jour bloquées
AUTOMATIC_UPDATER_DISABLED vaut vrai ou automatic_updater_disabled renvoie vraiMises à jour bloquées

Ressources pour les développeurs

3.3 L’éligibilité par élément (should_update())

Chaque élément candidat passe par should_update( $type, $item, $context ), qui fusionne l’état du système de fichiers, la détection de VCS, les indicateurs de l’API, les adhésions, les filtres et les contrôles de compatibilité.

Fonctionnement

should_update() commence par appeler is_disabled() à nouveau. Si le programme de mise à jour automatique est désactivé globalement, la méthode renvoie faux avant toute logique par élément, si bien que find_core_auto_update() et les autres appelants respectent eux aussi la désactivation globale.

Les contrôles restants se combinent : accès non interactif au système de fichiers (l’arrière-plan ne peut pas afficher de formulaire FTP) ; détection d’une copie de travail VCS (voir §3.4) ; règles d’autorisation par type (Core_Upgrader::should_update_to_version() pour le cœur, ou autoupdate plus auto_update_plugins et auto_update_themes pour les extensions et les thèmes, ou autoupdate pour les traductions) ; disable_autoupdate sur l’offre (voir §1.4) ; apply_filters( "auto_update_{$type}", … ) ; puis, pour le cœur, des contrôles PHP et MySQL face à l’offre ; pour les extensions et les thèmes, requires_php s’il est défini.

Pour le cœur, les contrôles de compatibilité PHP et MySQL s’exécutent après disable_autoupdate et auto_update_core, et non au début (voir §3.7).

Déroulement

  1. should_update() appelle is_disabled(). Si le résultat est vrai, la méthode renvoie faux immédiatement.
  2. Le cœur vérifie que le système de fichiers accepte des écritures non interactives.
  3. La détection de copie de travail VCS s’exécute pour le chemin concerné.
  4. Les règles d’autorisation propres au type s’évaluent : politique de branche pour le cœur, ou autoupdate plus tableaux d’adhésion pour les extensions et les thèmes.
  5. La propriété disable_autoupdate peut forcer le résultat à faux.
  6. Le filtre auto_update_{$type} s’exécute.
  7. Pour le cœur : les contrôles de compatibilité PHP et MySQL s’évaluent face à l’offre. Pour les extensions et les thèmes : requires_php s’évalue face au PHP en cours d’exécution.
  8. Un résultat faux à n’importe quelle étape écarte cet élément. Un résultat vrai mène au téléchargement et à l’installation.
  9. L’action pre_auto_update se déclenche une fois par élément avant la tentative (voir §6.5).

Référence

ContrôleRésultat type en cas d’échec
is_disabled()Désactivation globale ; renvoie faux (court-circuit)
Système de fichiersAucune capacité d’écriture silencieuse ; renvoie faux
VCSCopie de travail détectée ; renvoie faux (sauf filtrage)
Autorisation par type (politique de branche, autoupdate ou listes d’adhésion)Renvoie faux
disable_autoupdateForce faux avant auto_update_{$type} ; le filtre peut réactiver
auto_update_{$type}Le filtre renvoie faux ; renvoie faux (le cœur peut encore envoyer un e-mail de notification)
PHP ou MySQL (cœur) ou requires_php (extension ou thème)Environnement d’exécution incompatible ; renvoie faux

Ressources pour les développeurs

3.4 La détection d’une copie de travail VCS

Les mises à jour automatiques ignorent les chemins qui ressemblent à des copies de travail d’un système de gestion de versions, pour ne pas écraser les dispositions des développeurs ou des déploiements.

Fonctionnement

WP_Automatic_Updater::is_vcs_checkout() remonte depuis le chemin du paquet et vérifie toujours, dans ABSPATH, la présence des marqueurs .svn, .git, .hg ou .bzr. Une correspondance désactive les mises à jour automatiques pour cet élément, sans avertissement dans l’administration. Le filtre automatic_updates_is_vcs_checkout reçoit ( bool $checkout, string $context ) et peut renvoyer faux pour passer outre la détection (sur une chaîne CI ou chez un hébergeur infogéré, par exemple).

Un clone Git du cœur ou d’une extension sous wp-content peut bloquer silencieusement les mises à jour automatiques pour ce chemin.

Déroulement

  1. should_update() appelle la détection VCS pour le contexte concerné.
  2. Si la détection renvoie vrai, l’élément est écarté, sauf si le filtre lève l’indicateur.
  3. Les mises à jour manuelles via l’interface d’administration peuvent encore se poursuivre avec les identifiants appropriés.

Référence

CrochetTypeParamètresRemarques
automatic_updates_is_vcs_checkoutfiltre$checkout, $contextPasser outre la détection VCS

Ressources pour les développeurs

3.5 Les garde-fous de compatibilité PHP et MySQL

Les offres peuvent déclarer des versions requises de PHP ou de la base de données. Les mises à jour automatiques refusent les cibles incompatibles avant même de tenter une mise à jour.

Fonctionnement

Pour le cœur, should_update() compare la version de PHP à $item->php_version et celle de MySQL à $wpdb->db_version(), sauf si un drop-in remplace MySQL. Une différence renvoie faux, sans tentative de mise à jour. Pour les extensions et les thèmes, si $item->requires_php est défini et que le PHP en cours est inférieur, le résultat est faux.

Ces contrôles s’exécutent dans should_update(), après les garde-fous du système de fichiers et du VCS, les règles d’autorisation par type, disable_autoupdate et auto_update_{$type} : ils ne constituent pas la première barrière (voir §3.3 et §3.7).

Déroulement

  1. Les garde-fous précédents peuvent déjà renvoyer faux.
  2. Si l’élément est encore éligible, should_update() applique les contrôles PHP et MySQL (cœur) ou requires_php (extensions et thèmes).
  3. Un environnement d’exécution incompatible renvoie faux avant que update() ne s’exécute.

Référence

TypeGarde-fou
CœurComparaison des versions de PHP et de MySQL avec l’offre
Extension ou thèmeComparaison de requires_php avec l’environnement d’exécution

Ressources pour les développeurs

3.6 find_core_auto_update() : la sélection de l’offre du cœur

Une seule offre automatique du cœur s’exécute par lot. find_core_auto_update() la choisit dans le transient update_core.

Fonctionnement

La fonction lit le transient de site update_core, parcourt le tableau updates et écarte toute offre dont le response n’est pas autoupdate. Pour chaque offre restante, elle appelle should_update( 'core', $update, ABSPATH ). Elle retient ensuite la version la plus élevée parmi celles qui passent, en comparant les versions sur la propriété current, ou renvoie faux si aucune ne convient.

Une mise à jour automatique du cœur ne s’exécute jamais si l’offre n’existe pas avec response === 'autoupdate' et si should_update() ne passe pas. Les entrées réservées à l’interface manuelle ne passent pas par ce sélecteur.

Déroulement

  1. Le cœur charge le transient update_core.
  2. Les offres dont le response n’est pas autoupdate sont écartées.
  3. Chaque candidat passe par should_update().
  4. La version la plus élevée qui passe l’emporte.
  5. Si aucune ne convient, la fonction renvoie faux et aucune mise à jour automatique du cœur ne s’exécute pour ce lot.

Référence

FonctionFichierRetourRemarques
find_core_auto_update()wp-admin/includes/update.phpobjet ou falseSélectionne l’offre automatique du cœur

Ressources pour les développeurs

3.7 La politique de branche du cœur et l’ordre de résolution

Les mises à jour automatiques du cœur combinent la politique définie par les constantes, les options de site, les filtres de branche, les vetos portés par les offres et le filtre auto_update_core propre à chaque offre. L’ordre ci-dessous est la chaîne de résolution que vous devez avoir en tête.

Fonctionnement

find_core_auto_update() ne considère que les offres dont le response vaut autoupdate, puis appelle should_update( 'core', $update, ABSPATH ) pour chaque candidat.

Core_Upgrader::should_update_to_version() applique la constante WP_AUTO_UPDATE_CORE quand elle est définie, sinon les options de site auto_update_core_dev, auto_update_core_minor et auto_update_core_major. Elle évalue aussi l’historique des échecs, la logique de branche et, selon la branche, les filtres allow_dev_auto_core_updates, allow_minor_auto_core_updates et allow_major_auto_core_updates. Chaque filtre reçoit le booléen issu des constantes et des options.

La propriété disable_autoupdate de l’offre peut forcer la décision en attente à faux ; les filtres peuvent encore réactiver l’élément. Ensuite, apply_filters( 'auto_update_core', $update, $item ) s’exécute. Les contrôles de compatibilité PHP et MySQL sur l’offre viennent après.

Remarque : apply_filters( 'wp_auto_update_core', … ) n’est pas appelé par Core_Upgrader dans le cœur, dans les versions inspectées. Ne confondez pas ce nom de filtre avec l’option de site ou la gestion de la constante. La politique qui décide quelles classes de mise à jour du cœur sont autorisées vit dans should_update_to_version(). Le crochet dynamique auto_update_core est la barrière par offre, dans should_update(), après le calcul de l’autorisation ou du refus initial pour cette offre.

Déroulement

  1. Seules les offres dont le response vaut autoupdate sont prises en compte.
  2. Core_Upgrader::should_update_to_version() évalue la constante, les options auto_update_core_*, l’historique des échecs, la logique de branche et les filtres allow_*_auto_core_updates : le résultat est un booléen.
  3. disable_autoupdate sur l’offre peut forcer faux ; les filtres peuvent réactiver.
  4. apply_filters( 'auto_update_core', $update, $item ) s’exécute.
  5. Les contrôles de compatibilité PHP et MySQL sur l’offre viennent ensuite.

Référence

CrochetTypeParamètresRemarques
allow_dev_auto_core_updatesfiltreboolInstallations de versions de développement
allow_minor_auto_core_updatesfiltreboolMême branche x.y
allow_major_auto_core_updatesfiltreboolPassage de x.y à x.y+1
auto_update_corefiltrebool, objetAprès la décision initiale du cœur pour l’offre

Ressources pour les développeurs

3.8 Les préférences de mise à jour automatique par extension et par thème

Les options de site listent les extensions et les thèmes qui ont adhéré aux mises à jour automatiques. Ces options se combinent avec les indicateurs autoupdate portés par les offres.

Fonctionnement

auto_update_plugins stocke un tableau de noms de base d’extensions. auto_update_themes stocke les identifiants des thèmes ayant adhéré. L’action AJAX toggle-auto-updates enregistre ces options sans lancer le moteur de mise à niveau. should_update() les combine avec l’indicateur autoupdate de l’offre quand les mises à jour automatiques sont actives pour ce type.

Sur un multisite, qui peut modifier ces bascules est restreint (voir §5.11 et §5.4).

Déroulement

  1. Un utilisateur bascule le contrôle de l’interface, ou un changement de politique réseau met les options à jour.
  2. L’appel suivant à should_update() lit les tableaux d’adhésion.
  3. Une offre sans autoupdate exige quand même une adhésion pour cet élément, sauf si un filtre change le résultat.

Référence

NomTypeValeur par défautEffet
auto_update_pluginsoption de site (tableau)videNoms de base des extensions ayant adhéré aux mises à jour automatiques
auto_update_themesoption de site (tableau)videIdentifiants des thèmes ayant adhéré aux mises à jour automatiques

Ressources pour les développeurs

3.9 Les mises à jour automatiques des traductions et l’enchaînement asynchrone

Les traductions se mettent à jour automatiquement avec leurs propres filtres et peuvent s’installer lors d’une passe enchaînée après la fin d’une autre mise à niveau.

Fonctionnement

Deux filtres s’appliquent dans des contextes différents.

async_update_translation s’exécute dans Language_Pack_Upgrader::async_upgrade(), uniquement après une mise à niveau réussie du cœur, d’une extension ou d’un thème dans la même requête. Il décide s’il faut installer en bloc les paquets de traduction lors de la passe de suivi ; la décision en attente suit par défaut l’autoupdate de chaque offre de langue. Avant d’installer, async_upgrade() s’arrête sans rien faire si WP_Automatic_Updater::is_vcs_checkout( WP_CONTENT_DIR ) détecte une copie de travail VCS sous wp-content, ce qui reproduit le comportement prudent de ce chemin de code.

auto_update_translation participe à should_update() pour les mises à jour automatiques de traductions déclenchées par le cron, comme les autres crochets auto_update_{$type}.

Modifier un filtre ne modifie pas automatiquement l’autre.

Déroulement

  1. Une mise à niveau principale se termine.
  2. L’action upgrader_process_complete se déclenche.
  3. À la priorité 20, la mise à niveau asynchrone des traductions peut s’exécuter (sauf si la détection VCS la court-circuite).
  4. Séparément, les mises à jour automatiques déclenchées par le cron évaluent les éléments de traduction via should_update(), y compris le filtre auto_update_translation.

Référence

CrochetTypeParamètresRemarques
async_update_translationfiltreboolEnchaînement après mise à niveau, dans la même requête
auto_update_translationfiltreboolshould_update() en arrière-plan pour les traductions

Ressources pour les développeurs

Auteur

Photo de Quentin Le Duff

Quentin Le Duff

Quentin Le Duff est développeur WordPress depuis dix ans, certifié Opquast® Expert & ISTQB. Il travaille avec WordPress au quotidien : développement d’extensions open source et de thèmes, hébergement et maintenance des sites de ses clients, et rédaction sur l’écosystème WP.

À propos
Contact