4.1 Le modèle de notification
WordPress sépare le retour d’information affiché dans l’administration de l’e-mail. Les mises à jour manuelles passent par les habillages ou AJAX ; les mises à jour en arrière-plan peuvent envoyer un e-mail à l’administrateur du site.
Fonctionnement
Les utilisateurs connectés voient des notifications, des pastilles de menu et l’écran Mises à jour, alimentés par les transients et les capacités. WP_Automatic_Updater envoie les e-mails des résultats d’arrière-plan par des méthodes dédiées. La sortie manuelle de WP-CLI reste dans le terminal, sauf si des crochets ajoutent du comportement. Désactiver le programme de mise à jour automatique supprime aussi ses e-mails de notification, d’après la documentation du cœur.
Déroulement
- La découverte met les transients à jour.
- L’interface d’administration lit les transients et affiche les informations de mise à jour.
- Si des mises à jour en arrière-plan s’exécutent, un e-mail peut partir à la fin.
- L’action
automatic_updates_completene s’exécute que siWP_Automatic_Updater::run()enregistre au moins un résultat dans son tableau interne$update_results. Si le lot ne produit aucune tentative suivie, le crochet ne se déclenche pas (§4.7).
Référence
| Chemin | Canal |
|---|---|
| Administration manuelle | Habillage ou JSON AJAX |
| Arrière-plan | E-mail et crochets facultatifs |
| WP-CLI | Sortie standard |
Ressources pour les développeurs
- Référence de l’action
automatic_updates_complete: se déclenche après un lot d’arrière-plan dont les résultats ne sont pas vides.
4.2 Les notifications et les pastilles de menu dans l’administration
Les messages affichés dans l’administration reposent sur des crochets et des assistants, sans wp_mail(), pour signaler les mises à jour disponibles.
Fonctionnement
update_nag(), dans wp-admin/includes/update.php, s’attache à admin_notices et network_admin_notices à la priorité 3. Elle affiche une notification d’administration de type avertissement (via wp_admin_notice(), de type warning, avec des classes telles que update-nag) quand une mise à niveau du cœur est disponible dans get_preferred_from_update_core() avec response === 'upgrade'. Elle ne s’affiche pas sur update-core.php. Les utilisateurs sans la capacité update_core peuvent voir un texte les invitant à prévenir l’administrateur du site.
La bulle de comptage du menu d’administration utilise wp_get_update_data() depuis wp-admin/menu.php. Le widget « En un coup d’œil » utilise update_right_now_message() pour afficher un bouton de mise à jour quand c’est pertinent.
Déroulement
- La page d’administration s’affiche.
- Les transients fournissent les compteurs de mises à jour.
- Les capacités déterminent quels messages apparaissent.
- Aucun e-mail ne part par ces mécanismes seuls.
Référence
| Mécanisme | Objet |
|---|---|
update_nag() | Notification de mise à niveau du cœur |
| Bulle de menu | Compteurs de mises à jour agrégés |
| Widget « En un coup d’œil » | Bouton d’action rapide quand l’utilisateur a les capacités |
Ressources pour les développeurs
- Référence de
wp_get_update_data(): compteurs de mises à jour pour le menu.
4.3 Santé du site : les tests de diagnostic liés aux mises à jour
Santé du site met en avant les risques de configuration. Elle ne bloque pas les mises à jour.
Fonctionnement
WP_Site_Health exécute des tests de diagnostic. Les tests de mise à jour en arrière-plan reflètent des facteurs proches de WP_Automatic_Updater::is_disabled() : constantes, filtres, détection VCS et indicateurs associés. Les tests de boucle locale vérifient que le serveur arrive à s’adresser une requête HTTP à lui-même (utile pour les éditeurs de fichiers et pour la détection des erreurs fatales de WordPress 6.6 et suivantes). WordPress 6.3 et suivantes ajoutent des contrôles sur l’écriture dans le dossier de sauvegarde et sur l’espace disque, liés aux sauvegardes temporaires du retour en arrière manuel. Les résultats sont purement informatifs : vérifiez le comportement dans le code du programme de mise à jour lors d’un diagnostic.
Déroulement
- La page Santé du site lance les tests.
- Chaque test renvoie un statut et des messages.
- Les administrateurs utilisent les résultats pour corriger les problèmes d’environnement.
Référence
| Sujet | Pertinence |
|---|---|
| Mises à jour en arrière-plan | Reflète les conditions de désactivation |
| Boucle locale | Fonctions asynchrones et retour en arrière |
| Dossier de sauvegarde et espace disque | Espace pour le retour en arrière manuel |
Ressources pour les développeurs
- Référence de la classe
WP_Site_Health: classe de Santé du site.
4.4 Les e-mails de mise à jour du cœur en arrière-plan
Les mises à jour automatiques du cœur envoient un e-mail à l’administrateur du site en cas de succès, d’échec, d’échec critique et, parfois, d’invitation à lancer la mise à jour à la main quand l’application automatique a été écartée.
Fonctionnement
WP_Automatic_Updater implémente des chemins comme after_core_update() et send_core_update_notification_email(). Les types incluent success, fail, critical et la notification manual (quand elle est conditionnée par l’indicateur notify_email de l’API et par des filtres). Les options de site auto_core_update_notified et auto_core_update_failed évitent les doublons ou programment des nouvelles tentatives.
Le filtre send_core_update_notification_email décide s’il faut envoyer le message « nouvelle version du cœur disponible » (l’invitation à la mise à jour manuelle). Le filtre auto_core_update_send_email ne s’applique qu’aux types success, fail et critical : il ne s’exécute pas pour les e-mails manual, car send_email() saute cette barrière quand $type === 'manual'. Le filtre auto_core_update_email modifie le message composé pour les envois qui passent par send_email().
Le destinataire est en général get_site_option( 'admin_email' ), avec un possible changement de locale.
Déroulement
- Une mise à jour du cœur en arrière-plan se termine ou échoue.
- Le cœur choisit le type d’e-mail.
- Les filtres concernés s’exécutent.
wp_mail()envoie l’e-mail, sauf si un filtre le désactive.- Les options de suivi empêchent les e-mails en double pour une même version.
Référence
| Crochet | Type | Paramètres | Remarques |
|---|---|---|---|
send_core_update_notification_email | filtre | bool | Faut-il envoyer l’e-mail de mise à jour manuelle disponible (chemin notify_email) |
auto_core_update_send_email | filtre | bool, chaîne | Barre les e-mails d’arrière-plan success, fail et critical — pas manual |
auto_core_update_email | filtre | tableau | Modifie destinataire, objet, corps et en-têtes pour send_email() |
Ressources pour les développeurs
- Référence du filtre
auto_core_update_email: filtre de la charge utile des e-mails.
4.5 Les e-mails de mise à jour des extensions et des thèmes en arrière-plan
Les lots automatiques d’extensions et de thèmes peuvent envoyer des récapitulatifs en cas de succès, d’échec ou de résultats mitigés.
Fonctionnement
Après les mises à jour automatiques d’extensions ou de thèmes, after_plugin_theme_update() peut appeler send_plugin_theme_email() avec les types success, fail ou mixed.
auto_plugin_update_send_email et auto_theme_update_send_email reçoivent ( $enabled, $slice ), où $slice vaut $update_results['plugin'] ou $update_results['theme'] (les tableaux d’objets de résultat pour ce type), et non l’arborescence complète $update_results. auto_plugin_theme_update_email ajuste la charge utile finale de l’e-mail.
La valeur auto_plugin_theme_update_emails est stockée avec get_option() et update_option() (l’API d’options par site), et non avec get_site_option(), lorsqu’il s’agit de suivre les versions en échec pour limiter les messages répétés. Les messages de WordPress 6.6 et suivantes peuvent inclure les résultats d’un retour en arrière après une erreur fatale détectée par boucle locale.
Déroulement
- Un lot se termine.
- Le cœur décide s’il faut envoyer un e-mail.
- Des filtres ajustent ou suppriment l’e-mail.
- WordPress envoie le message à l’adresse e-mail de l’administration, sauf si un filtre l’en empêche.
Référence
| Crochet | Type | Paramètres | Remarques |
|---|---|---|---|
auto_plugin_update_send_email | filtre | bool, tableau | Barrière des e-mails de lot d’extensions ; le second argument est la liste des résultats d’extensions uniquement |
auto_theme_update_send_email | filtre | bool, tableau | Barrière des e-mails de lot de thèmes ; le second argument est la liste des résultats de thèmes uniquement |
auto_plugin_theme_update_email | filtre | tableau | Destinataire, objet, corps et en-têtes finaux |
Ressources pour les développeurs
- Référence du filtre
auto_plugin_theme_update_email: filtre combiné des e-mails d’extensions et de thèmes.
4.6 Les e-mails de débogage (versions de développement)
Les versions de développement de WordPress peuvent envoyer un e-mail de journal de débogage après les mises à jour en arrière-plan, quand l’option est active.
Fonctionnement
Si le site exécute une version de développement (une chaîne de version contenant un tiret, comme un suffixe de version candidate) et que des résultats de mise à jour en arrière-plan existent, le cœur peut envoyer un e-mail de débogage. Le filtre automatic_updates_send_debug_email vaut vrai par défaut uniquement sur les versions de développement. Le filtre automatic_updates_debug_email ajuste la charge utile de cet e-mail.
Déroulement
- Un lot d’arrière-plan se termine sur une version de développement.
- Le chemin de l’e-mail de débogage évalue les filtres.
- Un e-mail facultatif part avec un contenu de diagnostic.
Référence
| Crochet | Type | Paramètres | Remarques |
|---|---|---|---|
automatic_updates_send_debug_email | filtre | bool | Active l’e-mail de débogage |
automatic_updates_debug_email | filtre | tableau | Ajuste la charge utile de l’e-mail |
Ressources pour les développeurs
- Référence du filtre
automatic_updates_debug_email: contenu de l’e-mail de débogage.
4.7 automatic_updates_complete : la charge utile des résultats
L’action automatic_updates_complete transmet un tableau structuré de résultats, pour la journalisation et les notifications externes. Quand vous exploitez ce crochet, examinez avec soin les types, les objets de résultat et les codes d’erreur.
Fonctionnement
do_action( 'automatic_updates_complete', $update_results ) se déclenche à la fin de WP_Automatic_Updater::run() quand des résultats existent. Le tableau correspond à la propriété interne update_results. Les clés de premier niveau sont les chaînes de type de mise à jour : core, plugin, theme et translation. Une clé n’existe que si le lot a tenté au moins une mise à jour de ce type. Chaque valeur est un tableau indexé numériquement d’objets de résultat.
Quand messages et result se contredisent en cas d’échec : quand une tentative échoue avec une WP_Error dans result (exemple courant : le code fs_unavailable quand WP_Filesystem ne peut pas s’initialiser), messages peut encore contenir une sortie d’habillage antérieure ou générique — parfois un message proche du succès (comme « le site dispose déjà de la dernière version ») qui ne reflète pas l’échec réel. Si vous construisez des diagnostics destinés à l’exploitation, inspectez result avec is_wp_error() et faites remonter le code et le message d’erreur, pas seulement un implode() de messages. Le texte de l’e-mail de débogage des mises à jour automatiques s’appuie sur les résultats structurés et sur WP_Error ; pour obtenir la même chose que ce journal, il faut fusionner les deux sources.
Signaux de retour en arrière : le cœur peut placer une WP_Error de code rollback_was_required dans result quand Core_Upgrader revient en arrière après un échec. Les mises à jour automatiques d’extensions sous WordPress 6.6 et suivantes peuvent utiliser des codes comme plugin_update_fatal_error_rollback_successful ou plugin_update_fatal_error_rollback_failed sur cette même propriété result, avec item qui identifie l’extension.
Déroulement
- L’exécution du lot se termine.
- Le cœur remplit un objet de résultat par tentative.
automatic_updates_completese déclenche uniquement si$update_resultsn’est pas vide à la fin derun(). Sinon, les écouteurs ne s’exécutent jamais.- Votre extension peut gérer la journalisation ou des intégrations sortantes depuis ce crochet.
Référence
Structure de premier niveau :
| Forme | Détail |
|---|---|
| Clés de premier niveau | 'core', 'plugin', 'theme', 'translation' — présentes seulement si une tentative a eu lieu |
| Chaque valeur | Tableau numérique d’objets de résultat |
Chaque objet de résultat :
| Propriété | Type | Description |
|---|---|---|
item | objet | Offre de mise à jour issue du transient concerné |
result | true, WP_Error ou autre valeur falsy | Le succès est en général le booléen true ; les échecs sont le plus souvent une WP_Error ; d’autres valeurs falsy peuvent signaler un échec sans WP_Error dans des cas limites |
name | chaîne | Libellé lisible |
messages | tableau | Chaînes issues du tampon de messages d’Automatic_Upgrader_Skin |
Champs item courants selon le type :
| Type | Identifiants | Version ou paquet | Autres (liste non exhaustive) |
|---|---|---|---|
core | — | current (version du ZIP proposé), souvent l’affichage version | response (autoupdate pour les candidats automatiques), locale, php_version, mysql_version, new_files, URL de téléchargement, autoupdate, disable_autoupdate le cas échéant |
plugin | plugin, slug | new_version | package, url, id, requires_php, autoupdate, disable_autoupdate |
theme | theme (identifiant de la feuille de style) | new_version | package, url, requires_php, autoupdate, disable_autoupdate |
translation | type (core, plugin ou theme), slug, language | version | package, autoupdate — objets issus des tableaux de traduction via wp_get_translation_updates() |
Ressources pour les développeurs
- Référence de l’action
automatic_updates_complete: référence du crochet. - Référence de
WP_Automatic_Updater::run(): là où les résultats sont produits.
4.8 L’e-mail de récupération après erreur fatale (WP_Recovery_Mode)
Une erreur fatale au démarrage peut déclencher le mode de récupération, qui envoie par e-mail un lien de connexion. Ce chemin est distinct des e-mails du programme de mise à jour automatique.
Fonctionnement
WP_Recovery_Mode, dans wp-includes/class-wp-recovery-mode.php, gère la détection et l’envoi de l’e-mail quand une erreur fatale casse le site après une modification. Ses déclencheurs, ses options et ses messages diffèrent de ceux de WP_Automatic_Updater. Ne confondez pas les deux lors du diagnostic d’une panne après mise à jour.
Déroulement
- Une erreur fatale survient.
- Le mode de récupération peut s’activer.
- WordPress envoie à l’administrateur du site un e-mail contenant un lien de connexion sécurisé.
- L’administrateur corrige le problème à l’aide de ce lien.
- Ce processus est distinct des e-mails de succès ou d’échec des mises à jour en arrière-plan.
Référence
| Classe | Fichier | Hérite de | Rôle |
|---|---|---|---|
WP_Recovery_Mode | class-wp-recovery-mode.php | — | Récupération après erreur fatale et envoi de l’e-mail |
Ressources pour les développeurs
- Référence de la classe
WP_Recovery_Mode: classe du mode de récupération.
