1.1 Le modèle de découverte
La découverte est la phase où WordPress apprend quelles mises à jour existent. Rien ne s’installe tant que WordPress n’a pas écrit les offres dans les transients du site et que l’interface d’administration ou le programme de mise à jour automatique ne les a pas lus.
Fonctionnement
WordPress sépare la découverte de l’application et du retour d’information. Les fonctions wp_version_check(), wp_update_plugins() et wp_update_themes() cherchent les mises à jour ; elles n’installent rien. Leurs résultats vivent dans les transients de site. L’application repose sur la pile de mise à niveau (voir §2.1). Le retour d’information passe par des notifications, des pastilles, des habillages ou un e-mail selon le chemin d’entrée (voir §4.1–§4.2 et la partie 5).
Déroulement
- Un client HTTP contacte WordPress.org ou un autre hôte pour récupérer des métadonnées tierces.
- WordPress décode la réponse en objets d’offre.
- Le cœur fusionne les offres dans les charges utiles des transients.
- Les écrans d’administration et le cron lisent les transients pour décider quoi afficher ou tenter ensuite.
- Si la découverte échoue, les transients restent obsolètes ou vides, et le site n’affiche aucune mise à jour avant qu’une vérification ultérieure n’aboutisse.
Référence
| Concept | Rôle |
|---|---|
| Fonctions de découverte | Remplissent les transients de site update_core, update_plugins et update_themes |
| Application | Sous-classes de WP_Upgrader ; la découverte seule ne les appelle pas |
| Retour d’information | Les transients pilotent l’interface d’administration ; l’e-mail en arrière-plan n’est envoyé qu’après les mises à jour automatiques (voir §4.1) |
Ressources pour les développeurs
- API des extensions : crochets, actions et filtres : comment les crochets s’attachent au comportement du cœur.
1.2 Les transients de site : la couche de données des mises à jour
Les transients de site contiennent les derniers résultats de découverte. Quand vous modifiez le comportement des mises à jour, vous manipulez en général ces structures ou les filtres qui les enveloppent.
Fonctionnement
Le cœur met en cache les résultats de découverte dans des transients de site, partagés à l’échelle du réseau sur un multisite. wp_version_check() définit le transient update_core. Ce transient contient le tableau des offres dans updates, plus last_checked, version_checked et d’éventuelles charges utiles de traduction. Les cartes de sommes de contrôle ne sont pas stockées ici : le cœur les récupère à la demande via get_core_checksums() (voir §1.9).
wp_update_plugins() définit le transient update_plugins avec response, no_update, les versions checked et les listes de traductions. wp_update_themes() définit le transient update_themes selon le même schéma, pour les thèmes.
Les filtres dynamiques tels que pre_set_site_transient_{$transient} s’exécutent avant l’enregistrement. Ce filtre est le point d’intégration principal pour ajuster ou vider des structures avant qu’une mise à jour ne s’exécute.
Déroulement
- Une fonction de vérification s’exécute et construit ou fusionne une charge utile.
- Des filtres peuvent modifier la charge utile avant son enregistrement.
- WordPress enregistre la charge utile sous forme de transient de site.
- Les lecteurs — écran Mises à jour,
wp_get_update_data()etWP_Automatic_Updater— consomment le transient. - Les transients obsolètes persistent jusqu’à la prochaine vérification réussie ou à un rafraîchissement forcé (voir §1.6).
Référence
| Transient | Défini par | Contenu courant |
|---|---|---|
update_core | wp_version_check() | updates (offres), last_checked, version_checked, traductions |
update_plugins | wp_update_plugins() | response, no_update, checked, traductions |
update_themes | wp_update_themes() | Même schéma pour les thèmes |
Ressources pour les développeurs
- Référence de
wp_update_plugins(): vérification des mises à jour d’extensions et enregistrement du transient.
1.3 Options de politique de branche du cœur (auto_update_core_*)
Les options de site déterminent quelles branches du cœur de WordPress peuvent recevoir des mises à jour automatiques quand la constante WP_AUTO_UPDATE_CORE n’est pas définie dans wp-config.php. Elles fonctionnent de pair avec les filtres et avec le filtre auto_update_core propre à chaque offre (voir §3.7).
Fonctionnement
Quand WP_AUTO_UPDATE_CORE n’est pas définie, le cœur lit les options de site dans la logique de politique de branche de Core_Upgrader::should_update_to_version(). Les valeurs sont en général enabled, disabled ou non définies, avec des valeurs par défaut issues du schéma et de l’interface d’administration. Ces options vivent dans la table des options (options de site sur un multisite) : elles ne sont pas stockées dans les transients de mise à jour. Pour l’ordre de priorité avec WP_AUTO_UPDATE_CORE et les filtres, voir §5.10 et §3.7.
Déroulement
- Le cœur évalue la branche de la version en cours : développement, mineure ou majeure.
- Le cœur lit l’option
auto_update_core_*correspondante, sauf si la constante impose la politique. - Les filtres de branche peuvent modifier le résultat booléen.
- Le résultat alimente
should_update()avec l’offre et les autres garde-fous.
Référence
| Nom | Type | Valeur par défaut | Effet |
|---|---|---|---|
auto_update_core_dev | option de site | selon le schéma | Versions de développement ou de type nightly sur la branche en cours |
auto_update_core_minor | option de site | selon le schéma | Versions mineures dans la même branche x.y |
auto_update_core_major | option de site | selon le schéma | Versions majeures ; l’interface de WordPress 5.6 et suivantes associe les choix à cette option |
Ressources pour les développeurs
WP_AUTO_UPDATE_COREdanswp-config.php: constante qui remplace les options de branche lorsqu’elle est définie.
1.4 Les indicateurs d’offre autoupdate et disable_autoupdate
Les réponses de l’API attachent des indicateurs à chaque offre. Ces indicateurs déterminent si un élément est candidat à une mise à jour non assistée, avant l’exécution des filtres par élément.
Fonctionnement
Quand WordPress.org répond à une requête de vérification de mise à jour d’une extension ou d’un thème, chaque entrée de la carte de réponse est un objet d’offre. Les extensions et les thèmes dotés d’un en-tête Update URI peuvent recevoir des offres de update_plugins_{$hostname} ou update_themes_{$hostname} à la place ; ces objets peuvent aussi contenir autoupdate et disable_autoupdate.
Un booléen autoupdate signale que la version est éligible à une mise à jour automatique non assistée, du point de vue de l’annuaire ou du fournisseur tiers. Dans WP_Automatic_Updater::should_update(), pour les extensions et les thèmes, le cœur initialise d’abord la décision en attente à partir de autoupdate, puis fusionne les adhésions par élément stockées dans les options de site (auto_update_plugins, auto_update_themes) quand les mises à jour automatiques sont actives pour ce type. Si autoupdate est vide et que l’administrateur du site n’a pas adhéré pour cet élément, la décision en attente reste fausse.
La propriété disable_autoupdate force la décision en attente à faux avant l’exécution de apply_filters( "auto_update_{$type}", … ), mais le filtre peut encore renvoyer vrai pour réactiver la mise à jour.
Ces indicateurs ne sont pas des réglages durables du site. Ils arrivent à chaque réponse HTTP ou depuis un rappel de filtre. Le transient stocke ce que la dernière vérification a renvoyé. Rafraîchissez les offres avec wp_update_plugins() ou wp_update_themes() avant de fonder une politique sur les objets d’offre.
Déroulement
- La découverte renvoie des offres, chacune portant éventuellement les indicateurs
autoupdateetdisable_autoupdate. should_update()combine ces indicateurs avec les tableaux d’adhésion et les filtres.- Un résultat faux écarte l’installation automatique pour cet élément, sauf si un filtre impose la décision.
Référence
| Indicateur | Signification |
|---|---|
autoupdate | L’annuaire, le fournisseur d’Update URI tiers ou l’auteur signale l’éligibilité à la mise à jour automatique |
disable_autoupdate | Met l’élément en veto avant l’exécution de auto_update_{$type} ; les filtres peuvent passer outre |
Ressources pour les développeurs
- Référence de
WP_Automatic_Updater::should_update(): pile d’éligibilité aux mises à jour automatiques.
1.5 Les vérifications planifiées (WP-Cron)
WordPress planifie des vérifications récurrentes pour que la découverte tourne sans utilisateur connecté. Vous devez connaître le comportement du cron quand DISABLE_WP_CRON ou un ordonnanceur externe remplace le mécanisme par défaut.
Fonctionnement
wp_schedule_update_checks() s’exécute sur init et planifie trois événements biquotidiens : wp_version_check appelle wp_version_check(), wp_update_plugins appelle wp_update_plugins() et wp_update_themes appelle wp_update_themes().
Quand DISABLE_WP_CRON vaut vrai, WordPress ne lance plus le moteur de cron au chargement normal des pages. Les crochets planifiés — dont wp_version_check, wp_update_plugins, wp_update_themes et, par enchaînement, wp_maybe_auto_update — ne s’exécutent pas, sauf si quelque chose appelle wp-cron.php (cron système, supervision ou WP-CLI). Les vérifications déclenchées depuis l’administration décrites en §1.6 continuent de tourner sur ces requêtes, car elles ne passent pas par le cron.
Déroulement
- Le crochet
initplanifie les événements s’ils ne le sont pas déjà. - À chaque passage du cron, les événements dus se déclenchent.
- Chaque gestionnaire appelle la fonction de mise à jour correspondante.
- La limitation interne de ces fonctions peut éviter la requête HTTP si une vérification récente est encore valide, sauf si l’appelant force un rafraîchissement (§1.6).
- En cas d’échec, les transients restent inchangés jusqu’au prochain passage réussi.
Référence
| Crochet | Type | Paramètres | Remarques |
|---|---|---|---|
wp_version_check | événement cron | — | Appelle wp_version_check() |
wp_update_plugins | événement cron | — | Appelle wp_update_plugins() |
wp_update_themes | événement cron | — | Appelle wp_update_themes() |
Ressources pour les développeurs
- Désactiver WP-Cron dans
wp-config.php: comportement quand le cron est désactivé. - Commande WP-CLI
wp cron event run: exécuter les événements dus à la main.
1.6 Vérifications déclenchées depuis l’administration et contournement de la limitation
Charger certains écrans d’administration force des vérifications plus fraîches, avec des délais d’attente plus courts que les longs reports par défaut. Si vous ajoutez un contrôle « Rechercher des mises à jour », reprenez ces schémas.
Fonctionnement
Des crochets sur les écrans d’administration tels que load-plugins.php, load-update.php et load-update-core.php déclenchent des vérifications d’extensions ou de thèmes avec des délais dépendants du contexte. L’écran Mises à jour utilise un report d’environ une minute, les listes environ une heure, et le report par défaut environ 12 heures.
_maybe_update_plugins() et _maybe_update_themes() sur admin_init appliquent un report de 12 heures quand last_checked est récent. _maybe_update_core() n’applique cette même fenêtre de 12 heures que si le champ version_checked du transient correspond encore à la version de WordPress en cours ; si les versions diffèrent, la vérification part immédiatement.
wp_version_check() accepte un second paramètre $force_check. Quand il vaut vrai, la fonction ignore le délai d’attente lié au transient update_core stocké et lance une nouvelle requête HTTP. wp_update_plugins() et wp_update_themes() acceptent $extra_stats ; quand ce tableau n’est pas vide, le retour anticipé pour « vérifié récemment et rien n’a changé » est ignoré, ce qui revient à une vérification forcée. Un premier argument non vide passé à wp_version_check() peut aussi activer $force_check en interne, d’après wp-includes/update.php.
Remarque : ne forcez pas les vérifications à chaque passage du cron ou à chaque requête d’arrière-plan. Réservez les vérifications forcées aux actions lancées par un utilisateur ou aux tâches peu fréquentes, pour éviter les requêtes excessives vers WordPress.org.
Déroulement
- Un écran d’administration se charge et ses crochets de chargement s’exécutent.
- Les fonctions de mise à jour tournent avec des délais courts, ou avec
$force_checket des statistiques supplémentaires non vides. - La requête HTTP renvoie de nouvelles offres.
- WordPress rafraîchit les transients.
- L’interface affiche les nouveaux compteurs de mises à jour.
- Si l’utilisateur n’a pas les capacités suffisantes, WordPress affiche un message limité.
Référence
| Fonction | Fichier | Retour | Remarques |
|---|---|---|---|
wp_version_check() | wp-includes/update.php | void | Passez $force_check à vrai pour ignorer le report lié au transient du cœur |
wp_update_plugins() | wp-includes/update.php | void | Un $extra_stats non vide contourne le chemin « vérifié récemment » |
wp_update_themes() | wp-includes/update.php | void | Un $extra_stats non vide contourne le chemin « vérifié récemment » |
wp_clean_update_cache() | wp-includes/update.php | void | Vide les transients ; à combiner avec une vérification quand vous voulez une nouvelle requête HTTP |
Ressources pour les développeurs
- Référence de
wp_version_check(): API de vérification de version du cœur. - Référence de
wp_clean_update_cache(): vide les transients de mise à jour.
1.7 Les points de terminaison de l’API
La découverte dépend de points de terminaison HTTP qui renvoient des offres au format JSON. La disponibilité de SSL influe sur le transport et sur les avertissements.
Fonctionnement
Le cœur envoie des requêtes POST aux points de terminaison de vérification de version et de mises à jour de WordPress.org. Les URL dans le code source utilisent http:// ; quand wp_http_supports( array( 'ssl' ) ) renvoie vrai, WordPress passe le schéma en HTTPS.
La vérification de version du cœur envoie des paramètres de chaîne de requête plus un corps POST qui contient les traductions encodées. Les vérifications d’extensions et de thèmes envoient des corps JSON listant les composants et les locales installés. Un point de terminaison distinct fournit les sommes de contrôle, pour la seule vérification d’intégrité, sans offres de mise à jour (voir §1.9). Quand SSL n’est pas disponible, le cœur peut retomber en HTTP avec des avertissements visibles sur certains chemins d’échec.
Déroulement
- Une fonction de mise à jour construit le corps de la requête.
- WordPress envoie une requête POST au point de terminaison.
- WordPress décode la réponse.
- En cas d’erreur, les transients peuvent rester obsolètes ou WordPress déclenche un comportement de repli.
- En cas de succès, WordPress met à jour les charges utiles des transients.
Référence
Chemin d’URL sur api.wordpress.org | Méthode | Objet |
|---|---|---|
/core/version-check/1.7/ | POST | Offres du cœur ; arguments de requête plus corps (dont les traductions) |
/plugins/update-check/1.1/ | POST | Offres par extension |
/themes/update-check/1.1/ | POST | Offres par thème |
/core/checksums/1.0/ | GET | Carte chemin-vers-empreinte pour une version et une locale (§1.9) |
Ressources pour les développeurs
- Présentation de l’API HTTP : requêtes sortantes depuis WordPress.
1.8 Les sources de mise à jour tierces (Update URI)
Les extensions et les thèmes peuvent déclarer un en-tête Update URI pour que les métadonnées arrivent d’un autre hôte que WordPress.org. Cela étend la découverte sans remplacer le modèle de transients du cœur.
Fonctionnement
Pour les extensions et les thèmes qui déclarent Update URI, le cœur applique les filtres dynamiques update_plugins_{$hostname} et update_themes_{$hostname}. Ce mécanisme permet aux annuaires commerciaux ou sur mesure de fournir des métadonnées de mise à jour. Les préférences d’interface de mise à jour automatique par entité sont stockées dans les options de site ; elles sont décrites en §5.4 et §3.8.
Déroulement
- La découverte s’exécute.
- Le cœur résout le nom d’hôte à partir de l’en-tête
Update URI. - Le filtre correspondant peut injecter ou modifier des offres.
- WordPress fusionne les résultats dans les transients de site habituels.
- La logique du programme de mise à jour automatique décrite dans la partie 3 utilise ces offres comme les autres.
Référence
| Crochet | Type | Paramètres | Remarques |
|---|---|---|---|
update_plugins_{$hostname} | filtre | variables | Offres d’extensions tierces |
update_themes_{$hostname} | filtre | variables | Offres de thèmes tiers |
Ressources pour les développeurs
- Manuel des thèmes : en-tête
Update URI: rôle de l’en-tête pour les thèmes ; les extensions suivent le même schéma dans le cœur.
1.9 Vérification de l’intégrité du cœur (sommes de contrôle)
La vérification par sommes de contrôle compare les fichiers installés aux empreintes attendues pour une version donnée de WordPress. Elle sert au diagnostic et aux outils en ligne de commande. Elle ne filtre pas le programme de mise à jour automatique avant l’exécution des mises à jour automatiques. La vérification des signatures de paquets sur les fichiers ZIP téléchargés avant l’installation est un mécanisme distinct (§2.12).
Fonctionnement
L’API de sommes de contrôle de WordPress.org renvoie du JSON dont l’entrée checksums associe des chemins de fichiers relatifs à des empreintes attendues, pour une version du cœur et une locale. Le cœur récupère cette carte via get_core_checksums() dans wp-admin/includes/update.php.
Core_Upgrader::check_files() dans wp-admin/includes/class-core-upgrader.php charge les sommes de contrôle et compare la sortie de md5_file() à chaque empreinte attendue, en ignorant les chemins sous wp-content/. Santé du site et les chemins de mise à niveau peuvent utiliser la même API. Le transient de découverte update_core n’embarque pas la carte des sommes de contrôle : le cœur la récupère séparément quand il en a besoin.
La commande WP-CLI wp core verify-checksums effectue un contrôle d’intégrité comparable depuis la ligne de commande. Cette vérification est un audit d’intégrité. Elle ne correspond pas aux contrôles de signature de paquet Ed25519 sur les fichiers ZIP téléchargés (§2.12) et ne sert pas de barrière générale avant vol pour WP_Automatic_Updater.
Déroulement
- Un outil ou une fonction demande les sommes de contrôle pour une version et une locale précises.
- Le cœur compare les fichiers installés à la carte d’empreintes.
- Une différence indique des fichiers du cœur modifiés ou manquants.
- Le résultat informe les administrateurs, mais ne pilote pas à lui seul la chaîne du programme de mise à jour automatique.
Référence
| Fonction | Fichier | Retour | Remarques |
|---|---|---|---|
get_core_checksums() | wp-admin/includes/update.php | array<string, string> ou false | Récupère la carte chemin-vers-empreinte ; renvoie false en cas d’échec |
Core_Upgrader::check_files() | wp-admin/includes/class-core-upgrader.php | bool | Compare les fichiers d’ABSPATH à la carte |
Ressources pour les développeurs
- Référence de
get_core_checksums(): récupération de la carte des sommes de contrôle. - Référence de
Core_Upgrader::check_files(): comparaison des fichiers du cœur. - Commande WP-CLI
wp core verify-checksums: contrôle d’intégrité en ligne de commande.
1.10 Les exclusions : extensions obligatoires et drop-ins
Les extensions obligatoires et les drop-ins vivent en dehors des chaînes habituelles de découverte des extensions et des thèmes. Ils n’apparaissent jamais dans les charges utiles de vérification de mise à jour de WordPress.org et ne sont pas mis à niveau par l’interface de mise à jour standard ni par les chemins du programme de mise à jour automatique destinés aux extensions et thèmes ordinaires.
Fonctionnement
Les extensions obligatoires se chargent depuis wp-content/mu-plugins/ (et les fichiers PHP imbriqués, là où c’est pris en charge). Le cœur ne les énumère pas comme les extensions ordinaires de wp-content/plugins/, donc wp_update_plugins() ne récupère pas d’offres les concernant depuis WordPress.org.
Les drop-ins (par exemple advanced-cache.php, db.php et object-cache.php) sont des fichiers isolés ou de petits ensembles de fichiers placés directement sous wp-content/ et recensés par get_dropins(). Ils ne sont pas empaquetés comme des extensions en dossier ; le cœur n’a pas de flux intégré pour « mettre à jour ce drop-in depuis l’annuaire ».
Remplacer une extension obligatoire ou un drop-in demande un déploiement manuel de fichiers, une chaîne de déploiement sur mesure ou des outils extérieurs aux mécanismes de mise à jour natifs.
Déroulement
- La découverte s’exécute pour les extensions et les thèmes standards.
- Les extensions obligatoires et les drop-ins sont exclus du modèle d’offres.
- Un administrateur ou un outil d’automatisation copie les nouveaux fichiers dans
mu-plugins/ouwp-content/(souvent via un système de gestion de versions ou une chaîne CI/CD). - Le cœur n’enregistre aucune métadonnée de version pour ces composants dans les transients de mise à jour.
- Les extensions obligatoires continuent de se charger tôt au démarrage ; les drop-ins prennent effet quand ils sont présents et valides.
Référence
| Artefact | Découverte | Application |
|---|---|---|
| Extensions obligatoires | Non listées dans le flux standard de l’API de mise à jour des extensions | Déploiement manuel ou externe |
| Drop-ins | Non listés comme paquets installables | Déploiement manuel ou externe |
Ressources pour les développeurs
- Extensions obligatoires : règles de chargement et contraintes.
- Référence de
get_dropins(): noms de fichiers des drop-ins et détection.
