Application : comment WordPress installe les mises à jour

2.1 Le modèle d’application

L’application est la phase où WordPress télécharge les paquets, les décompresse, remplace les fichiers et exécute le travail de suivi. Pour diagnostiquer une mise à jour en échec, vous avez besoin de ce modèle, distinct de la découverte et de la phase de mise à niveau de la base de données.

Fonctionnement

WP_Upgrader coordonne le téléchargement, l’accès au système de fichiers, les emplacements de décompression sous wp-content/upgrade/, install_package() et l’action upgrader_process_complete. Les interfaces interactives utilisent des habillages. Les mises à jour en arrière-plan utilisent Automatic_Upgrader_Skin et WP_Automatic_Updater. Les opérations groupées suivent la progression des habillages via update_count et update_current. Remplacer des fichiers n’équivaut pas à migrer la base de données ; voir §2.4. La vérification des signatures de paquets et le comportement du dossier de préparation sont traités en §2.12 et §2.13.

Déroulement

1. Un point d’entrée construit un moteur de mise à niveau et un habillage.
2. Les flux interactifs peuvent demander des identifiants pour le système de fichiers.
3. Le paquet se télécharge, sauf si un filtre court-circuite la requête.
4. Les fichiers prennent leur place.
5. Les crochets s’exécutent et le mode maintenance peut basculer.
6. Les caches d’extensions ou de thèmes se vident après le succès (§2.11).
7. Le remplacement des fichiers du cœur peut encore exiger un passage distinct de wp_upgrade() pour le schéma (§2.4).

Référence

Couche	Responsabilité
WP_Upgrader	Orchestration : téléchargement, décompression, installation, crochets
Sous-classes spécialisées	Moteurs de mise à niveau du cœur, des extensions, des thèmes et des paquets de langue
Habillages	Canal de sortie : HTML, JSON ou messages mis en tampon

Ressources pour les développeurs

• Référence de la classe WP_Upgrader : classe de base de tous les moteurs de mise à niveau.

---

2.2 WP_Upgrader : la classe de base

WP_Upgrader fournit l’implémentation commune du téléchargement, du travail sur le système de fichiers, de la décompression et de l’installation des paquets. La plupart des crochets de personnalisation s’attachent ici ou dans ses sous-classes.

Fonctionnement

La classe, dans wp-admin/includes/class-wp-upgrader.php, coordonne le téléchargement des paquets vers un fichier temporaire via download_url(), le travail avec WP_Filesystem, la décompression des fichiers ZIP dans wp-content/upgrade/ via unpack_package(), l’appel à install_package() et le déclenchement de l’action upgrader_process_complete. Les opérations groupées incrémentent les compteurs des habillages de progression.

Déroulement

1. L’appelant construit un moteur de mise à niveau et un habillage.
2. download_package() peut déclencher le filtre upgrader_pre_download.
3. install_package() exécute dans l’ordre les filtres de préinstallation, de sélection de la source, de nettoyage de la destination et de post-installation.
4. À la fin, upgrader_process_complete se déclenche.
5. Les erreurs renvoient des objets WP_Error à l’habillage ou à l’appelant.

Référence

Classe	Fichier	Hérite de	Rôle
WP_Upgrader	class-wp-upgrader.php	—	Orchestration de base, verrous et assistants de maintenance

Ressources pour les développeurs

• Référence de WP_Upgrader::install_package() : crochets de la chaîne d’installation.

---

2.3 Les moteurs de mise à niveau spécialisés

Chaque grand type de paquet dispose d’une classe de mise à niveau adaptée à ses particularités. Quand vous étendez les flux de mise à jour, vous héritez en général de ces classes ou vous les appelez.

Fonctionnement

Core_Upgrader remplace les fichiers du cœur de WordPress et prend en charge, dans sa méthode upgrade(), les versions partielles et les options liées au retour en arrière. Plugin_Upgrader gère les chemins d’une extension seule, bulk_upgrade() et les installations depuis un ZIP ou une URL. Theme_Upgrader gère les mises à jour et les installations de thèmes. Language_Pack_Upgrader installe les mises à jour de traduction collectées dans les transients.

Le remplacement des fichiers du cœur par Core_Upgrader reste distinct de la routine de mise à niveau de la base de données décrite en §2.4.

Déroulement

1. Le point d’entrée choisit la classe appropriée.
2. Le moteur reçoit les métadonnées du paquet depuis les transients ou des arguments directs.
3. Les opérations sur les fichiers tournent sous mode maintenance et verrous, le cas échéant.
4. Language_Pack_Upgrader::async_upgrade() s’attache à la priorité 20 sur upgrader_process_complete, si bien que les traductions s’installent après une mise à niveau du cœur, d’une extension ou d’un thème dans la même requête.
5. WP_Automatic_Updater::run() peut retirer puis réattacher ces écouteurs pour maîtriser l’ordre pendant les lots automatiques.

Référence

Classe	Fichier	Hérite de	Rôle
Core_Upgrader	class-core-upgrader.php	WP_Upgrader	Remplacement des fichiers du cœur
Plugin_Upgrader	class-plugin-upgrader.php	WP_Upgrader	Mises à jour et installations d’extensions
Theme_Upgrader	class-theme-upgrader.php	WP_Upgrader	Mises à jour et installations de thèmes
Language_Pack_Upgrader	class-language-pack-upgrader.php	WP_Upgrader	Paquets de traduction

Ressources pour les développeurs

• Référence de la classe Core_Upgrader : mises à jour du cœur.

---

2.4 La phase de mise à niveau de la base de données (wp_upgrade())

Remplacer les fichiers du cœur et migrer la base de données sont deux étapes distinctes. Beaucoup de problèmes viennent de leur confusion.

Fonctionnement

Une fois que Core_Upgrader a remplacé les fichiers, la phase de mise à niveau de la base de données s’exécute séparément, via wp_upgrade() dans wp-admin/includes/upgrade.php, en dehors de WP_Upgrader::install_package(). Cette routine compare l’option db_version stockée à la variable globale $wp_db_version. Si les valeurs diffèrent, la routine exécute pre_schema_upgrade(), make_db_current_silent() et upgrade_all(). Sur un multisite, upgrade_network() s’exécute sur le site principal quand c’est applicable. Après avoir vidé les caches, WordPress déclenche do_action( 'wp_upgrade', $wp_db_version, $wp_current_db_version ), où le premier argument est la nouvelle version de la base de données et le second l’ancienne. Les changements de tables et de schéma reposent en général sur dbDelta() pour un SQL idempotent.

Remarque : les fichiers peuvent correspondre à une nouvelle version sans que wp_upgrade() ne se soit terminée ou sans qu’une erreur ne survienne en cours de route. La commande WP-CLI wp core update-db force la phase de base de données indépendamment. Après une mise à jour des fichiers du cœur, vérifiez que db_version (et les métadonnées de site du multisite, le cas échéant) correspond à ce qui est attendu avant de considérer la mise à niveau comme terminée.

Déroulement

1. Core_Upgrader installe la nouvelle arborescence de fichiers du cœur.
2. Un chargement de page d’administration ou une exécution en ligne de commande appelle wp_upgrade() quand les versions diffèrent.
3. wp_upgrade() exécute les mises à niveau silencieuses et celles du réseau selon les besoins.
4. Les caches se vident et l’action wp_upgrade se déclenche.
5. Si l’étape 2 est sautée, le site exécute du nouveau PHP avec un ancien schéma.

Référence

Fonction	Fichier	Retour	Remarques
wp_upgrade()	wp-admin/includes/upgrade.php	void	Migration du schéma après le remplacement des fichiers du cœur
dbDelta()	wp-admin/includes/upgrade.php	tableau	Applique les écarts SQL de façon idempotente

Ressources pour les développeurs

• Référence de wp_upgrade() : routine de mise à niveau de la base de données.
• Référence de l’action wp_upgrade : se déclenche après une mise à niveau de la base de données.
• Commande WP-CLI wp core update-db : mise à niveau de la base de données en ligne de commande.

---

2.5 Les habillages de mise à niveau : la couche de sortie

Les habillages adaptent la sortie du moteur de mise à niveau à une page HTML complète, à du JSON pour AJAX ou à une exécution silencieuse en arrière-plan. Ce ne sont pas des thèmes décoratifs : c’est le canal entre le moteur et l’environnement d’exécution.

Fonctionnement

Les habillages héritent de WP_Upgrader_Skin et implémentent le contrat entre une instance de moteur de mise à niveau et son environnement. Ils n’étendent pas WP_Upgrader lui-même. L’administration interactive utilise des habillages qui affichent la progression, les erreurs et le formulaire d’identifiants FTP. Les habillages AJAX collectent les messages et les erreurs pour le JSON. Les habillages de mise à jour en arrière-plan suppriment la sortie visible et mettent en tampon les demandes d’identifiants ; leurs messages alimentent les journaux et le corps des e-mails.

Le moteur de mise à niveau appelle feedback(), error(), header(), footer() et request_filesystem_credentials(). Les chaînes viennent souvent de $upgrader->strings, définies par les méthodes upgrade_strings() des sous-classes. Automatic_Upgrader_Skin met en tampon la sortie des identifiants et accumule les messages destinés aux notifications. WP_Ajax_Upgrader_Skin l’étend pour collecter les erreurs des réponses asynchrones.

Déroulement

1. Le moteur de mise à niveau définit un habillage.
2. Chaque étape appelle les méthodes de l’habillage pour rendre compte de la progression.
3. Les flux interactifs impriment ou renvoient des données structurées.
4. Les flux d’arrière-plan mettent les messages en tampon.
5. En cas d’échec, l’habillage ou la couche AJAX fait remonter les erreurs. Les exécutions en arrière-plan n’envoient un e-mail que lorsque le programme de mise à jour automatique traite le lot (partie 4).

Référence

Classe	Fichier	Hérite de	Rôle
WP_Upgrader_Skin	class-wp-upgrader-skin.php	—	Base : identifiants et retour par défaut
Bulk_Upgrader_Skin	class-bulk-upgrader-skin.php	WP_Upgrader_Skin	Progression de plusieurs éléments
Plugin_Upgrader_Skin	class-plugin-upgrader-skin.php	WP_Upgrader_Skin	Écran d’une extension
Theme_Upgrader_Skin	class-theme-upgrader-skin.php	WP_Upgrader_Skin	Écran d’un thème
Bulk_Plugin_Upgrader_Skin	fichier correspondant	Bulk_Upgrader_Skin	Interface de mise à jour groupée d’extensions
Bulk_Theme_Upgrader_Skin	fichier correspondant	Bulk_Upgrader_Skin	Interface de mise à jour groupée de thèmes
Automatic_Upgrader_Skin	class-automatic-upgrader-skin.php	WP_Upgrader_Skin	Pas de HTML ; messages pour l’e-mail ou les journaux
WP_Ajax_Upgrader_Skin	class-wp-ajax-upgrader-skin.php	Automatic_Upgrader_Skin	Erreurs et messages AJAX

Ressources pour les développeurs

• Référence de la classe WP_Upgrader_Skin : classe d’habillage de base.

---

2.6 WP_Plugin_Dependencies : résolution des dépendances (WordPress 6.5 et suivantes)

Les dépendances d’extensions déclarées dans les en-têtes sont résolues par WP_Plugin_Dependencies. L’ordre des mises à jour groupées du cœur n’effectue pas de tri topologique par dépendance ; cette API aide votre code à ordonner correctement le travail.

Fonctionnement

L’en-tête Requires Plugins liste des identifiants (slugs) d’extensions de WordPress.org séparés par des virgules. WP_Plugin_Dependencies, dans wp-includes/class-wp-plugin-dependencies.php, lit les en-têtes, récupère les métadonnées des dépendances et sait détecter les graphes circulaires. L’interface d’installation désactive le bouton « Installer maintenant » tant que les prérequis ne sont pas satisfaits. L’application de ces règles par WP-CLI est plus stricte à l’activation ; plusieurs commandes peuvent être nécessaires.

Les mises à jour groupées du cœur ne réordonnent rien selon le graphe de dépendances. Des assistants publics comme get_dependency_names() et get_dependency_filepath() vous aident à déduire un ordre dépendance-avant-dépendant, même si certains éléments internes restent protégés.

Déroulement

1. Le cœur charge les métadonnées de dépendances depuis les en-têtes des extensions.
2. Les dépendances non satisfaites bloquent les actions d’installation dans l’interface.
3. Les mises à jour s’exécutent dans l’ordre de l’appelant, sauf si du code externe les réordonne à partir des données de dépendances.
4. L’activation peut encore échouer si des contraintes ne sont pas remplies.

Référence

Classe	Fichier	Hérite de	Rôle
WP_Plugin_Dependencies	class-wp-plugin-dependencies.php	—	Graphe et métadonnées des extensions requises

Ressources pour les développeurs

• Référence de la classe WP_Plugin_Dependencies : référence de la classe.
• Annonce de fusion des dépendances d’extensions : contexte de la fonctionnalité.

---

2.7 Le système de retour en arrière (WordPress 6.2 à 6.6)

La prise en charge du retour en arrière a évolué au fil des versions : déplacements de dossiers plus sûrs, retour en arrière manuel des extensions et des thèmes avec sauvegardes temporaires, puis retour en arrière automatique des extensions après les erreurs fatales détectées par boucle locale.

Fonctionnement

WordPress 6.2 a introduit move_dir() pour centraliser les déplacements de type atomique entre les couches de WP_Filesystem.

WordPress 6.3 a ajouté le retour en arrière manuel des extensions et des thèmes. Avant le remplacement, les arborescences précédentes partent vers wp-content/upgrade-temp-backup/plugins/{slug} ou .../themes/{slug}. En cas de WP_Error renvoyée par install_package() ou d’échec associé, la sauvegarde est restaurée. Un échec de réactivation peut aussi restaurer la copie antérieure. Santé du site a gagné des tests sur l’écriture dans le dossier de sauvegarde et sur l’espace disque.

WordPress 6.6 a ajouté le retour en arrière automatique pour les extensions actives. Après une mise à jour, le cœur peut envoyer une requête de boucle locale vers l’URL d’accueil pour détecter les erreurs fatales PHP et appeler restore_temp_backup(). Les extensions inactives échappent à la détection des erreurs fatales. Un e-mail peut suivre un retour en arrière.

Ces sauvegardes temporaires ne constituent pas un produit de retour en arrière destiné aux utilisateurs. En cas de succès comme après une restauration, WordPress en vide le contenu. WP_Upgrader::init() planifie chaque semaine wp_delete_temp_updater_backups ; la suppression peut être reportée quand des verrous ou des requêtes AJAX sont actifs.

Déroulement

1. Une mise à jour démarre et peut créer une sauvegarde temporaire.
2. WordPress remplace les fichiers.
3. En cas d’échec ou de détection d’une erreur fatale, la restauration part de la sauvegarde temporaire.
4. Le cron finit par supprimer les anciennes sauvegardes temporaires.
5. Voir §2.10 pour le détail des boucles locales.

Référence

Phase	Version	Comportement
Déplacements de dossiers plus sûrs	6.2	move_dir() pour des déplacements de type atomique
Retour en arrière manuel	6.3	Retour en arrière des extensions et des thèmes depuis une sauvegarde temporaire
Retour en arrière automatique des extensions actives	6.6	Retour en arrière après une erreur fatale détectée par boucle locale

Ressources pour les développeurs

• Nouveautés de la 6.3 : retour en arrière pour les mises à jour manuelles d’extensions et de thèmes en échec : fonctionnalité de retour en arrière manuel.
• Proposition de fusion : retour en arrière après une mise à jour automatique : chemin du retour en arrière automatique.

---

2.8 Les verrous des moteurs de mise à niveau

Les verrous empêchent des processus de mise à niveau simultanés de corrompre l’état. Le programme de mise à jour automatique et le moteur de mise à niveau du cœur utilisent des noms de verrou et des délais d’expiration différents.

Fonctionnement

WP_Upgrader::create_lock( $lock_name, $release_timeout ) enregistre une option de verrou contenant un horodatage Unix. Le délai de libération par défaut, quand il est omis, est d’une heure. WP_Automatic_Updater::run() utilise le verrou auto_updater avec le délai par défaut. Core_Upgrader utilise core_updater avec un délai de 15 minutes. release_lock() supprime l’option. Un verrou obsolète bloque les nouvelles exécutions jusqu’à son expiration ou jusqu’à la suppression manuelle de l’option de verrou via les API appropriées.

Déroulement

1. Une exécution appelle create_lock().
2. Si le verrou existe et n’a pas expiré, la nouvelle exécution abandonne ou attend, selon la logique de l’appelant.
3. À la fin ou en cas d’arrêt fatal, release_lock() s’exécute si l’appelant l’implémente.
4. Si un processus meurt sans libérer le verrou, le verrou expire après le délai prévu.

Référence

Nom du verrou	Délai type	Utilisé par
auto_updater	défaut (une heure)	WP_Automatic_Updater::run()
core_updater	900 secondes (15 minutes)	Core_Upgrader

Ressources pour les développeurs

• Référence de WP_Upgrader::create_lock() : acquisition du verrou.
• Référence de WP_Upgrader::release_lock() : libération du verrou.

---

2.9 Le mode maintenance

Le mode maintenance limite l’exécution du front-end pendant que les fichiers sont incohérents. Les lots automatiques peuvent le maintenir plus longtemps pour éviter de servir du code à moitié mis à jour.

Fonctionnement

WP_Upgrader::maintenance_mode( true | false ) bascule le fichier .maintenance pendant les mises à jour. Pour les mises à jour automatiques, le mode maintenance peut rester actif pendant tout le lot sur les versions qui le prennent en charge, afin que les requêtes du front-end ne tombent pas sur du code partiellement mis à jour pendant le travail lié au retour en arrière.

Déroulement

1. Une mise à niveau commence et active le mode maintenance.
2. WordPress remplace les fichiers.
3. En cas de succès ou d’échec maîtrisé, WordPress désactive le mode maintenance.
4. Les lots longs gardent le mode maintenance actif jusqu’à leur fin, selon le comportement du cœur pour cette version.

Référence

Mécanisme	Rôle
Fichier .maintenance	Court-circuite les requêtes du front-end pendant une mise à niveau

Ressources pour les développeurs

• Présentation du processus de mise à niveau de WordPress : décrit le comportement du fichier .maintenance.

---

2.10 Les requêtes de boucle locale dans la chaîne de mise à jour

Les requêtes de boucle locale sont des requêtes HTTP que PHP adresse au front-end du même site. Elles comptent pour Santé du site et pour le retour en arrière automatique des extensions après une erreur fatale.

Fonctionnement

Une boucle locale cible en général home_url( '/' ) avec des arguments de requête de contrôle. Le test de boucle locale de Santé du site vérifie que le site arrive à se joindre lui-même.

La détection des erreurs fatales du programme de mise à jour automatique de WordPress 6.6 et suivantes utilise wp_remote_get() sur l’URL d’accueil. Si la réponse est une WP_Error de transport, le cœur peut la traiter comme une erreur fatale aux fins du retour en arrière, si bien qu’une panne d’infrastructure peut déclencher une restauration. Vérifiez le comportement dans WP_Automatic_Updater::has_fatal_error() pour votre version.

Les environnements localhost, les proxys inverses ou un HTTP sortant bloqué peuvent casser les boucles locales.

Déroulement

1. Le programme de mise à jour termine une modification d’extension.
2. Le cœur envoie une requête HTTP vers l’URL d’accueil.
3. Le cœur inspecte la réponse à la recherche de marqueurs d’erreur fatale.
4. Sur un signal d’erreur fatale positif, le retour en arrière peut s’exécuter.
5. Sur une panne de transport, le comportement suit l’implémentation actuelle du cœur.

Référence

Contexte	Rôle
Santé du site	Diagnostique la capacité de boucle locale
Retour en arrière automatique de WordPress 6.6 et suivantes	Détection des erreurs fatales après la mise à jour d’une extension active

Ressources pour les développeurs

• Référence de wp_remote_get() : primitive HTTP GET utilisée dans les contrôles de boucle locale.

---

2.11 L’invalidation des caches après les mises à jour

Après un changement de fichiers, WordPress doit rafraîchir les caches d’exécution des extensions et des thèmes pour que l’interface et les API reflètent les nouvelles versions, sans requêtes HTTP inutiles vers WordPress.org.

Fonctionnement

Après une mise à jour réussie d’une extension ou d’un thème, le cœur appelle wp_clean_plugins_cache() et wp_clean_themes_cache(). Chaque fonction vide par défaut le transient de site concerné, puis rafraîchit les caches d’objets ou relit les dossiers de thèmes.

wp_clean_update_cache() supprime en un seul appel les transients update_core, update_plugins et update_themes, et invoque les nettoyeurs d’extensions et de thèmes quand ils existent. Il ne contacte pas WordPress.org de lui-même.

wp_update_plugins() et wp_update_themes() lancent des requêtes POST immédiates, soumises aux limitations internes. Utilisez-les quand vous avez besoin de charges utiles d’offres fraîches dans la même requête, et pas seulement de caches vidés.

Déroulement

1. Une mise à niveau réussit.
2. Les nettoyeurs de cache s’exécutent.
3. Le prochain appel à get_plugins() ou à wp_get_themes() renvoie des données fraîches.
4. Les compteurs de la barre latérale se rafraîchissent au chargement suivant de l’administration si les transients ont été vidés.
5. Le code sur mesure qui met à niveau en dehors des chemins du cœur devrait appeler les mêmes nettoyeurs si les versions semblent obsolètes.

Référence

Fonction	Fichier	Retour	Remarques
wp_clean_plugins_cache()	wp-includes/plugin.php	void	Vide les caches de données des extensions et le transient update_plugins
wp_clean_themes_cache()	wp-includes/theme.php	void	Relit les thèmes ; vide le transient update_themes
wp_clean_update_cache()	wp-includes/update.php	void	Vide les trois transients de mise à jour et les caches associés

Ressources pour les développeurs

• Référence de wp_clean_update_cache() : invalidation en un seul appel.

---

2.12 La vérification des signatures cryptographiques (Ed25519)

À partir de WordPress 5.2, le cœur sait vérifier les signatures Ed25519 des paquets téléchargés avant de les considérer comme dignes de confiance pour l’installation. Cela limite les altérations de la chaîne d’approvisionnement entre WordPress.org et le système de fichiers, en confrontant chaque paquet à des clés distribuées avec WordPress.

Fonctionnement

verify_file_signature(), dans wp-admin/includes/file.php, calcule l’empreinte du fichier téléchargé avec SHA-384, puis vérifie les signatures détachées avec sodium_crypto_sign_verify_detached() face aux clés publiques renvoyées par wp_trusted_keys(). Les signatures sont encodées en base64 pendant le transport ; les clés sont des clés publiques encodées en base64.

L’extension sodium native de PHP est utilisée quand elle est disponible. Sinon, WordPress peut recourir au polyfill sodium_compat embarqué, sous réserve d’un contrôle de performance à l’exécution. Si la vérification ne peut pas s’exécuter dans un délai raisonnable, le cœur renvoie une WP_Error de code signature_verification_unsupported au lieu d’ignorer silencieusement la cryptographie. Si aucune signature n’accompagne le paquet, la vérification échoue avec signature_verification_no_signature. Si aucune signature candidate ne correspond à une clé de confiance, la vérification échoue avec signature_verification_failed.

La liste des clés de confiance est filtrable via wp_trusted_keys. Les assistants de téléchargement HTTP comme download_url() intègrent ce chemin, si bien que la vérification a lieu après le téléchargement du ZIP et avant que le moteur de mise à niveau ne considère le paquet comme fiable pour l’extraction.

Échec non bloquant du cœur : pour les mises à jour du cœur uniquement, Core_Upgrader::upgrade() peut traiter une WP_Error de signature portant softfail-filename dans ses données d’erreur comme un cas non fatal. L’échec peut apparaître comme un retour d’information alors que le chemin de téléchargement issu des données d’erreur reste utilisé, ce qui laisse la mise à niveau se poursuivre. Les autres types de paquets, et les erreurs sans cette échappatoire, s’interrompent en général quand la vérification renvoie une WP_Error.

Déroulement

1. Une URL de paquet se télécharge dans un fichier temporaire.
2. Les éléments de signature venus de la réponse de mise à jour ou des métadonnées qui l’accompagnent entrent dans verify_file_signature().
3. En cas de succès, l’installation se poursuit.
4. Sur une WP_Error, la mise à niveau s’interrompt pour ce paquet, sauf par le chemin d’échec non bloquant du cœur décrit plus haut.
5. Dans les environnements non pris en charge, l’opération échoue avec un code d’erreur défini plutôt que de terminer par une installation non vérifiée.

Référence

Fonction	Rôle
verify_file_signature()	Vérification Ed25519 sur l’empreinte SHA-384 du fichier présent sur disque
wp_trusted_keys()	Renvoie les clés publiques de confiance encodées en base64 (filtrable)
sodium_crypto_sign_verify_detached()	Primitive utilisée quand elle est disponible ; sodium_compat peut la remplacer si elle est assez rapide

Ressources pour les développeurs

• Référence de verify_file_signature() : API de vérification des signatures.
• Référence de wp_trusted_keys() : clés de signature de confiance.
• La sécurité dans WordPress 5.2 : notes de version sur les signatures et la confiance.

---

2.13 Le cycle de vie du dossier de préparation et son nettoyage

Les archives téléchargées et les arborescences de travail extraites utilisent deux emplacements différents. download_url() écrit le ZIP dans un dossier temporaire général via wp_tempnam() et get_temp_dir(). WP_Upgrader::unpack_package() prépare les fichiers décompressés sous wp-content/upgrade/. Ce dossier est l’espace de travail principal sur disque avant que les fichiers ne rejoignent wp-content/plugins/, wp-content/themes/ ou la racine du cœur. Son contenu est éphémère ; une exécution en échec ou interrompue peut laisser des résidus qui gênent les mises à niveau suivantes.

Fonctionnement

download_url() range le fichier entrant dans le dossier temporaire (dossier temporaire système, dossier de téléversement, WP_CONTENT_DIR ou /tmp/, selon get_temp_dir(), sauf si WP_TEMP_DIR impose autre chose). WP_Upgrader::download_package() transmet les URL distantes à download_url() ; le chemin renvoyé alimente ensuite unpack_package().

unpack_package() vide wp-content/upgrade/ via WP_Filesystem, construit un nom de sous-dossier de travail à partir du nom de base du paquet et lance unzip_file() dans ce dossier. Après l’extraction, WordPress supprime en général le ZIP quand $delete_package vaut vrai.

Une extraction bloquée ou partielle laisse des dossiers ou des fichiers incomplets sous upgrade/. Un disque plein, des erreurs de droits ou des processus PHP tués peuvent abandonner des ZIP temporaires ou des arborescences upgrade/. À l’exécution suivante, unpack_package() tente de vider upgrade/ avant de décompresser, mais des collisions ou des chemins résiduels peuvent encore produire une WP_Error venue de la couche système de fichiers.

Le cœur ne garantit pas le nettoyage immédiat de chaque chemin partiel après chaque échec. Les administrateurs peuvent devoir supprimer à la main les contenus obsolètes de upgrade/ lors d’un diagnostic. Les arborescences temporaires liées au retour en arrière, sous wp-content/upgrade-temp-backup/, suivent leurs propres règles de suppression et de nettoyage par cron (voir §2.7).

Déroulement

1. Le téléchargement arrive dans un fichier temporaire (pas nécessairement sous upgrade/).
2. unpack_package() décompresse l’archive dans wp-content/upgrade/{dossier-de-travail}/.
3. En cas de succès, les fichiers rejoignent leur destination finale et WordPress peut supprimer le fichier du paquet.
4. En cas d’échec, des restes peuvent subsister à la fois dans le dossier temporaire et dans upgrade/.
5. Une suppression manuelle ou un nettoyage du système de fichiers résout les échecs tenaces.
6. De l’espace disque libre et des droits en écriture restent des prérequis.

Référence

Emplacement	Contenu courant	Risque en cas de résidu
Dossier temporaire général (get_temp_dir() ou wp_tempnam())	Fichier .zip ou .tmp téléchargé avant décompression	Gros fichiers laissés en place ; pression sur le disque
wp-content/upgrade/	Vidé avant décompression ; dossiers de travail extraits pendant l’installation	Collisions de noms ; erreurs de droits ou de disque à l’exécution suivante
wp-content/upgrade-temp-backup/	Instantanés de retour en arrière (voir §2.7)	Pression sur l’espace ; crochets de nettoyage distincts

Ressources pour les développeurs

• Référence de download_url() : télécharge via wp_tempnam() ; le chemin vient de get_temp_dir().
• Référence de get_temp_dir() : dossier temporaire accessible en écriture pour les téléchargements.
• Référence de la classe WP_Upgrader : unpack_package() utilise wp-content/upgrade/ pour l’extraction.

---

2.1 Le modèle d’application

L’application est la phase où WordPress télécharge les paquets, les décompresse, remplace les fichiers et exécute le travail de suivi. Pour diagnostiquer une mise à jour en échec, vous avez besoin de ce modèle, distinct de la découverte et de la phase de mise à niveau de la base de données.

Fonctionnement

WP_Upgrader coordonne le téléchargement, l’accès au système de fichiers, les emplacements de décompression sous wp-content/upgrade/, install_package() et l’action upgrader_process_complete. Les interfaces interactives utilisent des habillages. Les mises à jour en arrière-plan utilisent Automatic_Upgrader_Skin et WP_Automatic_Updater. Les opérations groupées suivent la progression des habillages via update_count et update_current. Remplacer des fichiers n’équivaut pas à migrer la base de données ; voir §2.4. La vérification des signatures de paquets et le comportement du dossier de préparation sont traités en §2.12 et §2.13.

Déroulement

1. Un point d’entrée construit un moteur de mise à niveau et un habillage.
2. Les flux interactifs peuvent demander des identifiants pour le système de fichiers.
3. Le paquet se télécharge, sauf si un filtre court-circuite la requête.
4. Les fichiers prennent leur place.
5. Les crochets s’exécutent et le mode maintenance peut basculer.
6. Les caches d’extensions ou de thèmes se vident après le succès (§2.11).
7. Le remplacement des fichiers du cœur peut encore exiger un passage distinct de wp_upgrade() pour le schéma (§2.4).

Référence

Couche	Responsabilité
WP_Upgrader	Orchestration : téléchargement, décompression, installation, crochets
Sous-classes spécialisées	Moteurs de mise à niveau du cœur, des extensions, des thèmes et des paquets de langue
Habillages	Canal de sortie : HTML, JSON ou messages mis en tampon

Ressources pour les développeurs

• Référence de la classe WP_Upgrader : classe de base de tous les moteurs de mise à niveau.

---

2.2 WP_Upgrader : la classe de base

WP_Upgrader fournit l’implémentation commune du téléchargement, du travail sur le système de fichiers, de la décompression et de l’installation des paquets. La plupart des crochets de personnalisation s’attachent ici ou dans ses sous-classes.

Fonctionnement

La classe, dans wp-admin/includes/class-wp-upgrader.php, coordonne le téléchargement des paquets vers un fichier temporaire via download_url(), le travail avec WP_Filesystem, la décompression des fichiers ZIP dans wp-content/upgrade/ via unpack_package(), l’appel à install_package() et le déclenchement de l’action upgrader_process_complete. Les opérations groupées incrémentent les compteurs des habillages de progression.

Déroulement

1. L’appelant construit un moteur de mise à niveau et un habillage.
2. download_package() peut déclencher le filtre upgrader_pre_download.
3. install_package() exécute dans l’ordre les filtres de préinstallation, de sélection de la source, de nettoyage de la destination et de post-installation.
4. À la fin, upgrader_process_complete se déclenche.
5. Les erreurs renvoient des objets WP_Error à l’habillage ou à l’appelant.

Référence

Classe	Fichier	Hérite de	Rôle
WP_Upgrader	class-wp-upgrader.php	—	Orchestration de base, verrous et assistants de maintenance

Ressources pour les développeurs

• Référence de WP_Upgrader::install_package() : crochets de la chaîne d’installation.

---

2.3 Les moteurs de mise à niveau spécialisés

Chaque grand type de paquet dispose d’une classe de mise à niveau adaptée à ses particularités. Quand vous étendez les flux de mise à jour, vous héritez en général de ces classes ou vous les appelez.

Fonctionnement

Core_Upgrader remplace les fichiers du cœur de WordPress et prend en charge, dans sa méthode upgrade(), les versions partielles et les options liées au retour en arrière. Plugin_Upgrader gère les chemins d’une extension seule, bulk_upgrade() et les installations depuis un ZIP ou une URL. Theme_Upgrader gère les mises à jour et les installations de thèmes. Language_Pack_Upgrader installe les mises à jour de traduction collectées dans les transients.

Le remplacement des fichiers du cœur par Core_Upgrader reste distinct de la routine de mise à niveau de la base de données décrite en §2.4.

Déroulement

1. Le point d’entrée choisit la classe appropriée.
2. Le moteur reçoit les métadonnées du paquet depuis les transients ou des arguments directs.
3. Les opérations sur les fichiers tournent sous mode maintenance et verrous, le cas échéant.
4. Language_Pack_Upgrader::async_upgrade() s’attache à la priorité 20 sur upgrader_process_complete, si bien que les traductions s’installent après une mise à niveau du cœur, d’une extension ou d’un thème dans la même requête.
5. WP_Automatic_Updater::run() peut retirer puis réattacher ces écouteurs pour maîtriser l’ordre pendant les lots automatiques.

Référence

Classe	Fichier	Hérite de	Rôle
Core_Upgrader	class-core-upgrader.php	WP_Upgrader	Remplacement des fichiers du cœur
Plugin_Upgrader	class-plugin-upgrader.php	WP_Upgrader	Mises à jour et installations d’extensions
Theme_Upgrader	class-theme-upgrader.php	WP_Upgrader	Mises à jour et installations de thèmes
Language_Pack_Upgrader	class-language-pack-upgrader.php	WP_Upgrader	Paquets de traduction

Ressources pour les développeurs

• Référence de la classe Core_Upgrader : mises à jour du cœur.

---

2.4 La phase de mise à niveau de la base de données (wp_upgrade())

Remplacer les fichiers du cœur et migrer la base de données sont deux étapes distinctes. Beaucoup de problèmes viennent de leur confusion.

Fonctionnement

Une fois que Core_Upgrader a remplacé les fichiers, la phase de mise à niveau de la base de données s’exécute séparément, via wp_upgrade() dans wp-admin/includes/upgrade.php, en dehors de WP_Upgrader::install_package(). Cette routine compare l’option db_version stockée à la variable globale $wp_db_version. Si les valeurs diffèrent, la routine exécute pre_schema_upgrade(), make_db_current_silent() et upgrade_all(). Sur un multisite, upgrade_network() s’exécute sur le site principal quand c’est applicable. Après avoir vidé les caches, WordPress déclenche do_action( 'wp_upgrade', $wp_db_version, $wp_current_db_version ), où le premier argument est la nouvelle version de la base de données et le second l’ancienne. Les changements de tables et de schéma reposent en général sur dbDelta() pour un SQL idempotent.

Remarque : les fichiers peuvent correspondre à une nouvelle version sans que wp_upgrade() ne se soit terminée ou sans qu’une erreur ne survienne en cours de route. La commande WP-CLI wp core update-db force la phase de base de données indépendamment. Après une mise à jour des fichiers du cœur, vérifiez que db_version (et les métadonnées de site du multisite, le cas échéant) correspond à ce qui est attendu avant de considérer la mise à niveau comme terminée.

Déroulement

1. Core_Upgrader installe la nouvelle arborescence de fichiers du cœur.
2. Un chargement de page d’administration ou une exécution en ligne de commande appelle wp_upgrade() quand les versions diffèrent.
3. wp_upgrade() exécute les mises à niveau silencieuses et celles du réseau selon les besoins.
4. Les caches se vident et l’action wp_upgrade se déclenche.
5. Si l’étape 2 est sautée, le site exécute du nouveau PHP avec un ancien schéma.

Référence

Fonction	Fichier	Retour	Remarques
wp_upgrade()	wp-admin/includes/upgrade.php	void	Migration du schéma après le remplacement des fichiers du cœur
dbDelta()	wp-admin/includes/upgrade.php	tableau	Applique les écarts SQL de façon idempotente

Ressources pour les développeurs

• Référence de wp_upgrade() : routine de mise à niveau de la base de données.
• Référence de l’action wp_upgrade : se déclenche après une mise à niveau de la base de données.
• Commande WP-CLI wp core update-db : mise à niveau de la base de données en ligne de commande.

---

2.5 Les habillages de mise à niveau : la couche de sortie

Les habillages adaptent la sortie du moteur de mise à niveau à une page HTML complète, à du JSON pour AJAX ou à une exécution silencieuse en arrière-plan. Ce ne sont pas des thèmes décoratifs : c’est le canal entre le moteur et l’environnement d’exécution.

Fonctionnement

Les habillages héritent de WP_Upgrader_Skin et implémentent le contrat entre une instance de moteur de mise à niveau et son environnement. Ils n’étendent pas WP_Upgrader lui-même. L’administration interactive utilise des habillages qui affichent la progression, les erreurs et le formulaire d’identifiants FTP. Les habillages AJAX collectent les messages et les erreurs pour le JSON. Les habillages de mise à jour en arrière-plan suppriment la sortie visible et mettent en tampon les demandes d’identifiants ; leurs messages alimentent les journaux et le corps des e-mails.

Le moteur de mise à niveau appelle feedback(), error(), header(), footer() et request_filesystem_credentials(). Les chaînes viennent souvent de $upgrader->strings, définies par les méthodes upgrade_strings() des sous-classes. Automatic_Upgrader_Skin met en tampon la sortie des identifiants et accumule les messages destinés aux notifications. WP_Ajax_Upgrader_Skin l’étend pour collecter les erreurs des réponses asynchrones.

Déroulement

1. Le moteur de mise à niveau définit un habillage.
2. Chaque étape appelle les méthodes de l’habillage pour rendre compte de la progression.
3. Les flux interactifs impriment ou renvoient des données structurées.
4. Les flux d’arrière-plan mettent les messages en tampon.
5. En cas d’échec, l’habillage ou la couche AJAX fait remonter les erreurs. Les exécutions en arrière-plan n’envoient un e-mail que lorsque le programme de mise à jour automatique traite le lot (partie 4).

Référence

Classe	Fichier	Hérite de	Rôle
WP_Upgrader_Skin	class-wp-upgrader-skin.php	—	Base : identifiants et retour par défaut
Bulk_Upgrader_Skin	class-bulk-upgrader-skin.php	WP_Upgrader_Skin	Progression de plusieurs éléments
Plugin_Upgrader_Skin	class-plugin-upgrader-skin.php	WP_Upgrader_Skin	Écran d’une extension
Theme_Upgrader_Skin	class-theme-upgrader-skin.php	WP_Upgrader_Skin	Écran d’un thème
Bulk_Plugin_Upgrader_Skin	fichier correspondant	Bulk_Upgrader_Skin	Interface de mise à jour groupée d’extensions
Bulk_Theme_Upgrader_Skin	fichier correspondant	Bulk_Upgrader_Skin	Interface de mise à jour groupée de thèmes
Automatic_Upgrader_Skin	class-automatic-upgrader-skin.php	WP_Upgrader_Skin	Pas de HTML ; messages pour l’e-mail ou les journaux
WP_Ajax_Upgrader_Skin	class-wp-ajax-upgrader-skin.php	Automatic_Upgrader_Skin	Erreurs et messages AJAX

Ressources pour les développeurs

• Référence de la classe WP_Upgrader_Skin : classe d’habillage de base.

---

2.6 WP_Plugin_Dependencies : résolution des dépendances (WordPress 6.5 et suivantes)

Les dépendances d’extensions déclarées dans les en-têtes sont résolues par WP_Plugin_Dependencies. L’ordre des mises à jour groupées du cœur n’effectue pas de tri topologique par dépendance ; cette API aide votre code à ordonner correctement le travail.

Fonctionnement

L’en-tête Requires Plugins liste des identifiants (slugs) d’extensions de WordPress.org séparés par des virgules. WP_Plugin_Dependencies, dans wp-includes/class-wp-plugin-dependencies.php, lit les en-têtes, récupère les métadonnées des dépendances et sait détecter les graphes circulaires. L’interface d’installation désactive le bouton « Installer maintenant » tant que les prérequis ne sont pas satisfaits. L’application de ces règles par WP-CLI est plus stricte à l’activation ; plusieurs commandes peuvent être nécessaires.

Les mises à jour groupées du cœur ne réordonnent rien selon le graphe de dépendances. Des assistants publics comme get_dependency_names() et get_dependency_filepath() vous aident à déduire un ordre dépendance-avant-dépendant, même si certains éléments internes restent protégés.

Déroulement

1. Le cœur charge les métadonnées de dépendances depuis les en-têtes des extensions.
2. Les dépendances non satisfaites bloquent les actions d’installation dans l’interface.
3. Les mises à jour s’exécutent dans l’ordre de l’appelant, sauf si du code externe les réordonne à partir des données de dépendances.
4. L’activation peut encore échouer si des contraintes ne sont pas remplies.

Référence

Classe	Fichier	Hérite de	Rôle
WP_Plugin_Dependencies	class-wp-plugin-dependencies.php	—	Graphe et métadonnées des extensions requises

Ressources pour les développeurs

• Référence de la classe WP_Plugin_Dependencies : référence de la classe.
• Annonce de fusion des dépendances d’extensions : contexte de la fonctionnalité.

---

2.7 Le système de retour en arrière (WordPress 6.2 à 6.6)

La prise en charge du retour en arrière a évolué au fil des versions : déplacements de dossiers plus sûrs, retour en arrière manuel des extensions et des thèmes avec sauvegardes temporaires, puis retour en arrière automatique des extensions après les erreurs fatales détectées par boucle locale.

Fonctionnement

WordPress 6.2 a introduit move_dir() pour centraliser les déplacements de type atomique entre les couches de WP_Filesystem.

WordPress 6.3 a ajouté le retour en arrière manuel des extensions et des thèmes. Avant le remplacement, les arborescences précédentes partent vers wp-content/upgrade-temp-backup/plugins/{slug} ou .../themes/{slug}. En cas de WP_Error renvoyée par install_package() ou d’échec associé, la sauvegarde est restaurée. Un échec de réactivation peut aussi restaurer la copie antérieure. Santé du site a gagné des tests sur l’écriture dans le dossier de sauvegarde et sur l’espace disque.

WordPress 6.6 a ajouté le retour en arrière automatique pour les extensions actives. Après une mise à jour, le cœur peut envoyer une requête de boucle locale vers l’URL d’accueil pour détecter les erreurs fatales PHP et appeler restore_temp_backup(). Les extensions inactives échappent à la détection des erreurs fatales. Un e-mail peut suivre un retour en arrière.

Ces sauvegardes temporaires ne constituent pas un produit de retour en arrière destiné aux utilisateurs. En cas de succès comme après une restauration, WordPress en vide le contenu. WP_Upgrader::init() planifie chaque semaine wp_delete_temp_updater_backups ; la suppression peut être reportée quand des verrous ou des requêtes AJAX sont actifs.

Déroulement

1. Une mise à jour démarre et peut créer une sauvegarde temporaire.
2. WordPress remplace les fichiers.
3. En cas d’échec ou de détection d’une erreur fatale, la restauration part de la sauvegarde temporaire.
4. Le cron finit par supprimer les anciennes sauvegardes temporaires.
5. Voir §2.10 pour le détail des boucles locales.

Référence

Phase	Version	Comportement
Déplacements de dossiers plus sûrs	6.2	move_dir() pour des déplacements de type atomique
Retour en arrière manuel	6.3	Retour en arrière des extensions et des thèmes depuis une sauvegarde temporaire
Retour en arrière automatique des extensions actives	6.6	Retour en arrière après une erreur fatale détectée par boucle locale

Ressources pour les développeurs

• Nouveautés de la 6.3 : retour en arrière pour les mises à jour manuelles d’extensions et de thèmes en échec : fonctionnalité de retour en arrière manuel.
• Proposition de fusion : retour en arrière après une mise à jour automatique : chemin du retour en arrière automatique.

---

2.8 Les verrous des moteurs de mise à niveau

Les verrous empêchent des processus de mise à niveau simultanés de corrompre l’état. Le programme de mise à jour automatique et le moteur de mise à niveau du cœur utilisent des noms de verrou et des délais d’expiration différents.

Fonctionnement

WP_Upgrader::create_lock( $lock_name, $release_timeout ) enregistre une option de verrou contenant un horodatage Unix. Le délai de libération par défaut, quand il est omis, est d’une heure. WP_Automatic_Updater::run() utilise le verrou auto_updater avec le délai par défaut. Core_Upgrader utilise core_updater avec un délai de 15 minutes. release_lock() supprime l’option. Un verrou obsolète bloque les nouvelles exécutions jusqu’à son expiration ou jusqu’à la suppression manuelle de l’option de verrou via les API appropriées.

Déroulement

1. Une exécution appelle create_lock().
2. Si le verrou existe et n’a pas expiré, la nouvelle exécution abandonne ou attend, selon la logique de l’appelant.
3. À la fin ou en cas d’arrêt fatal, release_lock() s’exécute si l’appelant l’implémente.
4. Si un processus meurt sans libérer le verrou, le verrou expire après le délai prévu.

Référence

Nom du verrou	Délai type	Utilisé par
auto_updater	défaut (une heure)	WP_Automatic_Updater::run()
core_updater	900 secondes (15 minutes)	Core_Upgrader

Ressources pour les développeurs

• Référence de WP_Upgrader::create_lock() : acquisition du verrou.
• Référence de WP_Upgrader::release_lock() : libération du verrou.

---

2.9 Le mode maintenance

Le mode maintenance limite l’exécution du front-end pendant que les fichiers sont incohérents. Les lots automatiques peuvent le maintenir plus longtemps pour éviter de servir du code à moitié mis à jour.

Fonctionnement

WP_Upgrader::maintenance_mode( true | false ) bascule le fichier .maintenance pendant les mises à jour. Pour les mises à jour automatiques, le mode maintenance peut rester actif pendant tout le lot sur les versions qui le prennent en charge, afin que les requêtes du front-end ne tombent pas sur du code partiellement mis à jour pendant le travail lié au retour en arrière.

Déroulement

1. Une mise à niveau commence et active le mode maintenance.
2. WordPress remplace les fichiers.
3. En cas de succès ou d’échec maîtrisé, WordPress désactive le mode maintenance.
4. Les lots longs gardent le mode maintenance actif jusqu’à leur fin, selon le comportement du cœur pour cette version.

Référence

Mécanisme	Rôle
Fichier .maintenance	Court-circuite les requêtes du front-end pendant une mise à niveau

Ressources pour les développeurs

• Présentation du processus de mise à niveau de WordPress : décrit le comportement du fichier .maintenance.

---

2.10 Les requêtes de boucle locale dans la chaîne de mise à jour

Les requêtes de boucle locale sont des requêtes HTTP que PHP adresse au front-end du même site. Elles comptent pour Santé du site et pour le retour en arrière automatique des extensions après une erreur fatale.

Fonctionnement

Une boucle locale cible en général home_url( '/' ) avec des arguments de requête de contrôle. Le test de boucle locale de Santé du site vérifie que le site arrive à se joindre lui-même.

La détection des erreurs fatales du programme de mise à jour automatique de WordPress 6.6 et suivantes utilise wp_remote_get() sur l’URL d’accueil. Si la réponse est une WP_Error de transport, le cœur peut la traiter comme une erreur fatale aux fins du retour en arrière, si bien qu’une panne d’infrastructure peut déclencher une restauration. Vérifiez le comportement dans WP_Automatic_Updater::has_fatal_error() pour votre version.

Les environnements localhost, les proxys inverses ou un HTTP sortant bloqué peuvent casser les boucles locales.

Déroulement

1. Le programme de mise à jour termine une modification d’extension.
2. Le cœur envoie une requête HTTP vers l’URL d’accueil.
3. Le cœur inspecte la réponse à la recherche de marqueurs d’erreur fatale.
4. Sur un signal d’erreur fatale positif, le retour en arrière peut s’exécuter.
5. Sur une panne de transport, le comportement suit l’implémentation actuelle du cœur.

Référence

Contexte	Rôle
Santé du site	Diagnostique la capacité de boucle locale
Retour en arrière automatique de WordPress 6.6 et suivantes	Détection des erreurs fatales après la mise à jour d’une extension active

Ressources pour les développeurs

• Référence de wp_remote_get() : primitive HTTP GET utilisée dans les contrôles de boucle locale.

---

2.11 L’invalidation des caches après les mises à jour

Après un changement de fichiers, WordPress doit rafraîchir les caches d’exécution des extensions et des thèmes pour que l’interface et les API reflètent les nouvelles versions, sans requêtes HTTP inutiles vers WordPress.org.

Fonctionnement

Après une mise à jour réussie d’une extension ou d’un thème, le cœur appelle wp_clean_plugins_cache() et wp_clean_themes_cache(). Chaque fonction vide par défaut le transient de site concerné, puis rafraîchit les caches d’objets ou relit les dossiers de thèmes.

wp_clean_update_cache() supprime en un seul appel les transients update_core, update_plugins et update_themes, et invoque les nettoyeurs d’extensions et de thèmes quand ils existent. Il ne contacte pas WordPress.org de lui-même.

wp_update_plugins() et wp_update_themes() lancent des requêtes POST immédiates, soumises aux limitations internes. Utilisez-les quand vous avez besoin de charges utiles d’offres fraîches dans la même requête, et pas seulement de caches vidés.

Déroulement

1. Une mise à niveau réussit.
2. Les nettoyeurs de cache s’exécutent.
3. Le prochain appel à get_plugins() ou à wp_get_themes() renvoie des données fraîches.
4. Les compteurs de la barre latérale se rafraîchissent au chargement suivant de l’administration si les transients ont été vidés.
5. Le code sur mesure qui met à niveau en dehors des chemins du cœur devrait appeler les mêmes nettoyeurs si les versions semblent obsolètes.

Référence

Fonction	Fichier	Retour	Remarques
wp_clean_plugins_cache()	wp-includes/plugin.php	void	Vide les caches de données des extensions et le transient update_plugins
wp_clean_themes_cache()	wp-includes/theme.php	void	Relit les thèmes ; vide le transient update_themes
wp_clean_update_cache()	wp-includes/update.php	void	Vide les trois transients de mise à jour et les caches associés

Ressources pour les développeurs

• Référence de wp_clean_update_cache() : invalidation en un seul appel.

---

2.12 La vérification des signatures cryptographiques (Ed25519)

À partir de WordPress 5.2, le cœur sait vérifier les signatures Ed25519 des paquets téléchargés avant de les considérer comme dignes de confiance pour l’installation. Cela limite les altérations de la chaîne d’approvisionnement entre WordPress.org et le système de fichiers, en confrontant chaque paquet à des clés distribuées avec WordPress.

Fonctionnement

verify_file_signature(), dans wp-admin/includes/file.php, calcule l’empreinte du fichier téléchargé avec SHA-384, puis vérifie les signatures détachées avec sodium_crypto_sign_verify_detached() face aux clés publiques renvoyées par wp_trusted_keys(). Les signatures sont encodées en base64 pendant le transport ; les clés sont des clés publiques encodées en base64.

L’extension sodium native de PHP est utilisée quand elle est disponible. Sinon, WordPress peut recourir au polyfill sodium_compat embarqué, sous réserve d’un contrôle de performance à l’exécution. Si la vérification ne peut pas s’exécuter dans un délai raisonnable, le cœur renvoie une WP_Error de code signature_verification_unsupported au lieu d’ignorer silencieusement la cryptographie. Si aucune signature n’accompagne le paquet, la vérification échoue avec signature_verification_no_signature. Si aucune signature candidate ne correspond à une clé de confiance, la vérification échoue avec signature_verification_failed.

La liste des clés de confiance est filtrable via wp_trusted_keys. Les assistants de téléchargement HTTP comme download_url() intègrent ce chemin, si bien que la vérification a lieu après le téléchargement du ZIP et avant que le moteur de mise à niveau ne considère le paquet comme fiable pour l’extraction.

Échec non bloquant du cœur : pour les mises à jour du cœur uniquement, Core_Upgrader::upgrade() peut traiter une WP_Error de signature portant softfail-filename dans ses données d’erreur comme un cas non fatal. L’échec peut apparaître comme un retour d’information alors que le chemin de téléchargement issu des données d’erreur reste utilisé, ce qui laisse la mise à niveau se poursuivre. Les autres types de paquets, et les erreurs sans cette échappatoire, s’interrompent en général quand la vérification renvoie une WP_Error.

Déroulement

1. Une URL de paquet se télécharge dans un fichier temporaire.
2. Les éléments de signature venus de la réponse de mise à jour ou des métadonnées qui l’accompagnent entrent dans verify_file_signature().
3. En cas de succès, l’installation se poursuit.
4. Sur une WP_Error, la mise à niveau s’interrompt pour ce paquet, sauf par le chemin d’échec non bloquant du cœur décrit plus haut.
5. Dans les environnements non pris en charge, l’opération échoue avec un code d’erreur défini plutôt que de terminer par une installation non vérifiée.

Référence

Fonction	Rôle
verify_file_signature()	Vérification Ed25519 sur l’empreinte SHA-384 du fichier présent sur disque
wp_trusted_keys()	Renvoie les clés publiques de confiance encodées en base64 (filtrable)
sodium_crypto_sign_verify_detached()	Primitive utilisée quand elle est disponible ; sodium_compat peut la remplacer si elle est assez rapide

Ressources pour les développeurs

• Référence de verify_file_signature() : API de vérification des signatures.
• Référence de wp_trusted_keys() : clés de signature de confiance.
• La sécurité dans WordPress 5.2 : notes de version sur les signatures et la confiance.

---

2.13 Le cycle de vie du dossier de préparation et son nettoyage

Les archives téléchargées et les arborescences de travail extraites utilisent deux emplacements différents. download_url() écrit le ZIP dans un dossier temporaire général via wp_tempnam() et get_temp_dir(). WP_Upgrader::unpack_package() prépare les fichiers décompressés sous wp-content/upgrade/. Ce dossier est l’espace de travail principal sur disque avant que les fichiers ne rejoignent wp-content/plugins/, wp-content/themes/ ou la racine du cœur. Son contenu est éphémère ; une exécution en échec ou interrompue peut laisser des résidus qui gênent les mises à niveau suivantes.

Fonctionnement

download_url() range le fichier entrant dans le dossier temporaire (dossier temporaire système, dossier de téléversement, WP_CONTENT_DIR ou /tmp/, selon get_temp_dir(), sauf si WP_TEMP_DIR impose autre chose). WP_Upgrader::download_package() transmet les URL distantes à download_url() ; le chemin renvoyé alimente ensuite unpack_package().

unpack_package() vide wp-content/upgrade/ via WP_Filesystem, construit un nom de sous-dossier de travail à partir du nom de base du paquet et lance unzip_file() dans ce dossier. Après l’extraction, WordPress supprime en général le ZIP quand $delete_package vaut vrai.

Une extraction bloquée ou partielle laisse des dossiers ou des fichiers incomplets sous upgrade/. Un disque plein, des erreurs de droits ou des processus PHP tués peuvent abandonner des ZIP temporaires ou des arborescences upgrade/. À l’exécution suivante, unpack_package() tente de vider upgrade/ avant de décompresser, mais des collisions ou des chemins résiduels peuvent encore produire une WP_Error venue de la couche système de fichiers.

Le cœur ne garantit pas le nettoyage immédiat de chaque chemin partiel après chaque échec. Les administrateurs peuvent devoir supprimer à la main les contenus obsolètes de upgrade/ lors d’un diagnostic. Les arborescences temporaires liées au retour en arrière, sous wp-content/upgrade-temp-backup/, suivent leurs propres règles de suppression et de nettoyage par cron (voir §2.7).

Déroulement

1. Le téléchargement arrive dans un fichier temporaire (pas nécessairement sous upgrade/).
2. unpack_package() décompresse l’archive dans wp-content/upgrade/{dossier-de-travail}/.
3. En cas de succès, les fichiers rejoignent leur destination finale et WordPress peut supprimer le fichier du paquet.
4. En cas d’échec, des restes peuvent subsister à la fois dans le dossier temporaire et dans upgrade/.
5. Une suppression manuelle ou un nettoyage du système de fichiers résout les échecs tenaces.
6. De l’espace disque libre et des droits en écriture restent des prérequis.

Référence

Emplacement	Contenu courant	Risque en cas de résidu
Dossier temporaire général (get_temp_dir() ou wp_tempnam())	Fichier .zip ou .tmp téléchargé avant décompression	Gros fichiers laissés en place ; pression sur le disque
wp-content/upgrade/	Vidé avant décompression ; dossiers de travail extraits pendant l’installation	Collisions de noms ; erreurs de droits ou de disque à l’exécution suivante
wp-content/upgrade-temp-backup/	Instantanés de retour en arrière (voir §2.7)	Pression sur l’espace ; crochets de nettoyage distincts

Ressources pour les développeurs

• Référence de download_url() : télécharge via wp_tempnam() ; le chemin vient de get_temp_dir().
• Référence de get_temp_dir() : dossier temporaire accessible en écriture pour les téléchargements.
• Référence de la classe WP_Upgrader : unpack_package() utilise wp-content/upgrade/ pour l’extraction.

---