Comprenez ce que WordPress vous empêche de faire
Vous lancez une mise à jour du cœur de WordPress et un message indique qu’une autre mise à jour est déjà en cours. Ce message peut apparaître alors que vous ne voyez aucune barre de progression. WordPress utilise un verrou pour éviter que deux opérations concurrentes ne remplacent les mêmes fichiers au même moment.
Le verrou peut correspondre à une opération réelle : un autre administrateur, une tâche automatique ou un outil de l’hébergeur travaille encore. Il peut aussi rester après l’interruption d’un traitement. Le dépannage consiste à distinguer ces situations avant de modifier quoi que ce soit.
Ce guide concerne le message de verrouillage de la mise à jour du cœur. Une extension ou un hébergeur peut employer une formulation proche pour son propre mécanisme. Vérifiez donc l’écran qui affiche le message et l’opération demandée. Ne supposez pas que tous les avertissements contenant les mots « mise à jour » utilisent la même entrée de base de données.
Si les visiteurs voient seulement une page de maintenance, le symptôme est différent. Le fichier .maintenance et le verrou de mise à jour ont des fonctions distinctes. Retirer le premier ne prouve pas que l’autre a disparu, ni que le remplacement des fichiers est terminé.
Approche 1 : laisser finir une opération réellement active
Ne relancez pas la mise à jour dans plusieurs onglets. Consultez l’écran qui avait démarré l’opération et les informations du panneau d’hébergement. Regardez si un traitement y est encore annoncé comme actif ou si un résultat final a été enregistré. Un navigateur qui a cessé d’afficher la progression ne garantit pas que le serveur a arrêté son travail.
Demandez aux autres administrateurs s’ils ont lancé une intervention. Si vous utilisez un service de gestion centralisée, consultez son historique pour ce site. Relevez l’heure de lancement et le résultat connu. L’objectif est de trouver qui contrôle l’opération en cours et d’éviter un second départ pendant la première.
Si l’hébergement confirme que le processus travaille encore, laissez-le terminer. En cas de durée inhabituelle, demandez au support de vérifier les journaux et l’état du traitement. Ne supprimez pas le verrou uniquement parce que votre propre attente semble longue.
Si une tâche doit être interrompue, utilisez le mécanisme prévu par son gestionnaire ou faites intervenir le prestataire. Tuer au hasard des processus PHP peut affecter d’autres requêtes et laisser des fichiers partiellement remplacés. Une interruption confirmée sera suivie d’un contrôle de l’installation avant toute nouvelle tentative.
Comprendre le délai du verrou sans le prendre pour une preuve d’arrêt
Dans le mécanisme actuel de mise à jour du cœur, WordPress demande un verrou avec une durée de quinze minutes. Cette durée sert à décider si une entrée existante doit encore être respectée lorsqu’une nouvelle tentative cherche à acquérir le verrou. Ce n’est pas une garantie que toute mise à jour se termine en quinze minutes.
Le mécanisme général de verrouillage accepte d’autres durées et utilise une heure par défaut lorsqu’aucune n’est fournie. Il faut donc examiner le verrou propre à l’opération, pas appliquer un délai universel à toutes les tâches WordPress.
Après confirmation qu’aucune mise à jour ne travaille encore, laissez passer le délai pertinent puis faites une seule nouvelle tentative. WordPress sait normalement reprendre un verrou expiré. Il n’est pas nécessaire de supprimer immédiatement une entrée simplement parce que vous l’avez repérée dans la base.
Si le blocage persiste, notez son heure et l’état du site. Une valeur future, une horloge incorrecte, un accès à la mauvaise base ou un autre mécanisme de verrouillage peut expliquer le résultat. Le fait que le message dure longtemps oriente le diagnostic ; il ne remplace pas la vérification de ces éléments.
Préparez les accès et une sauvegarde restaurable
Avant une intervention directe, identifiez la bonne installation : domaine, répertoire, base de données et environnement. Un compte d’hébergement peut contenir le site public, une copie de test et une ancienne migration. Un verrou supprimé dans la mauvaise base peut laisser le problème intact tout en modifiant un autre site.
Vérifiez la présence d’une sauvegarde récente des fichiers et de la base, ainsi que la manière de la restaurer. Une sauvegarde des seuls fichiers ne protège pas les articles, les réglages et les commandes enregistrés dans la base. Si une intervention précédente a déjà échoué, conservez aussi l’état actuel pour permettre une analyse.
Vous pouvez utiliser les sauvegardes de l’hébergeur, un export de base et une copie des fichiers. Gardez les exports dans un emplacement privé, hors du répertoire public. Un export SQL peut contenir des données personnelles et des informations techniques qui ne doivent pas être téléchargeables par les visiteurs.
Notez l’entrée exacte que vous allez examiner et sa valeur avant toute suppression. La sauvegarde protège contre une erreur de manipulation ; elle ne justifie pas une suppression large. Dans une boutique active, restaurer toute une ancienne base ferait aussi perdre les opérations récentes. La correction recherchée ici reste limitée au verrou identifié.
Approche 2 : examiner le verrou avec WP-CLI
Si WP-CLI est disponible et que vous possédez un accès SSH autorisé, placez-vous dans le répertoire du site concerné. Vérifiez d’abord l’adresse obtenue par WordPress, puis lisez l’option de verrouillage du cœur. Ces lectures ne lancent pas de mise à jour.
Le nom exact de l’option est core_updater.lock, avec un point. Sa valeur correspond à un instant exprimé en secondes depuis l’époque Unix. Ce n’est pas un identifiant d’utilisateur ni un numéro de processus. Conservez la valeur et faites-la comparer à l’heure du serveur si nécessaire.
Si la commande ne trouve pas l’option, ne la créez pas. Vérifiez l’installation sélectionnée et le mécanisme qui a produit le message. Une erreur de connexion à la base signifie que la lecture n’a pas abouti ; elle ne démontre pas l’absence du verrou. En multisite, faites confirmer le contexte concerné par l’administrateur du réseau.
wp option get home
wp option get core_updater.lockRetirer uniquement un verrou confirmé comme abandonné
N’utilisez la commande suivante qu’après avoir confirmé l’arrêt de l’opération, préparé la sauvegarde et vérifié que cette entrée correspond au blocage observé. Elle supprime une option précise au moyen de WordPress. Elle ne répare pas les fichiers, ne relance pas une mise à jour et ne supprime pas les autres verrous.
Lisez le résultat. Si l’option a déjà disparu, ne cherchez pas une autre entrée portant un nom ressemblant simplement pour obtenir un message de succès. Une tâche peut avoir terminé entre votre lecture et votre intervention. Actualisez l’écran et contrôlez l’état courant avant d’agir de nouveau.
Si le verrou réapparaît aussitôt, arrêtez les suppressions répétées et identifiez ce qui le recrée. Une tâche automatique ou un gestionnaire peut avoir repris l’opération. Supprimer continuellement son verrou ferait perdre la protection contre les interventions simultanées.
wp option delete core_updater.lockApproche 3 : retrouver l’entrée dans l’outil de base de données
Sans WP-CLI, l’outil fourni par l’hébergeur, souvent phpMyAdmin, permet d’examiner la base. Ouvrez-le depuis le compte client authentifié. Identifiez la base associée au site grâce à la configuration, sans publier les identifiants qu’elle contient.
Repérez la table des options. Son nom dépend du préfixe de l’installation : wp_options est courant, mais ce n’est pas une obligation. Sur un réseau ou une base contenant plusieurs copies, le bon préfixe et le bon site doivent être confirmés avant toute modification.
Dans la table choisie, recherchez une correspondance exacte de option_name avec core_updater.lock. Examinez la ligne retournée et conservez sa valeur. Une recherche portant seulement sur le mot « update » ramènerait des données sans rapport que vous n’avez pas besoin de modifier.
Si vous préférez une lecture SQL, l’exemple ci-dessous sélectionne cette seule option. Remplacez le nom de table par le nom vérifié. Il s’agit d’une lecture destinée à confirmer la ligne ; elle ne supprime rien. Si aucun résultat n’apparaît, revenez au diagnostic plutôt que de vider la table.
SELECT option_id, option_name, option_value
FROM wp_options
WHERE option_name = 'core_updater.lock';Supprimer la ligne ciblée, sans toucher aux autres options
Lorsque l’absence de processus actif et le caractère abandonné du verrou sont confirmés, utilisez l’action de suppression sur cette seule ligne. Lisez l’écran de confirmation et vérifiez le nom de la table, le nom de l’option et le nombre de lignes concernées. N’utilisez pas les fonctions Vider ou Supprimer la table.
Ne sélectionnez pas toutes les entrées terminées par .lock. Les mises à jour automatiques et d’autres composants peuvent employer leurs propres protections pour des opérations distinctes. Un nettoyage général des options n’est pas une réparation du verrou du cœur.
Une modification directe dans la base ne passe pas par les fonctions WordPress qui gèrent les caches d’options. Si un cache objet persistant conserve une ancienne valeur, faites réaliser une invalidation ciblée pour ce site par l’hébergeur, ou utilisez la méthode WP-CLI lorsque c’est possible. Évitez de vider un cache partagé entre plusieurs sites sans connaître sa portée.
Retournez ensuite dans le tableau de bord et relevez le nouvel état. Si le message reste identique, conservez ce résultat et faites vérifier le contexte de lecture. Répéter la même suppression dans plusieurs bases au hasard rendrait l’intervention plus risquée et plus difficile à comprendre.
Vérifier les fichiers avant de relancer une mise à jour interrompue
Le retrait du verrou ne garantit pas que le site est resté dans un état cohérent. Si la première tentative a été interrompue pendant la copie, vérifiez la version installée et les messages de l’opération. Une page d’accueil qui s’affiche ne prouve pas que tous les fichiers du cœur correspondent à la même version.
Avec WP-CLI, la commande de version fournit un repère, puis la vérification des sommes de contrôle compare les fichiers du cœur aux références de WordPress.org. Choisissez la version et la langue pertinentes lorsque l’outil le demande. Une comparaison contre une mauvaise version peut produire des différences sans expliquer la panne initiale.
Un contrôle satisfaisant concerne les fichiers examinés, pas les extensions, le contenu de la base ou toutes les fonctions du site. Une erreur réseau empêchant le téléchargement des références n’est pas une preuve de corruption. Ne désactivez pas la validation des certificats pour forcer le contrôle ; faites corriger le problème de connexion.
wp core version
wp core verify-checksumsRelancer une seule mise à jour par le parcours prévu
Une fois le verrou résolu et l’installation examinée, ouvrez Tableau de bord, puis Mises à jour. Vérifiez la version proposée et la compatibilité attendue avec votre environnement. Lancez une seule opération et laissez son écran terminer. Ne démarrez pas simultanément la même action depuis un outil d’hébergement ou un terminal.
Si vous utilisez habituellement WP-CLI, la mise à jour du cœur peut être réalisée avec son outil dédié après préparation. Choisissez un seul gestionnaire pour cette intervention. Les options de forçage et les changements de version précis ne sont pas nécessaires simplement parce qu’un verrou a été rencontré.
Si WordPress demande ensuite une mise à niveau de la base, suivez le parcours prévu avec une sauvegarde actuelle. Les fichiers du cœur et la structure de la base doivent rester cohérents. Sur multisite, la portée peut concerner plusieurs sites ; faites intervenir l’administrateur du réseau.
Si la nouvelle tentative échoue, conservez la première erreur utile : téléchargement refusé, espace insuffisant, permissions ou interruption du traitement. Le verrou peut n’être qu’une conséquence de cette panne. Corriger seulement sa présence ne suffit pas si la même cause interrompt chaque mise à jour.
Comprendre pourquoi le verrou revient
Comparez l’heure des échecs avec les tâches de l’hébergement et les interventions des administrateurs. Un gestionnaire externe peut lancer une mise à jour pendant qu’une personne utilise le bouton du tableau de bord. Établissez une responsabilité claire et évitez deux opérations sur les mêmes fichiers au même moment.
Demandez au prestataire de vérifier les ressources, le stockage et les journaux correspondant à la tentative. Un délai d’exécution, une connexion interrompue ou une impossibilité d’écrire un fichier demande une correction adaptée. Augmenter toutes les limites ou accorder des permissions très larges sans diagnostic peut créer d’autres difficultés.
Si l’horloge du serveur est incorrecte, faites la corriger au niveau du système. Le fuseau d’affichage choisi dans WordPress ne remplace pas cette correction. Conservez la valeur du verrou et l’heure observée afin que le support puisse comparer les deux.
Une extension qui propose de retirer le verrou en un clic n’établit pas automatiquement qu’il est abandonné. Elle ne remplace ni la vérification du processus ni l’analyse de l’échec précédent. Les outils natifs et ceux de l’hébergement suffisent pour ce dépannage lorsqu’ils sont utilisés sur la bonne installation.
Contrôler le site après la réussite
Vérifiez la version affichée dans l’administration et l’absence de message d’échec sur l’écran des mises à jour. Consultez les journaux ou le résultat de l’outil utilisé. Conservez cette preuve de fin plutôt que de considérer la disparition du verrou comme le seul critère de réussite.
Ouvrez quelques pages publiques et plusieurs écrans d’administration. Enregistrez un brouillon, vérifiez les médias et testez les fonctions essentielles du site selon un parcours prévu. Sur une boutique, utilisez les moyens de test appropriés sans déclencher un paiement réel uniquement pour cette vérification.
Si un message de maintenance subsiste, examinez-le comme un problème distinct après confirmation de la fin de la mise à jour. Ne supprimez pas des fichiers de protection pendant qu’un traitement pourrait encore les utiliser. Retirez aussi les réglages temporaires de diagnostic devenus inutiles.
Gardez une courte note indiquant la cause, le verrou concerné, la méthode utilisée et les contrôles réussis. Elle permettra de reconnaître un incident récurrent. Le dépannage est abouti lorsque la mise à jour se termine normalement et que le site fonctionne avec une installation cohérente, pas seulement lorsque le bouton de mise à jour redevient disponible.
