Dépannage WordPress
Erreur « Are you sure you want to do this? » dans WordPress
Ce message historique apparaît souvent lorsqu’une vérification de nonce échoue, mais il peut aussi masquer une action expirée, une session incohérente ou un upload dépassant une limite. Un nonce n’est ni un mot de passe ni une autorisation suffisante à lui seul.
Lire le conseilLe message « Are you sure you want to do this? » apparaît au moment où WordPress refuse de poursuivre une action. Selon la version et le composant, vous pouvez aussi lire « Le lien que vous avez suivi a expiré ». Ce refus ne désigne pas, à lui seul, une extension défectueuse ou un manque de mémoire.
Une cause possible est un contrôle de sécurité qui échoue : le formulaire ou le lien ne contient plus le jeton attendu, appelé nonce. Ce jeton accompagne une action et possède une validité limitée. Il aide à protéger les requêtes, mais ne remplace ni la connexion au compte ni la vérification de ses droits.
Reprendre une action restée ouverte sans perdre sa saisie
Un onglet d’administration ouvert depuis longtemps mérite d’abord un essai simple. Avant de recharger, conservez le texte saisi dans un emplacement privé adapté. Évitez de copier une page complète, son code source ou une URL contenant des informations de sécurité dans un message d’assistance.
- Vérifiez si l’action a déjà abouti : modification enregistrée, fichier présent ou tâche créée. Ne relancez pas une opération sensible sans ce contrôle, pour éviter un doublon.
- Retrouvez la page concernée depuis le menu habituel de l’administration, plutôt que depuis un ancien favori ou l’historique du navigateur.
- Si votre session a expiré, reconnectez-vous avec votre compte, puis rouvrez le formulaire. Ne poursuivez pas depuis un ancien onglet après cette reconnexion.
- Refaites une fois l’action autorisée. Si le refus revient, notez le message exact et l’étape qui le déclenche au lieu de multiplier les essais.
Si le nouvel essai fonctionne, vérifiez aussi que le résultat attendu a bien été enregistré. Une page qui se ferme ou un message qui disparaît ne suffit pas à confirmer l’enregistrement.
Une erreur répétée sur un seul écran demande un diagnostic ciblé
Précisez ce qui fonctionne encore : l’édition d’un autre article, l’accès aux réglages ou une autre action du même composant. Ce repère aide à distinguer une session vieillissante d’un formulaire particulier. Un problème sur une seule extension ne justifie pas de désactiver toutes les extensions du site public.
Vous pouvez comparer avec une nouvelle session dans une fenêtre privée, en autorisant les cookies nécessaires au site. Reprenez uniquement une action sans risque de doublon. Si elle fonctionne dans cette session, faites examiner les anciennes données de session et le chemin de connexion ; ce résultat ne prouve pas automatiquement que le cache est responsable.
Le responsable technique doit notamment vérifier qu’une page propre à un utilisateur connecté n’est pas servie depuis un cache partagé et que le formulaire transmet bien son jeton. Sur une copie de test, il peut isoler le composant concerné et contrôler un conflit ou une régression récente. Il faut conserver les réglages et une sauvegarde restaurable avant toute modification.
Si le refus survient pendant l’envoi d’un fichier
Notez le type et la taille du fichier, l’écran utilisé et le moment du refus. Un petit fichier autorisé peut servir de comparaison si cet envoi n’entraîne pas une publication ou un traitement métier non souhaité. Si le petit fichier passe et le gros échoue, cela donne une piste, pas encore une cause certaine.
PHP et le serveur peuvent imposer des limites différentes. Une requête trop volumineuse peut arriver sans les champs attendus ; augmenter uniquement la mémoire ne résout donc pas nécessairement le problème. Le responsable doit confronter la taille réelle aux limites d’envoi et de requête, puis consulter les erreurs du serveur ou du service intermédiaire.
Ne recopiez pas une série de valeurs dans la configuration au hasard. Une limite se règle au bon niveau, pour le besoin réel et après vérification des ressources disponibles. Le guide des erreurs d’envoi de fichiers WordPress détaille ce diagnostic distinct.
Corriger le contrôle et vérifier le résultat
Dans un formulaire développé sur mesure, le développeur doit faire correspondre la création et la vérification du jeton pour la même action et le bon champ. Il doit également vérifier les droits du compte et les données reçues côté serveur. Retirer le contrôle, accepter tous les jetons ou allonger leur validité pour masquer le refus peut laisser une action exposée.
La recette doit couvrir l’action normale avec le rôle prévu, puis les refus attendus : compte sans droit et requête avec un jeton absent ou invalide. Ces essais se font sur un environnement adapté, sans créer de commande, de paiement ou de publication réelle pour les besoins du test. Vérifiez ensuite le résultat enregistré, l’absence de doublon et le fonctionnement après une nouvelle connexion.
Si vous demandez un diagnostic WordPress, indiquez l’écran, l’action, l’heure approximative et un changement récent connu. Une capture du message peut aider si elle masque les informations privées. Ne joignez pas d’export de base, de mot de passe ou de requête contenant un jeton.