Mise à jour WordPress : réparer un téléchargement bloqué vers WordPress.org

Relever séparément le contrôle de version et le paquet

Ouvrez **Tableau de bord → Mises à jour** et notez le composant concerné, son état et le message détaillé. Si WordPress propose une version, ces métadonnées peuvent avoir été obtenues lors d’un contrôle antérieur. Relevez aussi le résultat et l’heure du test de communication dans **Outils → Santé du site**. Le test de Santé du site et le téléchargement exact du paquet sont deux demandes. L’un peut réussir alors que l’autre est bloqué.

Dans le message détaillé, le journal privé ou la trace HTTP, identifiez l’hôte de la demande de métadonnées et celui du paquet. Pour les mises à jour du répertoire, on rencontre notamment api.wordpress.org et downloads.wordpress.org. Certaines URL ou redirections suivent un trajet différent. Notez la dernière destination autorisée et le code qu’elle a renvoyé. Si le composant dépend d’un autre fournisseur, demandez à son mainteneur l’adresse prévue. Le trajet d’une extension distribuée ailleurs peut utiliser une politique différente.

Avec un accès limité au tableau de bord, transmettez ces deux constats et leur heure au responsable de l’hébergement. En multisite, les mises à jour peuvent dépendre des droits d’administration du réseau. Sur WordPress.com ou un site géré, utilisez les contrôles accessibles et laissez l’équipe qui administre le service examiner les sorties réseau ou le cœur géré. Avec un terminal autorisé, faites les mesures depuis le serveur ou le conteneur qui exécute WordPress. Un résultat depuis votre poste indique seulement ce que votre connexion peut joindre. Un succès avec curl sur le serveur doit encore être rapproché de l’API HTTP PHP, du proxy et de la liste d’hôtes que WordPress utilise.

Préparer les accès et choisir votre parcours

Commencez par le diagnostic natif, accessible à l’administrateur. La correction des hôtes convient ensuite si une restriction WordPress a réellement été identifiée et que vous pouvez modifier sa configuration. Les contrôles réseau avancés demandent un terminal autorisé sur l’hébergement ; sans cet accès, transmettez les observations au prestataire. Le dépôt d’un paquet officiel fournit enfin une solution de continuité lorsque le téléchargement serveur reste bloqué.

Avant de remplacer du code, préparez une sauvegarde des fichiers et de la base, vérifiez sa date et la façon de la restaurer. Gardez les archives hors de l’espace public. Une copie de test doit empêcher les paiements, courriels et autres effets réels avant d’essayer une mise à jour. Notez la version actuelle et la version cible de chaque composant concerné.

Vérifiez qu’aucune autre mise à jour ne travaille encore, notamment depuis l’outil de l’hébergeur. Réservez une fenêtre d’intervention pour le remplacement et convenez du retour arrière. Une sauvegarde ancienne peut écraser des commandes ou des textes récents : sa restauration ne se décide pas uniquement parce qu’un écran paraît bloqué.

Approche 1 : relever le test natif de communication

Ce parcours ne demande aucune nouvelle extension. Dans l’administration, ouvrez Outils, puis Santé du site. Le contrôle de communication contacte api.wordpress.org depuis WordPress. Il n’installe pas une mise à jour. Son résultat favorable signifie qu’aucune erreur de transport WordPress n’a été renvoyée ; il ne garantit pas à lui seul un statut HTTP 200. Un résultat favorable ne vérifie pas tous les hôtes d’archives, toutes les URL ni la capacité d’écrire les fichiers ; il ne faut donc pas le confondre avec une réparation complète.

L’onglet Informations aide à relever WordPress, PHP et l’environnement du serveur. Gardez les renseignements utiles au diagnostic ; ne publiez pas l’export intégral sans en examiner le contenu. Pour comparer deux essais, indiquez leur heure avec le fuseau et le même environnement. Une copie de test peut avoir une politique réseau différente du site public.

1. Ouvrez l’onglet État et attendez la fin de ses contrôles ; examinez les problèmes et les tests réussis.
2. Dépliez l’entrée de communication avec WordPress.org lorsqu’elle apparaît. Relevez son message exact, l’hôte et le détail technique disponible.
3. Comparez ce résultat à l’échec de téléchargement déjà conservé. Une API accessible avec une archive refusée dirige vers l’URL de cette archive.
4. Après une correction identifiée, revenez sur cet écran pour un nouveau constat. Cette observation seule n’exige aucun retour de configuration.

Relancer un contrôle ciblé après un incident temporaire

Si le prestataire confirme une interruption temporaire désormais terminée, commencez par Tableau de bord, puis Mises à jour. Utilisez le contrôle de recherche proposé par l’écran, souvent nommé Vérifier à nouveau. Distinguez ce contrôle des boutons qui installent ou réinstallent réellement une version. Ne choisissez pas Réinstaller maintenant pour simplement tester une connexion.

Consultez ensuite la ligne du composant concerné. La présence d’une proposition de version prouve que des informations sont disponibles ; elle ne garantit pas que le paquet sera téléchargé. Après préparation de la sauvegarde, lancez une seule mise à jour ciblée et conservez son résultat. N’utilisez pas Tout mettre à jour pour un diagnostic : plusieurs remplacements rendraient l’origine d’un nouvel échec plus difficile à isoler.

Un succès signifie que cette opération a abouti à cette heure. Une nouvelle erreur identique justifie l’approche suivante, sans séries de clics ni attente arbitraire présentée comme une réparation. Si le message change vers l’écriture, l’extraction ou la maintenance, suivez cette nouvelle étape. Ne retirez pas un verrou ou un marqueur de maintenance pendant qu’un autre processus travaille encore.

Corriger une liste d’hôtes WordPress incomplète

Cette correction concerne une restriction confirmée dans wp-config.php, accessible par SFTP ou un gestionnaire autorisé. WP_HTTP_BLOCK_EXTERNAL à true limite les requêtes de l’API HTTP de WordPress ; WP_ACCESSIBLE_HOSTS autorise des hôtes supplémentaires. Ce réglage ne modifie pas le pare-feu serveur.

L’exemple illustre une liste limitée à trois hôtes validés pour l’opération. Ce n’est pas une liste universelle : relevez aussi toute destination de redirection nécessaire et conservez les autorisations existantes justifiées. Les valeurs sont des noms d’hôtes, sans protocole ni chemin. Une configuration injectée par l’environnement doit être corrigée à sa source.

1. Conservez une copie privée de wp-config.php et retrouvez les définitions existantes avant le chargement de wp-settings.php.
2. Si le blocage est volontaire, complétez uniquement la valeur existante de WP_ACCESSIBLE_HOSTS avec les hôtes manquants confirmés. Créez cette définition seulement si elle manque et que cette politique est bien voulue ; aucun doublon.
3. Gardez le blocage externe actif. Enregistrez, puis refaites Santé du site et le contrôle de téléchargement ciblé.
4. Si l’ajout était injustifié ou crée un problème, rétablissez la valeur enregistrée. Une erreur de syntaxe demande de restaurer la copie privée.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org,wordpress.org' );

Approche 2 : mesurer depuis l’hébergement

Ce parcours s’adresse à une personne disposant d’un terminal autorisé sur le serveur ou le conteneur du site. Un terminal sur votre ordinateur mesure un autre trajet. La commande suivante effectue une lecture HTTPS publique, sans télécharger un paquet ni lancer une mise à jour. Elle conserve la vérification du certificat et ne suit pas automatiquement les redirections.

Sous Linux, /dev/null élimine le corps ; les en-têtes, le statut et la durée restent affichés. Sous Windows, utilisez curl.exe et remplacez /dev/null par NUL. L’option -q, placée en premier, ignore le fichier de configuration propre à curl ; des paramètres d’environnement peuvent encore s’appliquer. Les délais sont des limites de ce contrôle, pas un réglage de WordPress.

1. Exécutez une fois la commande dans l’environnement autorisé et notez l’heure ainsi que l’erreur éventuelle.
2. Pour une archive, comparez ensuite uniquement son URL officielle exacte déjà relevée, si cette lecture est nécessaire ; elle peut transférer tout le paquet même vers /dev/null.
3. Gardez les résultats privés si des en-têtes ou une URL contiennent des données sensibles. Aucun changement de configuration ne nécessite ici un retour arrière.

curl -q --connect-timeout 10 --max-time 20 -sS -D - -o /dev/null -w '\nHTTP=%{http_code} duree=%{time_total}s\n' 'https://api.wordpress.org/'

Lire le premier échec dans l’ordre du trajet

Repérez d’abord si WordPress a émis la demande. Le code http_request_not_executed peut indiquer que sa politique HTTP a interdit cet hôte avant le transport. Comparez l’adresse exacte et les redirections nécessaires aux autorisations du site. Si une règle doit changer, demandez un ajout limité à la destination validée. Si une trace ne montre aucune requête côté serveur, vérifiez aussi que le contrôle a réellement été lancé et que le journal couvre ce contexte.

Si le transport a été utilisé, lisez le détail de l’erreur. Les exemples ci-dessous donnent des points de départ. Le même nombre peut prendre un autre sens s’il s’agit d’un statut HTTP plutôt que d’un numéro d’erreur cURL.

Si un contrôle direct et le contrôle WordPress divergent, comparez le trajet réellement emprunté avant de chercher un correctif. Les variables de proxy du terminal, les constantes WordPress et le magasin de certificats du transport peuvent différer. Gardez les valeurs privées. Une modification de DNS, de certificat ou de proxy doit viser la couche qui a échoué et conserver l’ancienne valeur pour pouvoir revenir au réglage précédent.

• **cURL 6** indique que le nom de la destination n’a pas été résolu pour ce trajet. **cURL 5** désigne le nom du proxy. Faites vérifier le résolveur depuis l’environnement du site et précisez si l’appel passe par un proxy qui résout lui-même les destinations. Une résolution réussie depuis votre poste ou pour un autre hôte n’explique pas le résultat du serveur.
• **cURL 60** signale un certificat que le client ne valide pas. Relevez le nom contacté, l’heure et le certificat réellement présenté. Vérifiez la chaîne d’autorités de confiance utilisée par PHP ou WordPress et l’existence d’une inspection TLS autorisée. **cURL 77** oriente vers le fichier d’autorités que le client ne peut pas charger. Conservez HTTPS et la vérification du certificat pendant le contrôle.
• Un **407** associé au tunnel CONNECT désigne la réponse d’un proxy. Vérifiez l’hôte, le port et la configuration d’authentification attendue avec l’équipe réseau. Une requête cURL peut échouer avec un code de transport alors que le message indique le 407 du relais. Le serveur du paquet peut ne jamais avoir reçu la demande.
• Un **403** reçu pour le paquet est une réponse HTTP. Identifiez le service qui la renvoie. Un proxy, une politique de sortie ou le serveur du paquet peut refuser cette URL. Demandez le motif avant de changer les réglages DNS ou TLS. Une limite de délai ou une connexion refusée demande aussi de préciser la destination et l’étape atteinte.

Traiter TLS en conservant la vérification HTTPS

TLS permet notamment de vérifier l’identité du service contacté. Une erreur de confiance demande d’identifier le certificat présenté et le magasin d’autorités utilisé, pas de remplacer HTTPS par HTTP. Le certificat installé pour les visiteurs de votre propre domaine ne répare pas automatiquement la confiance utilisée par PHP vers un service extérieur.

WordPress peut fournir son propre fichier de certificats à son transport HTTP. Un succès avec curl système ne prouve donc pas que le même fichier a été lu par WordPress. Demandez une vérification dans le contexte PHP du site, y compris les droits de lecture du fichier concerné et un éventuel proxy d’inspection autorisé.

1. Relevez le message complet et le nom du service réellement contacté ; faites contrôler aussi l’heure du serveur.
2. Faites identifier le fichier ou magasin de confiance effectivement utilisé avant toute correction. S’il est absent, illisible ou périmé, le responsable restaure ou actualise ce seul élément depuis sa source de confiance.
3. Refaites le test WordPress après cette correction, puis l’opération prévue. Gardez l’état précédent pour annuler un changement mal ciblé.
4. N’ajoutez pas sslverify=false ou une option --insecure comme solution permanente.

Corriger un ancien proxy explicitement identifié

Cette branche convient après une migration lorsque l’équipe réseau confirme le nouveau proxy obligatoire et autorise la modification de wp-config.php. WordPress utilise notamment WP_PROXY_HOST et WP_PROXY_PORT pour activer son proxy HTTP. Ne retirez pas ces réglages si le serveur doit obligatoirement passer par ce relais.

L’extrait est fictif : HOTE_PROXY_CONFIRME doit devenir le nom réel, sans protocole, et 3128 doit être remplacé par le port fourni, même si celui-ci est différent. Conservez les éventuels paramètres d’authentification dans leur stockage privé ; aucun mot de passe ne figure dans cet exemple. Un proxy système ou un relais imposé par l’infrastructure relève de son propre réglage.

1. Sauvegardez la configuration en privé et retrouvez les deux définitions existantes ; ne les ajoutez pas en double.
2. Remplacez uniquement l’ancien hôte ou port confirmé incorrect. Si une variable d’environnement fournit la valeur, faites modifier cette source par son responsable.
3. Refaites le contrôle natif puis une mise à jour ciblée après sauvegarde.
4. Restaurez les anciennes valeurs si l’hypothèse était fausse. Pour un refus du pare-feu sortant, faites corriger la règle limitée à la destination nécessaire, sans ouvrir globalement le serveur.

define( 'WP_PROXY_HOST', 'HOTE_PROXY_CONFIRME' );
define( 'WP_PROXY_PORT', 3128 );

Query Monitor : observer un appel de la page courante

Query Monitor, de John Blackbourn, peut aider à repérer une URL, une durée et le composant qui réalise un appel HTTP. Sa fiche officielle indique actuellement WordPress 6.3 minimum, PHP 7.4 minimum et une compatibilité testée jusqu’à WordPress 7.1.4. Ces indications ne garantissent pas toutes les combinaisons d’extensions. Il reste facultatif ; Santé du site et les relevés serveur suffisent souvent.

Si le téléchargement serveur est bloqué, son installation classique peut échouer aussi. Sur une copie préparée, vous pouvez employer son ZIP officiel selon le parcours suivant. Son intérêt est l’observation : il ne répare ni DNS, ni certificat, ni pare-feu.

1. Après installation et activation autorisées, ouvrez une page d’administration qui se termine normalement et provoque la consultation à examiner.
2. Dans la barre d’administration, ouvrez le menu Query Monitor puis HTTP API Calls. Relevez l’hôte, la durée, le résultat et l’appelant disponibles.
3. Examinez seulement les appels de ce chargement. Une absence d’entrée ne prouve pas que l’ancien téléchargement a réussi : il n’y a pas d’historique de cet incident.
4. Ne relancez pas un paiement pour obtenir une trace. Désactivez l’outil après le diagnostic si son usage temporaire est terminé.

Contrôler l’archive sans appliquer la mise à jour

Quand l’API répond, reprenez l’URL officielle exacte du paquet relevée dans l’erreur ou dans la trace. Un résultat sur la racine de l’API montre qu’un hôte a répondu. Il ne dit pas que le serveur d’archives accepte ce fichier. Si vous utilisez le terminal de l’hébergement, remplacez l’URL de l’exemple par celle du paquet validé. Commencez par examiner le statut et, s’il y a lieu, l’en-tête de redirection. Vérifiez la destination avant de poursuivre. Une demande limitée aux en-têtes peut être utile pour un premier constat, mais certains serveurs lui répondent différemment d’un téléchargement.

Si le responsable doit confirmer un véritable téléchargement, faites-le dans un dossier temporaire privé avec la vérification TLS active et le paquet exact prévu par le fournisseur. Gardez le statut final, la taille reçue et, si une somme de contrôle officielle est disponible, son résultat. Supprimez le fichier de test après lecture. Une réponse 200 avec une page HTML de connexion ou une archive incomplète ne valide pas le paquet. Si une URL contient un jeton ou une signature dans ses paramètres, gardez-la privée et transmettez une version expurgée du relevé.

Après correction de la sortie réseau, refaites le contrôle de métadonnées puis celui du paquet. Vérifiez que les deux atteignent leur destination depuis WordPress ou depuis le même environnement de transport. Le téléchargement réussi est un résultat distinct de l’installation. Si l’erreur devient « impossible d’écrire le fichier temporaire », « décompression impossible » ou « impossible de copier le fichier », conservez ce nouveau message. Le diagnostic passe alors à l’étape qu’il désigne.

Approche 3 : utiliser le ZIP officiel d’une extension

Ce parcours permet d’appliquer une mise à jour préparée quand votre ordinateur peut récupérer le paquet officiel et que l’administration accepte son dépôt. Il ne rétablit pas les futures connexions sortantes. Il exige les droits d’installation et de mise à jour, un paquet correspondant au même produit et une sauvegarde restaurable. Une archive trouvée sur un miroir inconnu ne convient pas.

Téléchargez le ZIP installable depuis la fiche WordPress.org du produit ou votre espace officiel chez son éditeur. Vérifiez nom, auteur, version cible et prérequis. Ne confondez pas archive complète de documentation, version gratuite et version commerciale. Si des fichiers de cette extension ont été personnalisés, préservez ces changements avant remplacement.

1. Ouvrez Extensions, Ajouter une extension, puis Téléverser une extension. Choisissez le ZIP officiel sans le décompresser et cliquez sur Installer maintenant.
2. Si WordPress reconnaît l’extension existante, comparez les informations de l’ancienne version et du paquet.
3. Confirmez Remplacer l’extension actuelle par celle téléversée seulement si les informations concordent. Annulez si un autre produit ou une rétrogradation inattendue apparaît.
4. Attendez le résultat, contrôlez la version dans Extensions installées et suivez les contrôles finaux. Ne désinstallez pas d’abord l’extension pour forcer le passage.

Actualiser un thème sans remplacer vos personnalisations

La même logique s’applique à un thème, avec une attention particulière au parent et à l’enfant. Le thème enfant contient souvent les adaptations ; il ne doit pas être remplacé par l’archive du parent. Une modification directement inscrite dans les fichiers du parent sera écrasée par sa mise à jour, quel que soit le mode de téléchargement.

Sur la copie préparée, conservez le thème installé et identifiez le nom exact de son dossier, son auteur et sa version. Préparez le ZIP installable officiel correspondant, ainsi que la sauvegarde de ses adaptations. Une simple capture de l’apparence ne sauvegarde pas les fichiers modifiés.

1. Ouvrez Apparence, Thèmes, Ajouter un thème, puis Téléverser un thème. Sélectionnez son ZIP et cliquez sur Installer maintenant.
2. Examinez la comparaison lorsque WordPress détecte le thème installé. Vérifiez produit, version et exigences affichées.
3. Confirmez le remplacement du thème correspondant. Ne changez pas le thème actif pour seulement terminer ce dépôt.
4. Contrôlez accueil, page intérieure et affichage mobile, puis menus et modèles utilisés. Si une adaptation disparaît, récupérez-la depuis sa copie ; ne réimportez pas toute la base sans nécessité.

Cas du cœur WordPress : réserver le remplacement manuel au bon contexte

Le cœur ne se téléverse pas par l’écran des extensions. Le parcours suivant concerne une installation standard autohébergée, avec accès SFTP autorisé, sauvegarde vérifiée, fenêtre de maintenance et version cible préparée sur une copie. Un déploiement géré, un réseau complexe ou un grand saut de versions demande son propre processus ; faites intervenir son responsable plutôt que mélanger deux méthodes.

1. Téléchargez le paquet WordPress officiel et extrayez-le sur votre ordinateur. Notez les extensions actives avant leur désactivation préparée.
2. Dans le dossier WordPress confirmé, remplacez entièrement les anciens dossiers wp-admin et wp-includes par ceux du paquet, afin de ne pas laisser de vieux fichiers.
3. Transférez les fichiers du cœur à la racine. Préservez wp-config.php, les règles propres au site et son contenu. Ne remplacez ni ne supprimez tout wp-content ; fusionnez seulement les éléments distribués nécessaires en préservant médias, thèmes et extensions existants.
4. Ouvrez /wp-admin sur le domaine prévu et suivez l’éventuelle mise à niveau de la base. Rétablissez les extensions selon leur état relevé et contrôlez le site avant réouverture.
5. Si le transfert reste incomplet, gardez l’intervention ouverte et restaurez un état cohérent selon la sauvegarde préparée ; ne combinez pas des fichiers de plusieurs versions au hasard.

Comparer les réponses dans une recette locale

La recette a appelé l’API HTTP de WordPress 7.1.4 depuis une copie. Un nom de test réservé qui ne se résout pas a produit l’erreur cURL **6**. Le serveur HTTPS sur la boucle locale a d’abord présenté un certificat absent du magasin de confiance utilisé. L’appel a produit cURL **60**. Le même serveur a ensuite répondu **200** à la demande de métadonnées lorsque son certificat de test a été fourni au client WordPress comme autorité de confiance de cette copie. La vérification TLS est restée active dans les deux essais.

Le proxy de test a reçu une demande CONNECT et renvoyé **407**. Le message WordPress a conservé ce refus du tunnel. Un autre hôte de test a été refusé avant transport par la politique HTTP de WordPress. Ces deux cas ne désignent pas la même règle à corriger. Le premier doit être examiné au niveau du proxy qui a répondu. Le second concerne la configuration qui détermine quels hôtes l’API HTTP de WordPress peut joindre.

Alors que les métadonnées étaient joignables, l’URL d’un paquet fictif a renvoyé **403**. La fonction native de téléchargement a enveloppé ce statut dans une erreur nommée http_404 dont les données donnaient bien **403**. Une autre URL locale a fourni l’archive témoin complète. La recette a vérifié son empreinte et retiré le fichier temporaire. Le test ne mesure pas la disponibilité du service WordPress.org. Il montre les différents signes à relever quand les erreurs apparaissent sur les chemins de la mise à jour.

Vérifier la réussite et organiser le retour arrière

Pour chaque paquet, vérifiez la version effectivement installée dans l’administration, puis la fonction qu’il fournit. Un bouton marqué terminé ne suffit pas à contrôler une intégration. Sur une boutique ou un site membre, préparez les vérifications de parcours sans déclencher d’opérations réelles involontaires. Comparez aussi les journaux privés de l’heure de l’intervention si un nouvel avertissement apparaît.

Le retour de wp-config.php à sa valeur initiale annule un réglage réseau, mais pas une mise à jour déjà appliquée. De même, remettre les anciens fichiers d’une extension ne remet pas forcément sa base dans son état précédent. Une migration de données peut nécessiter une restauration coordonnée ; préservez les ajouts récents avant toute remise en arrière.

Si le paquet local s’est installé alors que le téléchargement distant échoue encore, notez deux résultats séparés : version mise à jour, connexion à réparer. Ne fermez pas le second incident. Après réparation réseau, refaites le contrôle natif et vérifiez le prochain téléchargement nécessaire dans la fenêtre prévue, sans réinstaller un composant sain uniquement pour fabriquer un test.

Transmettre un relevé utile et éviter la récidive

Lorsque la couche en cause dépasse vos accès, demandez une intervention précise. Fournissez le domaine du site, son environnement, l’heure avec fuseau, le composant, les versions et l’étape en échec. Ajoutez le numéro cURL ou HTTP, le texte complet expurgé et les hôtes concernés. Distinguez le résultat obtenu depuis votre ordinateur de celui relevé sur l’hébergement.

Demandez au prestataire de vérifier la résolution DNS du serveur, le trajet sortant HTTPS, la politique du proxy et le magasin de confiance réellement utilisé par PHP. Pour un blocage confirmé, demandez la règle corrigée, sa portée et le résultat après modification. Aucun ticket ne doit contenir les secrets de wp-config.php, un identifiant de proxy ou une URL privée de licence.

Conservez enfin la cause et le changement appliqué avec leur date. Après une migration, contrôlez les paramètres hérités et les destinations nécessaires aux mises à jour. Gardez une copie des paquets officiels utilisés avec leur version, dans votre stockage privé. Cette trace permet de différencier une nouvelle panne d’un ancien réglage réintroduit, tout en maintenant un parcours de mise à jour vérifiable.