Identifier le déplacement qui a échoué
Une mise à jour manuelle d’extension s’arrête sur le message « Could not move the old version to the upgrade-temp-backup directory ». Dans le cas décrit sur le forum WordPress, une première mise à jour avait laissé un dossier temporaire. À l’essai suivant, l’extension a disparu de la liste alors que son répertoire restait visible chez l’hébergeur. Le fil rapporte plusieurs propriétaires de fichiers différents. Il ne permet pas de confirmer lequel a causé le refus. Le message identifie en revanche une opération précise et permet de vérifier les deux emplacements concernés.
Pour les mises à jour manuelles d’extensions et de thèmes, WordPress peut déplacer l’ancienne version dans un emplacement temporaire avant de mettre la nouvelle en place. Pour une extension en dossier, la destination ordinaire suit le modèle wp-content/upgrade-temp-backup/plugins/nom-du-dossier. La source se trouve dans le dossier des extensions de l’installation. Les deux chemins peuvent différer des valeurs habituelles sur un site qui personnalise ses dossiers ou délègue les mises à jour à l’hébergeur. Si l’installation du paquet échoue après la mise de côté, le cœur peut tenter de remettre les anciens fichiers. Cette copie temporaire sert à cette opération et sa présence ne constitue pas une garantie de restauration complète.
Distinguez les messages qui se ressemblent. « Could not create the upgrade-temp-backup directory » désigne la création du dossier. « Could not move the old version » désigne le mouvement entre la source et la destination. Un message d’échec de restauration désigne le retour depuis la copie temporaire. Chacun peut concerner des droits ou un quota différents. L’état de la base mérite un contrôle séparé. Un rétablissement des fichiers ne rejoue pas à lui seul une migration de données qu’une nouvelle version aurait déjà lancée.
- Notez l’heure, le nom exact de l’extension, les versions visibles et le message complet. Vérifiez si une mise à jour est encore active dans le tableau de bord ou chez l’hébergeur.
- Après la fin de l’opération, relevez l’état de l’extension dans Extensions > Extensions installées. En multisite, contrôlez aussi l’écran Extensions de l’administration du réseau si l’extension y est gérée.
- Demandez une copie des deux dossiers s’ils existent avant de relancer. Le cœur peut essayer de supprimer le répertoire temporaire de la même extension avant un nouveau déplacement. Une nouvelle tentative peut donc effacer un indice ou la seule copie encore complète.
Vérifier ce qui fonctionne encore avant de réessayer
Si le site est accessible, ouvrez une fonction contrôlable de l’extension depuis une session adaptée. Pour une extension de formulaire, chargez par exemple la page de recette qui la contient et vérifiez qu’un formulaire fictif peut s’ouvrir. Pour une extension qui gère un écran d’administration, ouvrez cet écran avec le compte prévu. Notez la version et le statut sur l’écran Extensions. Une extension inactive et une extension absente appellent des vérifications différentes. Un dossier visible chez l’hébergeur ne suffit pas à confirmer qu’il contient le fichier principal avec son en-tête et que les fichiers attendus sont lisibles.
Si le site répond mais qu’une fonction importante a disparu, rétablissez en priorité une version connue sur une copie isolée. Demandez une sauvegarde qui permet de retrouver le répertoire exact de l’extension ainsi que l’état de la base à la date de la mise à jour. L’objectif de ce contrôle est de savoir si les deux emplacements contiennent une version complète et laquelle était réellement utilisée. Un répertoire partiel peut mélanger des fichiers de versions différentes. Comparer le seul numéro lu dans un fichier principal ne suffit pas à l’écarter.
Évitez de supprimer l’extension depuis l’interface pour récupérer un dossier propre. Une désinstallation peut exécuter un traitement qui retire des données. Séparez la copie de sécurité, le rétablissement des fichiers et la réactivation. Si l’extension était active sur le réseau, le résultat se mesure aussi sur un sous-site témoin. Avec un hébergement qui gère les extensions par déploiement, vérifiez quel outil est censé écrire ces fichiers. Une règle d’écriture délibérée appelle le flux de déploiement prévu.
- Notez l’état avant intervention. Relevez la version affichée, l’activation locale ou réseau et une fonction que vous pourrez retester.
- Conservez une sauvegarde des fichiers et une référence à la sauvegarde de la base. Ne réutilisez pas un dossier temporaire dont la provenance et la version sont incertaines.
- Si le site est instable, évitez une deuxième mise à jour pendant le diagnostic. Préparez la restauration ciblée ou demandez à l’hébergeur de préserver les deux dossiers et les journaux associés.
Utiliser le tableau de bord et Santé du site
Cette voie convient à un administrateur qui peut ouvrir le tableau de bord et dispose d’une recette, même sans terminal. Ouvrez Outils > Santé du site > État et cherchez les contrôles sur l’espace disponible pour les mises à jour et l’accès en écriture au dossier des sauvegardes temporaires. Notez le résultat avant correction. Le test général peut détecter que le parent n’est pas accessible ou que le disque est trop rempli. Un résultat favorable ne prouve pas que le sous-répertoire de cette extension peut être déplacé ou nettoyé par le mécanisme utilisé lors de la mise à jour.
Dans Extensions > Extensions installées, identifiez le seul composant à tester. Sur la copie, assurez-vous que la version de départ et le mécanisme de mise à jour correspondent au cas observé. Une copie hébergée ailleurs peut donner des permissions différentes. Si vous ne pouvez pas reproduire les droits, utilisez la copie pour vérifier l’état des fichiers et le retour arrière, puis demandez la vérification du mouvement sur l’environnement d’origine. Pour une extension dont la mise à jour utilise un paquet privé, conservez le même canal de distribution que celui prévu par son éditeur.
Après correction de l’espace ou de l’accès par le responsable de l’hébergement, relancez une seule mise à jour manuelle depuis la recette. Notez la première étape qui change. Si WordPress propose un identifiant FTP, signalez ce fait. Il peut employer un autre mode d’accès aux fichiers que celui que vous aviez supposé. Si la copie revient à l’ancienne version après l’échec, vérifiez le numéro et la fonction témoin. Si le message d’échec change, conservez le nouveau texte. Un refus de déplacement résolu peut révéler un problème différent plus loin dans la mise à jour.
- Relevez les contrôles de Santé du site et le statut de l’extension. Transmettez l’heure, le chemin de l’extension et le message exact au responsable de l’hébergement.
- Une fois la correction confirmée, lancez une seule mise à jour en recette. Conservez le résultat et ouvrez la fonction témoin.
- Si l’essai échoue encore au déplacement, passez à la comparaison des chemins. Si la recette fonctionne mais pas l’environnement d’origine, demandez une comparaison des deux mécanismes d’accès aux fichiers.
Comparer les emplacements avec SFTP ou SSH
Avec SFTP ou le gestionnaire de fichiers, ouvrez la racine du WordPress concerné puis le dossier des extensions. Notez l’emplacement exact de l’extension et vérifiez qu’un fichier principal reconnaissable se trouve au bon niveau. Comparez ensuite le dossier du même nom sous upgrade-temp-backup/plugins s’il existe. Relevez les dates, les propriétaires et les droits affichés pour les deux répertoires et leurs parents. Vérifiez également s’il s’agit d’un lien symbolique ou d’un volume monté. Un répertoire temporaire qui persiste peut avoir une autre origine que la dernière opération. Sauvegardez-le à part avant de le déplacer ou de demander son retrait.
Avec un terminal Linux, le bloc ci-dessous liste les chemins ciblés et l’espace du volume de contenu. Remplacez le chemin de recette et le nom du dossier. Si le dossier des extensions a été déplacé, remplacez également la valeur de plugins. df -h renseigne sur l’espace du volume et df -i sur le nombre d’entrées du système de fichiers disponibles. Un quota propre au compte peut être plus bas que ce que montre le volume. Demandez à l’hébergeur de le confirmer. Si les deux dossiers résident sur des montages distincts, interrogez aussi le volume de la source. La commande ne teste aucun déplacement.
Comparez ensuite l’identité de l’utilisateur du terminal à celle du mécanisme qui effectue la mise à jour. Des droits suffisants en SSH ou SFTP n’impliquent pas que PHP ou le compte FTP utilisé par WordPress puisse modifier les deux parents. Demandez au responsable de vérifier ce point pour le domaine, le processus et la méthode de fichiers concernés. L’opération peut échouer sur le déplacement d’origine ou sur le traitement d’une destination déjà présente. Un journal système peut préciser l’étape et l’erreur. Évitez d’appliquer un propriétaire ou un mode récursif à tout le site. Faites corriger le seul répertoire ou la règle qui empêche le mouvement autorisé et conservez les valeurs précédentes.
content='/srv/recette/wordpress/wp-content'
plugins="$content/plugins"
dossier='extension-temoin'
for chemin in "$plugins" "$plugins/$dossier" \
"$content/upgrade-temp-backup" "$content/upgrade-temp-backup/plugins" \
"$content/upgrade-temp-backup/plugins/$dossier"; do
if [ -e "$chemin" ] || [ -L "$chemin" ]; then
ls -ld -- "$chemin"
else
printf 'Absent ou inaccessible %s\n' "$chemin"
fi
done
df -h -- "$content"
df -i -- "$content"Rétablir une version complète si l’extension ne s’affiche plus
Si WordPress ne reconnaît plus l’extension après l’incident, récupérez la version exacte qui fonctionnait à partir d’une sauvegarde vérifiée ou du canal de distribution prévu. Vérifiez dans un dossier privé que le paquet contient bien le répertoire de l’extension et son fichier principal au niveau attendu. Si une archive ajoute un dossier d’emballage autour de l’extension, retirez ce niveau dans la copie de préparation. Gardez séparément l’état présent et la sauvegarde temporaire. Ne recopiez pas les fichiers d’une archive par-dessus un mélange dont vous ignorez le contenu. Sur la recette, préparez le dossier complet de la version choisie et faites-le remettre à la place attendue par la méthode de gestion du site.
Une extension qui redevient visible peut rester inactive. Vérifiez d’abord qu’elle est compatible avec le PHP et le WordPress de la recette et que ses réglages sont encore présents. Réactivez-la uniquement avec la portée qu’elle avait avant, locale ou réseau. Contrôlez une fonction concrète après l’activation. Pour un formulaire, vérifiez l’ouverture et une soumission fictive capturée. Pour un composant qui expose une page, vérifiez la réponse publique et l’écran d’administration associé. Consultez le journal après ces actions, car le chargement du fichier principal peut réussir alors qu’une dépendance manque.
Avant de remettre un dossier de sauvegarde, faites une comparaison avec un paquet de référence de la même version. Vérifiez le nom du répertoire, la présence du fichier principal et la liste des fichiers attendus. En SSH, une empreinte calculée avec sha256sum sur le fichier principal peut montrer que les deux copies diffèrent. Une empreinte identique sur ce seul fichier ne valide pas les dépendances. Si le paquet de l’éditeur contient des fichiers personnalisés installés par votre équipe, repérez-les et vérifiez comment ils sont maintenus avant de les recopier. Pour un paquet tiers ou payant, utilisez la source prévue par votre contrat ou votre équipe. Une archive trouvée dans un ancien dossier de téléchargement ne permet pas de vérifier son origine.
Si les fichiers sont revenus mais que les données ne correspondent plus, comparez avec la sauvegarde de base sur une copie séparée. Une version plus récente peut avoir modifié la structure de ses tables ou ses options. Dans ce cas, la remise d’un ancien dossier peut ne pas suffire. Suivez la procédure du mainteneur avant toute restauration de base. Une restauration complète peut effacer des écritures créées depuis la sauvegarde. Documentez le périmètre et vérifiez la reprise sur la copie avant de décider de la méthode pour le site concerné.
- Vérifiez le paquet et mettez de côté les dossiers existants. Remettez sur la copie un seul dossier complet à l’emplacement prévu.
- Confirmez la version dans la liste et vérifiez la fonction témoin. Si les journaux signalent un problème de données, suspendez la réactivation et vérifiez la compatibilité du couple fichiers et base.
- Si la tentative ne rétablit pas le service sur la copie, remettez les fichiers conservés avant cet essai ou revenez à l’instantané cohérent de recette. Gardez les deux états pour la comparaison.
Vérifier un passage complet et la mise à jour suivante
Une correction aboutie produit une nouvelle version visible dans la liste, maintient l’état d’activation attendu et permet à la fonction témoin de fonctionner. Après la fin de l’opération, vérifiez que le dossier temporaire de cette extension n’a pas été laissé dans un état ambigu. Le dossier parent peut rester présent ou contenir les restes d’une autre opération. Contrôlez la cible précise et le journal. Si la version est restée ancienne après un échec ultérieur, comparez son contenu et son fonctionnement à l’état initial pour vérifier la remise des fichiers.
Quand un dossier persiste après une mise à jour annoncée comme réussie, notez sa taille, son horodatage et le nom exact du dossier. Comparez ces indices au journal de l’opération avant de conclure que WordPress n’a pas nettoyé sa copie. L’ancien dossier peut provenir d’une tentative interrompue ou avoir été déposé par un outil de l’hébergement. Faites conserver une copie hors de l’arborescence de travail et vérifiez avec le responsable si le processus a terminé avant de traiter le reliquat.
Le forum rapporte un échec au second passage. Si deux versions de test successives sont disponibles sur la recette, vérifiez une nouvelle mise à jour après la première. Sinon, restaurez la copie d’essai depuis son instantané et rejouez la même mise à jour, puis notez la limite de cette comparaison. Le résultat attendu est un déplacement et un nettoyage cohérents sans changement de propriétaire imprévu. Conservez l’heure et les deux chemins pour que l’hébergeur puisse faire correspondre le test aux événements du système. Si un changement de droits a réglé le déplacement mais dégradé une autre fonction, restaurez la règle précédente et reprenez la comparaison avec un périmètre plus étroit.
