Découvrir updatronix

Mon compte

Points d’entrée et configuration

Catégorie(s) :

Mis à jour le

|

Publié le :

14–21 minutes

|

3 265 mots

5.1 Vue d’ensemble des points d’entrée

Les mises à jour atteignent la même pile de mise à niveau par l’interface d’administration, AJAX (admin-ajax.php), le cron (WP_Automatic_Updater) et WP-CLI. Le cœur n’expose aucune méthode XML-RPC qui exécute la pile de mise à niveau des extensions, des thèmes ou du cœur ; considérez XML-RPC comme hérité pour d’autres usages, et non comme un point d’entrée de mise à jour de premier ordre (§5.7). Le choix du point d’entrée détermine les identifiants, le canal de sortie et le contexte des capacités.

Fonctionnement

L’écran Mises à jour envoie des formulaires vers les actions de mise à niveau. Les listes utilisent des actions de ligne et de groupe avec le script updates. Les actions AJAX appellent les moteurs de mise à niveau avec WP_Ajax_Upgrader_Skin. Le cron invoque WP_Automatic_Updater. WP-CLI charge les inclusions d’administration et appelle directement les primitives. L’API REST embarquée n’offre pas d’opération générique pour « mettre à niveau un paquet installé vers une nouvelle version » (§5.8).

Déroulement

  1. Un utilisateur ou un processus lance une action.
  2. Les capacités et les nonces vérifient la requête.
  3. L’habillage approprié s’attache.
  4. Le moteur de mise à niveau s’exécute.
  5. Le résultat revient par l’habillage, du JSON, le terminal ou l’e-mail, selon le point d’entrée.

Référence

EntréeSortie
Écrans de wp-adminHabillage HTML
AJAXJSON
CronHabillage d’arrière-plan et e-mail
WP-CLITerminal

Ressources pour les développeurs

5.2 L’écran Mises à jour du tableau de bord

wp-admin/update-core.php liste les mises à jour du cœur, des extensions, des thèmes et des traductions, et permet de lancer des opérations groupées.

Fonctionnement

L’écran se charge via admin.php, met en file le script updates et vérifie les capacités (update_core, update_plugins, update_themes et update_languages selon le contexte). Les formulaires envoient des POST vers des actions telles que la mise à niveau du cœur et les mises à jour groupées d’extensions ou de thèmes. Sur un multisite, les administrateurs qui ne gèrent pas le réseau peuvent être redirigés vers l’écran Mises à jour du réseau, selon la logique d’update-core.php.

Déroulement

  1. Un utilisateur ouvre l’écran Mises à jour.
  2. Le cœur rafraîchit les offres ou affiche celles en cache.
  3. L’utilisateur envoie un formulaire.
  4. Le serveur exécute le moteur de mise à niveau.
  5. Une redirection ou un message montre le résultat.

Référence

ÉcranEnsemble de capacités
Mises à jourVariable selon l’action : update_core, update_plugins, update_themes, update_languages

Ressources pour les développeurs

5.3 Le flux de mise à jour en AJAX

Les mises à jour AJAX traitent les extensions et les thèmes sans rechargement complet de la page, via admin-ajax.php et des réponses JSON.

Fonctionnement

Le cœur déclare des actions comme update-plugin et update-theme dans wp-admin/admin-ajax.php. Les gestionnaires vérifient le nonce updates, exigent les capacités, appellent wp_update_plugins() ou wp_update_themes() pour rafraîchir les transients, construisent un Plugin_Upgrader ou un Theme_Upgrader avec WP_Ajax_Upgrader_Skin, puis lancent bulk_upgrade() même pour un seul élément. Le JSON renvoie un succès ou une erreur à l’interface asynchrone. L’action toggle-auto-updates enregistre auto_update_plugins et auto_update_themes sans invoquer le moteur de mise à niveau.

Déroulement

  1. Le navigateur envoie une requête POST au gestionnaire AJAX.
  2. WordPress vérifie le nonce et la capacité.
  3. Le moteur de mise à niveau s’exécute avec l’habillage AJAX.
  4. L’habillage collecte les erreurs et les messages.
  5. Le JSON revient au navigateur.
  6. L’interface de liste met à jour l’état de la ligne.

Référence

ActionEffet
update-pluginMise à niveau d’une extension en AJAX
update-themeMise à niveau d’un thème en AJAX
toggle-auto-updatesBascule uniquement les tableaux d’adhésion ; aucun appel au moteur de mise à niveau

Ressources pour les développeurs

5.4 L’interface de mise à jour automatique par extension et par thème (WordPress 5.5 et suivantes)

Les listes et la fenêtre de détails d’un thème exposent des bascules de mise à jour automatique, stockées dans les options de site.

Fonctionnement

WordPress 5.5 a ajouté une colonne Mises à jour automatiques et des actions groupées sur l’écran Extensions installées ; les préférences persistent dans auto_update_plugins. Les thèmes utilisent auto_update_themes et des contrôles dans la fenêtre de détails, sous Apparence, Thèmes.

plugin_auto_update_setting_html filtre le balisage dans la liste des extensions (class-wp-plugins-list-table.php). Pour les écrans de thèmes d’un site simple, theme_auto_update_setting_template filtre le gabarit de la fenêtre de détails (wp-admin/themes.php). La liste des thèmes du réseau utilise theme_auto_update_setting_html (class-wp-ms-themes-list-table.php).

Qui peut modifier les bascules dépend des capacités et du rôle sur un multisite (administrateur du réseau ou du site). Ne supposez pas que seuls les super administrateurs sont concernés dans toutes les configurations.

Déroulement

  1. Un utilisateur bascule le contrôle.
  2. AJAX ou un formulaire enregistre les options.
  3. L’appel suivant à should_update() lit les tableaux d’adhésion en même temps que les indicateurs des offres.

Référence

CrochetTypeParamètresRemarques
plugin_auto_update_setting_htmlfiltrechaîneListe des extensions installées : colonne et HTML du contrôle
theme_auto_update_setting_templatefiltrechaîneFenêtre de thème d’un site simple : fragment de gabarit
theme_auto_update_setting_htmlfiltrechaîneListe des thèmes du réseau : HTML du contrôle

Ressources pour les développeurs

5.5 L’interface de mise à jour automatique des versions majeures du cœur (WordPress 5.6 et suivantes)

L’écran Mises à jour propose des contrôles pour les mises à jour automatiques majeures du cœur, stockés séparément des options de branche mineure.

Fonctionnement

WordPress 5.6 a ajouté des contrôles sur update-core.php pour accepter ou refuser les mises à jour automatiques majeures du cœur. La préférence est stockée dans l’option de site auto_update_core_major (avec la sémantique enabled, disabled ou unset par défaut), et non dans une option wp_auto_update_core distincte. Voir §1.3, ainsi que update-core.php et Core_Upgrader::should_update_to_version().

Les filtres core_auto_updates_settings_fields et after_core_auto_updates_settings_fields étendent cette section. Quand WP_AUTO_UPDATE_CORE est définie dans wp-config.php, la constante remplace la politique de branche et les options de site auto_update_core_* sont ignorées pour ce chemin de politique.

Déroulement

  1. Un utilisateur définit une préférence sur l’écran Mises à jour.
  2. WordPress enregistre l’option, sauf si la constante la remplace.
  3. Core_Upgrader::should_update_to_version() et should_update() appliquent la politique effective avec les filtres de branche.

Référence

NomTypeValeur par défautEffet
auto_update_core_majoroption de siteunsetContrôle d’interface des mises à jour majeures automatiques du cœur (enabled, disabled ou unset) ; voir §1.3

Ressources pour les développeurs

5.6 WP-CLI

WP-CLI démarre WordPress et appelle les mêmes primitives de mise à niveau que l’administration, après avoir chargé les fichiers nécessaires.

Fonctionnement

Les commandes typiques incluent wp core update, wp core update-db, wp plugin update, wp theme update et les sous-commandes de mise à jour de wp language. WP-CLI n’est pas fourni avec le cœur, mais c’est la surface en ligne de commande prise en charge pour la maintenance scriptée. L’installation forcée d’une version du cœur antérieure à celle présente sur le disque (--version avec --force) et ses conséquences sur le schéma sont traitées en §5.13.

Déroulement

  1. Un opérateur lance une commande.
  2. WP-CLI charge WordPress.
  3. Le moteur ou la routine de mise à niveau s’exécute.
  4. La sortie s’affiche dans le terminal.
  5. Le cœur n’envoie aucun e-mail, sauf si des crochets ajoutent ce comportement.

Référence

DomaineExemples
Cœurwp core update, wp core update-db, wp core verify-checksums
Paquetswp plugin update, wp theme update
Langueswp language core update, wp language plugin update, wp language theme update

Ressources pour les développeurs

5.7 XML-RPC et mots de passe d’application

Les clients distants hérités peuvent déclencher des flux qui chargent du code d’administration et exigent des capacités. XML-RPC n’est pas le chemin d’automatisation principal des nouveaux projets.

Fonctionnement

XML-RPC et les requêtes authentifiées par mot de passe d’application peuvent appeler les procédures distantes prises en charge, là où elles sont activées. Les mises à jour exigent toujours un accès au système de fichiers et des contrôles de privilèges élevés. Préférez WP-CLI ou des points de terminaison sur mesure maîtrisés pour les nouvelles automatisations.

Déroulement

  1. Un client s’authentifie.
  2. WordPress achemine la requête.
  3. Si la procédure exécute des mises à jour, les mêmes contraintes de capacité et de système de fichiers s’appliquent que dans l’interface d’administration.

Référence

MécanismeRemarques
XML-RPCPérimètre hérité ; conditionné par les capacités
Mots de passe d’applicationComplément moderne d’authentification pour REST

Ressources pour les développeurs

5.8 L’API REST : aucun déclencheur de mise à jour natif

Le cœur n’expose aucun point de terminaison REST qui exécute les mises à niveau d’extensions, de thèmes ou du cœur comme une opération générique.

Fonctionnement

Les routes embarquées /wp/v2/plugins et /wp/v2/themes exposent des métadonnées et prennent en charge l’activation et la désactivation (et l’installation depuis l’annuaire par identifiant, pour les extensions). Les gestionnaires update_item (PATCH ou PUT sur une extension ou un thème) ajustent l’état et les champs : ils ne téléchargent ni n’installent une version plus récente d’un paquet déjà installé.

Les mises à jour programmatiques hors navigateur passent en général par WP-CLI, par du code d’administration sur mesure qui charge les classes de mise à niveau avec une authentification correcte, ou par des schémas calqués sur les gestionnaires d’admin-ajax.php.

Déroulement

  1. Un client REST demande des métadonnées ou des changements d’état autorisés par l’API.
  2. La mise à niveau elle-même exige une autre couche d’orchestration.

Référence

RouteMise à niveau d’un paquet installé vers une version plus récente
/wp/v2/pluginsNon pris en charge
/wp/v2/themesNon pris en charge

Ressources pour les développeurs

5.9 Les méthodes du système de fichiers

WP_Filesystem abstrait les accès directs, FTP, FTPS et SSH. Les mises à jour en arrière-plan échouent de façon sûre quand les identifiants ne sont pas disponibles en mode non interactif.

Fonctionnement

Le cœur utilise WP_Filesystem et request_filesystem_credentials(). La constante FS_METHOD, dans wp-config.php, peut forcer direct, ftpext, ftpsockets ou ssh2. Quand le serveur web ne peut pas écrire de fichiers, les flux interactifs affichent le formulaire d’identifiants. Les mises à jour en arrière-plan ne peuvent pas demander d’identifiants : elles échouent s’ils ne sont pas disponibles sans interaction. wp_is_file_mod_allowed( $context ) centralise la question de savoir si les modifications sont autorisées, avec pour valeur par défaut ! DISALLOW_FILE_MODS et le filtre file_mod_allowed.

Déroulement

  1. Le moteur de mise à niveau demande l’accès au système de fichiers.
  2. Une méthode directe ou à identifiants se connecte.
  3. Les écritures se poursuivent ou renvoient une WP_Error.
  4. Le programme de mise à jour automatique abandonne quand les modifications de fichiers sont interdites.

Référence

NomTypeValeur par défautEffet
FS_METHODconstanteautoForce une couche de système de fichiers précise
DISALLOW_FILE_MODSconstantefalse si non définieBloque les modifications de fichiers sauf filtrage

Ressources pour les développeurs

5.10 Les constantes de configuration (wp-config.php)

Les constantes de wp-config.php remplacent les valeurs par défaut du cron, de HTTP, des mises à jour automatiques et du comportement du système de fichiers.

Fonctionnement

AUTOMATIC_UPDATER_DISABLED, quand elle vaut vrai, désactive la chaîne du programme de mise à jour automatique en arrière-plan, e-mails de notification compris. WP_AUTO_UPDATE_CORE, en booléen ou en chaîne, délimite les mises à jour automatiques du cœur (true, false, minor, ou des chaînes de canal de préversion selon le comportement de la version). Avant WordPress 5.6, true impliquait souvent les seules versions mineures ; depuis 5.6, les nouvelles installations partent sur les mises à jour automatiques majeures du cœur, sauf si l’utilisateur change le réglage.

Quand WP_AUTO_UPDATE_CORE n’est pas définie, la politique de branche retombe sur les options auto_update_core_* (§1.3). DISALLOW_FILE_MODS bloque les changements de fichiers, sauf si le filtre file_mod_allowed passe outre. DISABLE_WP_CRON arrête le lancement du cron au chargement des pages ; les vérifications planifiées exigent alors un déclencheur externe de wp-cron.php (§1.5).

WP_HTTP_BLOCK_EXTERNAL et WP_ACCESSIBLE_HOSTS filtrent le HTTP sortant. Bloquer api.wordpress.org ou downloads.wordpress.org casse la découverte, sauf à les mettre en liste d’autorisation. Un accès sortant uniquement via un proxy HTTP d’entreprise exige les constantes WP_PROXY_* (§5.12).

Déroulement

  1. PHP lit les constantes de wp-config.php avant l’exécution.
  2. Les moteurs de mise à jour les consultent dans is_disabled(), should_update_to_version() et les appels du client HTTP.
  3. Une mauvaise configuration se traduit par des mises à jour manquantes ou des exécutions en arrière-plan en échec.

Référence

NomTypeValeur par défautEffet
AUTOMATIC_UPDATER_DISABLEDboolfalse si non définieDésactive le programme de mise à jour automatique et ses e-mails de notification
WP_AUTO_UPDATE_COREbool ou chaînevoir le manuelRemplace les options de branche quand elle est définie
DISALLOW_FILE_MODSboolfalse si non définieInterdit les modifications de fichiers sauf filtrage
FS_METHODchaîneautoForce une couche de système de fichiers précise
DISABLE_WP_CRONboolfalse si non définieArrête le lancement du cron au chargement des pages
WP_HTTP_BLOCK_EXTERNALboolfalseBloque le HTTP sortant sauf liste d’autorisation
WP_ACCESSIBLE_HOSTSchaînevideNoms d’hôte autorisés quand les requêtes externes sont bloquées

Ressources pour les développeurs

5.11 Multisite : périmètre des mises à jour et propagation de la mise à niveau de la base de données

Un multisite partage une base de code et des transients de site au niveau du réseau, tandis que les mises à niveau de la base de données s’appliquent site par site. Après une mise à jour du cœur, les opérateurs doivent lancer les flux de mise à niveau du réseau.

Fonctionnement

Beaucoup d’actions de l’interface de mise à jour sont réservées à l’administration du réseau ou redirigent depuis l’administration d’un site, selon update-core.php. Les capacités dépendent de l’utilisateur et du contexte du site ; les règles des super administrateurs s’appliquent aux opérations réseau. Les transients de mise à jour sont des transients de site, donc le réseau partage un seul cache de mises à jour.

Le remplacement des fichiers du cœur vaut pour tout le réseau. wp_upgrade() exécute upgrade_all() pour les tables du site courant, puis upgrade_network() sur le site principal quand is_multisite() && is_main_site(). Les sous-sites ne se mettent pas tous à niveau en un seul appel.

wp-admin/admin.php peut détecter une incohérence de db_version et déclencher do_mu_upgrade (filtre à vrai par défaut) avec upgrade.php?step=1 sur les grands réseaux, en échantillonnant quand le nombre de sites dépasse 50. Le db_version de chaque site se met à jour quand son wp-admin/upgrade.php s’exécute.

L’écran Administration du réseau, Mise à niveau du réseau (wp-admin/network/upgrade.php), parcourt les sites par lots de cinq, change de blog et envoie des requêtes HTTP GET à l’admin_url( 'upgrade.php?step=upgrade_db' ) de chaque site. La commande WP-CLI wp core update-db --network exécute la mise à niveau de la base de données sur tous les sites, sans interaction.

Après une mise à jour des fichiers du cœur à l’échelle du réseau, chaque sous-site peut encore afficher une mise à niveau de base de données en attente jusqu’à ce que l’écran Mise à niveau du réseau, une mise à niveau site par site ou la commande réseau en ligne de commande se termine.

Déroulement

  1. Les fichiers du cœur se mettent à jour une fois, pour tout le réseau.
  2. Le site principal peut exécuter des routines de mise à niveau partielles.
  3. Les sous-sites se mettent à niveau paresseusement, via l’écran de mise à niveau du réseau ou la ligne de commande.
  4. Tant que le db_version de chaque site ne correspond pas, le schéma peut prendre du retard sur ce site.

Référence

MécanismePérimètre
Base de codeArborescence unique pour tout le réseau
wp_upgrade() par requêteTables du site courant, plus les routines réseau sur le site principal
Écran Mise à niveau du réseauMise à niveau HTTP par site, par lots
wp core update-db --networkMise à niveau en ligne de commande pour tous les sites

Ressources pour les développeurs

5.12 La configuration d’un proxy HTTP d’entreprise

Les hébergements qui ne sortent que par un proxy HTTP ou HTTPS doivent définir les identifiants et les points de terminaison du proxy dans wp-config.php. Sans cela, les requêtes de découverte vers api.wordpress.org et les téléchargements de paquets échouent : aucune offre de mise à jour n’apparaît et aucun paquet ne se télécharge.

Fonctionnement

WordPress lit WP_PROXY_HOST et WP_PROXY_PORT pour router les requêtes HTTP sortantes par le proxy de l’entreprise. Les constantes facultatives WP_PROXY_USERNAME et WP_PROXY_PASSWORD fournissent un accès authentifié au proxy. WP_PROXY_BYPASS_HOSTS liste les hôtes qui ne doivent pas passer par le proxy (séparés par des virgules ; les jokers comme *.wordpress.org sont pris en charge d’après class-wp-http-proxy.php).

Ces constantes sont consommées par l’API HTTP au moment de construire les requêtes (voir wp-includes/class-wp-http-proxy.php). L’interception TLS, des lots d’autorités de certification sur mesure ou des listes d’autorisation au niveau du serveur peuvent encore être nécessaires au-delà des constantes de WordPress. La découverte (wp_version_check(), wp_update_plugins(), wp_update_themes()) et les téléchargements de paquets dépendent de la même pile HTTP : un proxy mal configuré bloque les deux.

Déroulement

  1. PHP charge les constantes de wp-config.php avant les appels HTTP.
  2. WP_HTTP utilise les réglages du proxy pour chaque requête sortante.
  3. Si le proxy refuse la connexion ou renvoie 407 sans identifiants valides, les transients restent obsolètes ou les téléchargements échouent.
  4. Après avoir corrigé les réglages du proxy, un rafraîchissement forcé de la découverte (§1.6) peut être nécessaire pour remplir les offres.

Référence

NomTypeValeur par défautEffet
WP_PROXY_HOSTchaîne—Nom d’hôte ou IP du proxy
WP_PROXY_PORTchaîne—Port du proxy
WP_PROXY_USERNAMEchaîne—Utilisateur de proxy facultatif
WP_PROXY_PASSWORDchaîne—Mot de passe de proxy facultatif
WP_PROXY_BYPASS_HOSTSchaîne—Hôtes séparés par des virgules qui ignorent le proxy

Ressources pour les développeurs

5.13 WP-CLI : les rétrogradations explicites du cœur

WP-CLI peut installer une version précise du cœur de WordPress, y compris une version plus ancienne que celle présente sur le disque, quand vous utilisez --version avec --force. Cela contourne la sémantique habituelle de simple mise à niveau de l’interface d’administration et comporte des risques pour la base de données et la compatibilité.

Fonctionnement

La commande wp core update télécharge et installe le ZIP demandé depuis WordPress.org (sous réserve des contrôles de signature et de système de fichiers propres au contexte de la ligne de commande). Le drapeau --force est obligatoire quand la version cible est inférieure à la version installée, pour que l’opérateur accepte explicitement une rétrogradation.

Rétrograder les fichiers ne rétablit pas automatiquement le schéma de la base de données. Le db_version de la table des options peut rester supérieur à ce qu’attend le code de wp-includes/version.php, ou l’inverse si l’opérateur exécute les étapes dans le désordre. Les opérateurs devraient lancer wp core update-db après les changements de fichiers quand c’est pertinent, et savoir qu’une rétrogradation entre versions majeures peut laisser un schéma ou des données incompatibles. Les sauvegardes automatiques et un environnement de préproduction sont fortement conseillés. La compatibilité des extensions et des thèmes avec l’ancien cœur n’est pas vérifiée par la commande.

Déroulement

  1. L’opérateur lance wp core update --version=X.Y.Z --force.
  2. WP-CLI récupère et décompresse les fichiers du cœur.
  3. Le remplacement des fichiers se termine.
  4. La version de la base de données peut encore refléter la mise à niveau précédente jusqu’à ce que wp core update-db s’exécute ou que wp-admin lance wp_upgrade() pour le chemin de code courant.
  5. Une incohérence entre les fichiers et le schéma peut provoquer des erreurs fatales ou une corruption discrète des données jusqu’à sa résolution.

Référence

PréoccupationRisque de rétrogradation
Version des fichiers face à db_versionSchéma plus récent que le code, ou code plus récent que le schéma
Drapeau --forceObligatoire pour une régression de version ; implique une acceptation explicite
Retour en arrièrePas d’annulation atomique garantie ; restaurer depuis une sauvegarde si nécessaire

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