Sur cette page: [cacher]
WordPress imprime deux différents “les cookies sont bloqués” erreurs sur l'écran de connexion. La première signifie que votre navigateur a refusé un cookie. L’autre signifie que votre serveur a imprimé quelque chose avant que WordPress puisse en définir un. Ils sont séparés de onze lignes dans le même fichier principal. Ils ont besoin de réparations opposées, et presque tous les guides les traitent comme une seule erreur. La première chose à faire n'est donc pas de vider votre cache. C'est lire la phrase sur votre écran, mot pour mot.
Réponse rapide: Faites correspondre le texte d'erreur exact au correctif. “Les cookies sont bloqués ou ne sont pas pris en charge par votre navigateur” est votre navigateur, alors réessayez dans une fenêtre privée. “Les cookies sont bloqués en raison d'une sortie inattendue” est votre serveur, alors renommez le plugins dossier sur FTP. Une page blanche, ou “Il y a eu une erreur critique sur ce site Web”, n'est ni l'un ni l'autre. Vérifiez la boîte de réception de l'administrateur pour un e-mail en mode de récupération WordPress avant de toucher un fichier. Revenir sur le formulaire de connexion sans aucune erreur signifie généralement que l'URL de votre site a changé.
Dernière révision: septembre 2026. Chaînes d'erreur, les constantes des cookies et le comportement de hachage des mots de passe ont été lus à partir de la source principale de WordPress sur 8 septembre 2026. Versions du plugin, le nombre d'installations et les dates de sortie provenaient de l'API du plugin WordPress.org et des balises SVN le même jour.
Les fichiers d'où proviennent ces réponses
Les guides de connexion se copient, et les copies dérivent. Celui-ci a été construit en lisant le code qui produit les erreurs. Quatre fichiers principaux ont été extraits de la branche principale de WordPress le 8 septembre 2026:
- wp-login.php pour les chaînes d'erreur exactes et les conditions qui les déclenchent
- enfichable.php pour savoir comment les mots de passe sont vérifiés et comment les cookies de connexion sont définis
- constantes par défaut.php pour les noms des cookies et les valeurs par défaut de la mémoire
- utilisateur.php pour l'expiration de la clé de réinitialisation et la répétition qui s'exécute après une connexion réussie
Chaque comportement décrit ci-dessous remonte à l'un de ces quatre. Les chiffres du plugin proviennent de l'API d'informations sur le plugin WordPress.org. Les dates de sortie provenaient des en-têtes de balises SVN plutôt que des articles de blog du fournisseur. Un article de blog annonce une version; un en-tête de balise enregistre la date d'expédition.
Deux règles décident de ce qui entre. Tout correctif qui n'existe que dans le panneau de contrôle d'un hôte a été laissé de côté, puisque cela n'aide pas un lecteur sur un autre hôte. Toute astuce qui ne pouvait pas être attribuée à une ligne de source principale ou de plugin a également été laissée de côté., mais il apparaît souvent ailleurs.
Ce que ce guide n'a pas fait: exécuter ces échecs sur un site en direct en panne. Rien ici n'est un journal de réparation pratique. Le plus grand écart est la configuration du serveur. Les hôtes exécutent leurs propres règles de pare-feu devant WordPress. De l'extérieur, vous ne pouvez pas vérifier quelles requêtes un hôte bloque avant même que PHP ne se charge. Cette section nomme le symptôme et vous indique quoi demander à votre hôte, c'est ce que disent les preuves.
Commencez par ce que dit l’écran
Huit choses interrompent généralement les connexions WordPress. L'écran vous indique généralement lequel, si vous le lisez avant de chercher un correctif.
- Une erreur mentionnant les cookies, et vous êtes toujours sur le formulaire de connexion: le libellé divise cela en deux problèmes différents. Erreurs de cookies.
- Aucune erreur du tout, la page se recharge ou vous fait rebondir entre wp-login.php et wp-admin: la boucle de connexion.
- Une page blanche vierge, ou “Il y a eu une erreur critique sur ce site Web”: erreur fatale.
- Un verrouillage ou une invite 2FA tu ne peux pas passer outre: verrouillage du plugin.
- UNE 404 sur /wp-admin ou sur /wp-login.php: la page de connexion a été déplacée.
- Pas d'e-mail de réinitialisation, ou “le nom d'utilisateur n'est pas enregistré”: réinitialisez-le vous-même.
- UNE 403, 503 ou délai d'attente avant même que le formulaire ne se charge: le serveur, pas WordPress.
- Votre compte administrateur est manquant, ou il y a un utilisateur que vous n'avez pas créé: pas un bug.
Les deux erreurs de cookies qui signifient des choses opposées
Voici la partie qui décide de votre prochaine heure. Après avoir soumis le formulaire, core vérifie si le cookie connecté est revenu. Si ce n'était pas le cas, WordPress sélectionne l'un des deux messages sur la base d'un seul test: headers_sent().
PHP avait-il déjà envoyé une sortie lorsque WordPress avait essayé de définir le cookie? Ensuite tu obtiens “Les cookies sont bloqués en raison d'une sortie inattendue“. Il s'agit d'une erreur côté serveur, et votre navigateur est innocent. Quelque chose dans votre propre code imprimait des caractères avant la fin des en-têtes HTTP. En pratique, c'est l'une des trois choses suivantes. Une ligne vide après la clôture ?> dans le fichier function.php d'un thème. Un espace parasite en haut d'un fichier de plugin. Ou une marque d'ordre d'octet UTF-8, sauvegardé par un éditeur qui n'a jamais demandé.
La suppression des cookies ne fait rien ici. Il faut trouver le fichier qui parle trop tôt. Renommer /wp-content/plugins à plugins désactivés via FTP et rechargez la page de connexion. Si l'erreur disparaît, renommez le dossier et désactivez les plugins un par un jusqu'à ce qu'il revienne.
Si les en-têtes n’avaient pas été envoyés et que le cookie de test n’était tout simplement jamais revenu, vous obtenez “Les cookies sont bloqués ou non pris en charge par votre navigateur“. Celui-là est vraiment votre navigateur, ou quelque chose entre vous et le site. Essayez d'abord une fenêtre privée. Une fenêtre privée démarre sans aucun cookie et prend dix secondes. Si ça marche, effacez les cookies pour ce domaine dans votre profil normal et vous avez terminé. Si ce n'est pas le cas, regarde les extensions du navigateur, un VPN, ou filtrage réseau à votre bureau.
La distinction compte plus qu’il n’y paraît. L'erreur côté navigateur est corrigée en moins d'une minute sans aucun accès aux fichiers. L'erreur côté serveur nécessite FTP ou SSH et une recherche dans les fichiers du plugin, et la suppression du cache ne le déplacera jamais. Lire huit mots vous évite de faire le deuxième travail alors que vous aviez besoin du premier.
Utilisez cette section lorsque le mot “cookies” apparaît n'importe où sur l'écran. S'il n'y a aucun texte d'erreur, tu veux le boucle de connexion au lieu.
La boucle de connexion: Votre nom de cookie est un hachage de l'URL de votre site
Vous tapez le bon mot de passe, la page se recharge, et vous revenez sur le formulaire de connexion sans rien à lire. Aucune erreur, pas de verrouillage, aucune idée. Le mécanisme derrière cela est une ligne dans le noyau, et une fois que vous l'avez vu, la solution est évidente.
WordPress ne donne pas de nom fixe à votre cookie de connexion. Il construit le nom à partir d'une constante appelée COOKIEHASH, et COOKIEHASH est md5 de votre option siteurl. Le cookie d'authentification devient wordpress_ plus ce hachage. Le cookie connecté devient wordpress_logged_in_ plus le même hachage. Donc, au moment où votre siteurl change, WordPress commence à rechercher un cookie avec un nom différent de celui déjà présent dans votre navigateur. Il ne trouve rien, décide que vous n'êtes pas connecté, et vous renvoie au formulaire. Pour toujours.
Quatre changements déclenchent cela, et tous les quatre semblent inoffensifs à l'époque:
- Passer de http à https
- Ajouter ou supprimer le www
- Déplacer le site vers un nouveau domaine
- Ajout d'une barre oblique finale à l'un des deux champs URL
Boutiques WordPress siteurl et maison dans la table wp_options. Ils doivent correspondre exactement, personnage pour personnage. Vous ne pouvez pas résoudre ce problème dans le tableau de bord, parce que tu ne peux pas accéder au tableau de bord. Force the values in wp-config.php instead, just above the “arrêter l'édition” comment:
- définir( ‘WP_HOME’, «Https://exemple.com’ );
- définir( 'WP_SITEURL', «Https://exemple.com’ );
Pick the exact scheme and host you actually serve. These constants override the database rows without changing them, so they’re safe to try and trivial to undo. They also reach further than most guides admit. Core filters them into the siteurl option before it builds COOKIEHASH, so the constant fixes the cookie name too, not just the redirects. A trailing slash on the constant is harmless, because core strips it. A trailing slash in the database row is not.
Expect one side effect. Changing that value changes the cookie name for everybody, so every logged-in user gets signed out. That’s the fix working, not a second problem. Notre guide to editing wp-config.php safely covers where the file sits and what else belongs in it. Once you’re back in, set Settings > Général pour correspondre, puis supprimez les deux lignes.
Deux autres causes de boucle valent la peine de vérifier si les URL correspondent déjà. Un .htaccess corrompu peut réécrire les requêtes wp-admin dans un cercle. Renommez-le en .htaccess-ancien et réessaye; si la connexion fonctionne, WordPress en écrit un propre lorsque vous réenregistrez vos permaliens. Les sites derrière un proxy inverse ou un CDN ont un deuxième piège. FORCE_SSL_ADMIN vous fait rebondir entre http et https lorsque le proxy ne transmet pas l'en-tête du protocole.
Un symptôme ressemble à la boucle mais ne l’est pas: se connecter bien, puis je me suis fait expulser à nouveau une heure plus tard. WordPress définit le cookie d'authentification sur 2 journées, ou 14 les jours où tu coches “Souviens-toi de moi”. Sessions plus courtes que ce point sur un plugin de sécurité ou un cache d'objets, pas à cause d'une incompatibilité d'URL. Cela vaut la peine de savoir dans lequel vous vous trouvez, because the price gap is real. This fix is two lines in wp-config.php. The unexpected-output error costs you an FTP session and a plugin-by-plugin hunt.
This is your section if the loop began after a domain, SSL or URL change. Been on the same URL for a year, and the loop started after a plugin update? Un plugin is the likelier culprit.
Blank Page or “There Has Been a Critical Error”
Commencez par la bonne nouvelle, because a lot of people don’t know this exists. Depuis WordPress 5.2, a fatal error doesn’t just white-screen you. Core catches it, emails the site’s admin address, and that email carries a secret link into recovery mode. Click it and WordPress pauses the plugin or theme that crashed, for your browser only, and lets you into the dashboard to remove it. Visitors keep seeing the error page while you work. It’s the fastest fix on this list, and it needs no FTP at all.
So check that inbox before anything else, spam folder included. Two things break this for a lot of sites. The admin address is a mailbox nobody reads. Or the site can’t send mail in the first place. You can point future alerts somewhere better with définir( ‘RECOVERY_MODE_EMAIL’, ‘[email protected]’ ); in wp-config.php, though that only helps for the next crash. If no email ever arrives from your site, the real problem is deliverability. Notre répartition de why WordPress stops sending email covers the nine causes behind it.
Pas d'e-mail, no recovery link? Then find out what actually crashed. Ajouter définir( «WP_DEBUG», vrai ); et définir( «WP_DEBUG_LOG», vrai ); to wp-config.php, reload the login page, and read /wp-content/debug.log. The last few lines will name a file, and that file’s folder is your culprit. Renommez le dossier de ce plugin via FTP et WordPress le désactive au prochain chargement.
Si le journal pointe vers la mémoire plutôt que vers un plugin, les chiffres sont inférieurs à ce que les gens pensent. WordPress définit WP_MEMORY_LIMIT sur 40M par défaut, ou 64M en multisite, et élève le côté administrateur à 256M. Une pile de plugins lourde peut épuiser 40 M rien que pour la demande de connexion. Ajouter définir( «WP_MEMORY_LIMIT», «256 M’ ); est un test légitime. Traitez le résultat comme un diagnostic plutôt que comme un remède, parce que quelque chose consomme bien plus qu'il ne le devrait.
Un conseil populaire à ignorer. Les guides recommandent toujours le Plugin Bilan de santé pour isoler un conflit sans interrompre votre site en direct, et sur le papier c'est le bon outil. Sa dernière version était la version 1.7.1 sur 25 juillet 2024. Il déclare la compatibilité uniquement jusqu'à WordPress 6.6.7, et ça porte toujours 200,000 installations actives. C’est trois versions majeures de WordPress derrière, sur un plugin dont tout le travail consiste à manipuler les plugins chargés. Renommer un dossier via FTP est plus grossier et plus sûr.
Travaillez ici lorsque vous voyez une page d'erreur WordPress ou rien du tout. Un formulaire de connexion qui s'affiche correctement exclut cela, parce que PHP a répondu à la requête.
Votre plugin de sécurité vous a bloqué
Les outils qui protègent wp-login.php sont également les plus susceptibles de verrouiller la personne qui les a installés.. Connaissez l'échelle avant de supposer un bug principal. Wordfence est assis sur 5 millions de sites. Limiter les tentatives de connexion La sécurité et l'exécution de Loginizer sont activées 1 millions chacun, et Kadence Security sur 700,000. Sur une installation typique, l'un d'eux se situe entre vous et votre tableau de bord.
Ce qui soulève un problème de dénomination qui a dérouté les gens toute l'année. Vous recherchez Solid Security dans votre liste de plugins et vous ne le trouvez pas? Solid Security devient Kadence Security en version 10.0.0, marqué sur 12 Mai 2026, after Liquid Web retired the StellarWP brand. The plugin folder is still called better-wp-security, the name it carried as iThemes Security before that. Three brands, one folder.
The same version series carries a bug worth naming, because it causes exactly the failure this article is about. Kadence Security 10.0.1, marqué sur 12 Mai 2026, fixed a race condition in the plugin’s file writer that could empty wp-config.php or .htaccess. An empty wp-config.php doesn’t just lock you out of the login page. It takes down the whole site, database credentials and all. And it looks nothing like a plugin problem while you’re staring at it.
Recovery is the same for all of them, and it doesn’t require guessing a lockout table name. Connect over FTP or SSH, ouvert /wp-content/plugins/, and rename the offending folder, donc barrière de mots devient mot de clôture. WordPress ne trouve plus le fichier du plugin, le désactive silencieusement, et le lock-out va avec. S'identifier, renommer le dossier, puis reconfigurez avant de réactiver.
Les verrouillages à deux facteurs suivent le même chemin avec une longueur d'avance. Recherchez les codes de récupération qui vous ont été fournis lors de la configuration. Vérifiez d'abord votre gestionnaire de mots de passe, parce que c'est une solution de trente secondes contre une solution de cinq minutes. Aucun code? Renommer le dossier du plugin 2FA. Votre 2FA est-il regroupé dans une suite de sécurité plutôt que dans un plugin autonome? Renommer le dossier de la suite supprime le verrouillage et le deuxième facteur à la fois.
Commencez ici lorsque vous voyez un compte à rebours, un message de verrouillage ou une invite 2FA. Un mot de passe accepté avant le rechargement propre de la page est la boucle, pas un lock-out.
La page de connexion qui a déménagé
UNE 404 sur /wp-admin est un animal différent d'une connexion qui échoue. Rien ne s'est écrasé. La porte a été déplacée et personne n'a noté où.
WPS Masquer la connexion s'exécute sur 2 millions de sites et fait un seul travail. Cela change votre URL de connexion, donc les robots qui frappent /wp-login.php ne trouvent rien. Cela fonctionne bien jusqu'au jour où vous avez besoin de l'URL et ne vous en souvenez plus. (Ce jour semble toujours tomber un dimanche.) Le récupérer nécessite une seule recherche, parce que le plugin stocke le slug en texte brut. Ouvrez phpMyAdmin, aller au wp_options table, et recherchez option_name pour whl_page. La valeur dans cette ligne est votre slug de connexion. Votre URL de connexion est l'URL de votre site, une barre oblique, et cette valeur.
Je préfère ne pas toucher à la base de données? Renommer /wp-content/plugins/wps-hide-login/ via FTP restaure /wp-login.php immédiatement, comme n'importe quel autre plugin. La recherche dans la base de données est la meilleure option lorsque vous souhaitez récupérer l'URL plutôt que de supprimer le plugin.. Comparez cela avec les verrouillages de sécurité ci-dessus, où renommer le dossier est le correctif complet. Ici, c'est le plus brutal de deux choix.
Vérifiez également que personne n'a renommé wp-login.php lui-même, ou ajouté une règle .htaccess limitant wp-admin à une adresse IP fixe. Les listes d'autorisation IP sur wp-admin sont courantes sur les sites créés par les agences. Ils interrompent le jour où la connexion domestique du client obtient une nouvelle adresse.
Allez ici pour un 404 ou la page d'erreur de votre hébergeur au lieu d'un écran WordPress. Si le formulaire se charge, le fichier se trouve exactement là où WordPress l'attend, alors regarde ailleurs.
Réinitialiser le mot de passe lorsque l'e-mail n'arrive jamais
Le lien de réinitialisation a une durée de conservation à laquelle la plupart des gens ne s’attendent pas. WordPress fait expirer une clé de réinitialisation de mot de passe après 24 heures par défaut. Donc un lien dans votre boîte mail de la semaine dernière est mort. le “votre lien de réinitialisation de mot de passe a expiré” le message qui suit envoie les gens à la recherche d'un défaut qui n'existe pas. Demandez-en un nouveau d'abord.
Avant de toucher à la base de données pour tout ce qui suit, faire une sauvegarde. Il ne s'agit pas d'une sauvegarde de plugin dont vous supposez qu'elle existe, mais une copie réelle de la table wp_users que vous pouvez restaurer en une seule fois. Notre Guide de sauvegarde WordPress couvre le fait de faire cela correctement, et une exportation de base de données prend environ deux minutes dans phpMyAdmin.
Avec accès SSH, WP-CLI est la voie la plus rapide et celle à privilégier. Il passe par le propre hachage de WordPress plutôt que par son contournement. Courir administrateur de mise à jour utilisateur wp –user_pass=”votre-nouveau-mot de passe” depuis la racine du site, en remplaçant votre nom d'utilisateur. Cela fonctionne même si le tableau de bord est cassé, et il ne peut pas écrire un hachage mal formé.
Sans SSH, la route phpMyAdmin fonctionne toujours, et il y a un 2026 les autres guides se trompent dans les deux sens. Sur 15 avril 2025, WordPress 6.8 changement de hachage de mot de passe de phpass à bcrypt. Les mots de passe écrits après cette date portent un $wp$2ans$ préfixe au lieu de l'ancien $$$. Certains guides affirment désormais que l'astuce classique de phpMyAdmin est morte à cause de cela.. Ce n'est pas. La vérification du mot de passe de Core a toujours une branche pour tout hachage de 32 caractères ou moins, ce qui le compare à un simple MD5. L’ancienne routine fonctionne donc toujours sur WordPress 7.1. Modifier le user_pass rangée dans wp_users, choisissez MD5 dans la liste déroulante des fonctions, et tapez votre nouveau mot de passe.
Ce qui a changé, c'est ce qui se passe ensuite. Lors de votre première connexion réussie, core remarque que le hachage est obsolète et le réécrit discrètement en tant que bcrypt. Votre ligne MD5 existe pour exactement une connexion, puis se met à niveau. C'est le détail à retenir. Le hachage faible est une porte, pas un état dans lequel vous quittez votre site. Ne t'arrête pas à la porte: définir un vrai mot de passe pour les utilisateurs > Profil une fois à l’intérieur.
Votre section lorsque l'e-mail de réinitialisation n'arrive jamais, ou le compte lui-même semble sain. Les erreurs de cookies et les verrouillages ne se soucient pas de votre mot de passe, donc une réinitialisation ne corrige ni l'un ni l'autre.
Quand le bloc est votre serveur, Pas WordPress
Certains échecs de connexion n'atteignent jamais PHP. Si le formulaire ne se charge pas du tout, WordPress n'est pas impliqué. Il en va de même si le soumettre renvoie un nu 403 depuis votre hébergeur plutôt que depuis un écran WordPress. Aucun renommage de plugin n'aidera l'un ou l'autre.
La cause habituelle est une règle de pare-feu devant l'application. La plupart des hôtes partagés exécutent ModSecurity ou un équivalent, et un POST vers wp-login.php contenant un caractère inhabituel peut déclencher une règle générique. Vous verrez une plaine 403, parfois avec un identifiant de référence. Cet identifiant représente toute la conversation avec l'assistance: give it to them and ask which rule fired.
Caching is the second suspect. Server-level page caches are meant to exclude wp-login.php automatically. When that exclusion breaks, the login page gets served from cache with a stale nonce. It submits, and it fails silently.
One error belongs to neither list. “Erreur de connexion à la base de données” isn’t a login fault at all, because it shows on every page of the site. Check the credentials in wp-config.php, then ask your host whether the database server is up.
Then there’s the certificate, quietly becoming the more common one. Let’s Encrypt stopped sending expiry emails sur 4 juin 2025, so a renewal that fails now fails in silence. Chrome is closing the gap from the other side. Chrome 147 allumé “Utilisez toujours des connexions sécurisées” pour les utilisateurs de la navigation sécurisée améliorée en avril 2026. Chrome 154 makes it the default for everyone in October 2026. Un site avec un certificat mort cesse d'être un avertissement sur lequel vous pouvez cliquer et devient un mur. Votre page de connexion affiche-t-elle un écran de sécurité de navigateur plutôt que celui de WordPress ?? Notre procédure pas à pas de le “votre connexion n'est pas privée” Erreur sépare un mauvais certificat d'une mauvaise horloge d'appareil.
Un test vous indique sur quel côté travailler. Charger la page de connexion dans une fenêtre privée sur les données mobiles, hors de votre réseau domestique. Si ça charge là, le bloc est local pour vous: une interdiction IP, votre FAI, ou votre propre logiciel de sécurité. Si ça échoue là aussi, c'est le serveur, et c'est un ticket d'assistance plutôt qu'une modification de fichier.
Venez ici quand vous ne voyez jamais d'écran WordPress du tout. Une erreur formulée dans WordPress signifie que la requête a atteint PHP, alors travaillez plutôt les sections ci-dessus.
Quand ce n'est pas un bug
Parfois, rien n'est cassé et la connexion fonctionne exactement comme prévu. Ce n'est tout simplement plus conçu pour toi.
Trois signes pointent vers cette direction plutôt que vers n'importe quel correctif ci-dessus:
- Votre compte administrateur n'existe plus
- Il y a un administrateur dans la table des utilisateurs que vous n'avez pas créé
- Votre mot de passe a cessé de fonctionner sur tous les appareils au même moment
Un site compromis se comporte ainsi car l'attaquant a modifié les informations d'identification. La page de connexion continuera à vous rejeter poliment toute la journée.
L'écran de connexion lui-même a été une cible cette année. WordPress 7.0.3 corrigé CVE-2026-64638 sur 6 août 2026, une faille de script intersite de pré-authentification dans wp-login.php classée 8.9, avec des correctifs rétroportés via le 4.7 bifurquer. Il permet à un attaquant de créer une URL de connexion qui exécute JavaScript dans le navigateur d'un administrateur.. L'ouverture du lien était la seule interaction nécessaire, et les chercheurs ont démontré son lien avec l'exécution de PHP. Running an older build, with access that vanished for no reason? Check your patch level first, not last.
You can read the version without a dashboard. Ouvrir wp-includes/version.php over FTP and look at the $wp_version line on the same trip you’re already making. WordPress 7.1 is current as of September 2026. Note that the August fix was backported as far as 4.7.34, so an old major branch isn’t automatically unpatched. What matters is whether the site took its last minor update.
Regaining access is the easy half here, and it’s the half people stop at. Resetting the password gets you in; the attacker’s backdoor puts them back tomorrow. Une fois que vous êtes dedans, work through four steps in order:
- Update core and every plugin and theme
- Remove any administrator account you don’t recognize
- Change the salts in wp-config.php, qui force la déconnexion à chaque session
- Ensuite, lancez le nettoyage des logiciels malveillants
Si le site a été visiblement dégradé ou diffuse du spam, la restauration d'une sauvegarde connue et propre vaut mieux que le nettoyage manuel.
Lisez ceci lorsque l'accès a disparu sans mise à jour, aucun changement de configuration et aucune erreur. Tout ce que vous pouvez retracer à vos propres actions est l'un des sept problèmes les moins chers ci-dessus..
Quel correctif essayer en premier
Le bon ordre dépend de l'accès dont vous disposez et de ce que vous faisiez au moment de la panne.. Quatre situations en couvrent la plupart.
Mise à jour, écran blanc, pas de SSH. Vous avez cliqué sur Mettre à jour les plugins, le site est devenu blanc, et cPanel est tout ce que vous avez. Vérifiez d'abord la boîte de réception de l'administrateur pour l'e-mail du mode de récupération., parce qu'un clic vaut mieux qu'une chasse aux fichiers. Rien là? Dans le gestionnaire de fichiers, rebaptiser /wp-content/plugins à plugins désactivés, se connecter, renommez-le, puis réactivez un plugin à la fois jusqu'à ce qu'il se brise à nouveau. Don’t install Health Check to do this more elegantly. Its last update was July 2024, and it hasn’t been tested past WordPress 6.6.7.
Right password, silent bounce. No error message, straight back to the login form, and the site moved to HTTPS recently. Go directly to la boucle de connexion and set WP_HOME and WP_SITEURL in wp-config.php. Skip the cookie-clearing advice entirely. Your browser holds a cookie whose name no longer matches the md5 of your site URL. Clearing it just removes a cookie WordPress had already stopped looking for.
2FA lockout, SSH available. You wiped your phone and the authenticator went with it. Two commands and you’re done: wp plugin deactivate with the 2FA plugin’s slug, puis wp user update for a fresh password if you need one. This is where WP-CLI earns its place. Through phpMyAdmin, le même travail signifie trouver les bonnes lignes user_meta. Par FTP, cela signifie renommer les dossiers et espérer que vous avez choisi le bon.
La page ne se charge pas du tout. UNE 403 de votre hôte, ou un délai d'attente, et aucun écran WordPress nulle part. Rien dans wp-content n'aidera. Testez d'abord sur les données mobiles, pour exclure un blocage IP sur votre propre connexion. Envoyez ensuite à votre hôte l'horodatage et tout identifiant de référence du 403. Modifier des fichiers alors qu'une règle de serveur bloque la requête fait perdre l'après-midi.
Une habitude empêche la plupart des visites répétées: connaissez votre itinéraire avant d'en avoir besoin. Si vous avez SSH, confirmer que WP-CLI fonctionne réellement sur le site aujourd'hui. Si tu ne le fais pas, confirmez que vous pouvez accéder au gestionnaire de fichiers et à phpMyAdmin, et que l'email de l'administrateur est une boîte aux lettres que vous lisez. Découvrir que le courrier de récupération est envoyé à l'adresse d'un ancien développeur, while the site is down, is the worst possible timing.
Questions fréquemment posées
Pourquoi ma page de connexion WordPress continue-t-elle de s'actualiser sans erreur?
A silent refresh with no error text almost always means a cookie mismatch, not a wrong password. WordPress names its login cookie using an md5 of the siteurl option. Change the site URL (http to https, adding www, a new domain) and it looks for a cookie name your browser doesn’t have. Set WP_HOME and WP_SITEURL in wp-config.php to the exact URL you serve, with no trailing slash. A corrupted .htaccess produces the same symptom, so rename it to .htaccess-old if the constants don’t fix it.
Comment réinitialiser mon mot de passe administrateur WordPress dans phpMyAdmin?
Ouvrez phpMyAdmin, select your site’s database, and edit your username’s row in the wp_users table. Replace the value in user_pass, choose MD5 from the function dropdown beside the field, et économisez. Export the table first so you can undo it. Avec accès SSH, courir administrateur de mise à jour utilisateur wp –user_pass=”new-password” au lieu. WP-CLI écrit un hachage approprié et ne peut pas en produire un mal formé.
L'astuce du mot de passe MD5 fonctionne-t-elle toujours maintenant que WordPress utilise bcrypt?
Oui, sur WordPress 7.1 dès septembre 2026. WordPress 6.8 activé les nouveaux hachages de mot de passe sur bcrypt 15 avril 2025. La vérification du mot de passe dans le noyau traite toujours tout hachage de 32 caractères ou moins comme un simple MD5. Votre valeur MD5 vous permet d'entrer une fois, et core le réécrit ensuite sous forme de hachage bcrypt lors de cette première connexion réussie. Définissez quand même un mot de passe approprié à partir de votre profil.
Comment désactiver un plugin lorsque je ne parviens pas à me connecter à WordPress?
Connectez-vous via FTP, SFTP ou le gestionnaire de fichiers de votre hébergeur, puis renommez le dossier du plugin à l'intérieur /wp-content/plugins/. Tourner barrière de mots dans mot de clôture, par exemple. WordPress ne trouve pas le fichier du plugin, le désactive, et te laisse entrer. Pour tout désactiver d'un coup, renommer le tout plugins dossier à la place. Avec SSH, wp plugin deactivate –tout fait le même travail sans toucher à un nom de fichier.
Pourquoi WordPress me déconnecte-t-il après quelques jours?
C'est la valeur par défaut, pas une faute. WordPress définit le cookie d'authentification pour qu'il expire après 2 jours avec une connexion normale, et 14 les jours où tu coches “Souviens-toi de moi”. Déconnecté bien plus tôt que cela? Vérifiez trois choses: un plugin de sécurité raccourcissant la session, une inadéquation www et non-www, ou un cache d'objets supprimant les jetons de session.
Que dois-je faire si l’e-mail de réinitialisation du mot de passe WordPress n’arrive jamais?
Supposons que le site ne puisse pas du tout envoyer de courrier, plutôt que la réinitialisation est cassée. Les deux échecs semblent identiques sur l'écran de connexion. Réinitialisez le mot de passe directement avec WP-CLI ou phpMyAdmin pour revenir, puis corrigez la délivrabilité en acheminant le courrier via un service SMTP authentifié. Les liens de réinitialisation expirent également après 24 heures par défaut, donc un e-mail plus ancien dans votre boîte de réception échouera même s'il est arrivé.
Le plugin Health Check est-il toujours sûr pour résoudre un problème de connexion?
Ce n’est pas l’outil à utiliser 2026. Bilan de santé & Dépannage de la dernière version expédiée 1.7.1 sur 25 juillet 2024 et déclare la compatibilité uniquement jusqu'à WordPress 6.6.7, trois versions majeures en retard. Il a encore 200,000 installations actives et est toujours largement recommandé, which is why it keeps coming up. For isolating a plugin conflict while you’re locked out, renaming folders over FTP or running WP-CLI is simpler and current.
Revenir: La version courte
Read the error text before you touch anything, because the exact wording narrows eight possible failures to one. Cookie errors split into a browser fix and a server fix that share nothing but the word “cookies”. A silent loop is a site URL problem, solved in wp-config.php in two lines. A blank page means checking the admin inbox for a recovery mode link before you open an FTP client. A lockout means renaming a plugin folder. Everything else is either your server or an intrusion. A server block is a support ticket. An intrusion makes regaining access the start of the job, not the end.
Do one thing while the site is still working. Verify today that you can reach phpMyAdmin or WP-CLI, et que l'e-mail de l'administrateur atterrit quelque part que vous lisez réellement. Chaque correctif ci-dessus suppose qu'une de ces deux portes est ouverte.
Si votre crash remonte à quelque chose de plus large que l'écran de connexion, nous avons des guides pour les problèmes voisins. Une mise à jour bloquée laisse derrière elle le “brièvement indisponible pour la maintenance programmée” message, qui semble alarmant et s'efface en quelques secondes. Et si le même site continue de tomber en panne après des mises à jour de routine, l'hôte est souvent le facteur commun. Déménager à hébergement WordPress géré avec mise en scène et restaurations automatiques change les calculs. Une mise à jour interrompue devient une restauration de deux minutes au lieu d'un après-midi dans un client FTP.