Le WordPress d'aujourd'hui, décodé pour les développeurs

Erreurs WordPress · Connexion et administration

Cookies bloqués à la connexion WordPress : causes et solutions

Connexion

« Les cookies sont bloqués ou ne sont pas reconnus par votre navigateur » : causes (URL, cache, sortie parasite) et correctifs pour vous reconnecter.

Message affiché

Erreur : les cookies sont bloqués ou ne sont pas reconnus par votre navigateur. Vous devez activer les cookies pour utiliser WordPress.

En anglais : Error: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.

Réponse rapide

WordPress n’a pas retrouvé son cookie de test au moment de la connexion. Cause n°1 : un navigateur qui bloque les cookies, ou une adresse (http/https, www) différente entre l’affichage du formulaire et son envoi. Testez en navigation privée.

Vous saisissez le bon identifiant et le bon mot de passe sur wp-login.php, et la page se recharge avec un bandeau rouge : « Erreur : les cookies sont bloqués ou ne sont pas reconnus par votre navigateur. Vous devez activer les cookies pour utiliser WordPress. » Parfois, le message est un peu différent : « les cookies sont bloqués en raison d’un retour inattendu ». L’erreur n’apparaît que sur la page de connexion, jamais sur le site public, mais elle vous empêche d’entrer dans l’administration.

Elle ne dit pas toujours la vérité : votre navigateur accepte souvent très bien les cookies. Dans la majorité des cas, WordPress n’a pas pu poser ou relire son cookie de test, à cause d’une adresse qui change en route, d’un cache, ou d’un fichier PHP qui a affiché du texte trop tôt. Voici comment distinguer ces situations et vous reconnecter.

Ce que signifie cette erreur

À chaque affichage du formulaire, wp-login.php envoie au navigateur un cookie de test nommé wordpress_test_cookie (constante TEST_COOKIE, définie dans wp-includes/default-constants.php) avec la valeur « WP Cookie check ». Le cookie est posé pour le chemin COOKIEPATH et le domaine COOKIE_DOMAIN (vide par défaut, donc limité à l’hôte exact), avec l’attribut « secure » si l’URL de connexion est en HTTPS. Le formulaire contient aussi un champ caché testcookie.

À l’envoi du formulaire, WordPress vérifie d’abord vos identifiants (wp_signon()), puis, tant que le cookie de session LOGGED_IN_COOKIE n’est pas présent dans la requête, il applique deux contrôles dans wp-login.php :

  • si des en-têtes HTTP ont déjà été envoyés (headers_sent()), les cookies de connexion ne peuvent plus être posés : WordPress affiche le message « les cookies sont bloqués en raison d’un retour inattendu » ;
  • si le champ testcookie est présent mais que le cookie de test n’est pas revenu avec la requête, il affiche le message « les cookies sont bloqués ou ne sont pas reconnus par votre navigateur ».

Dans les deux cas, la connexion est refusée même avec un mot de passe correct. Le texte vient de WordPress, pas du navigateur : il est affiché par le cœur, quel que soit le navigateur utilisé.

Diagnostic rapide

Symptôme / constatCause probableÀ vérifier
L’erreur disparaît en navigation privée ou avec un autre navigateurExtension de navigateur, réglage de confidentialité ou cookies obsolètesCookies du site, bloqueurs de publicité, paramètres du navigateur
Le message parle d’un « retour inattendu »Du texte ou un espace a été envoyé avant les en-têtes (BOM, ligne vide, notice PHP)Début de wp-config.php, functions.php, extensions ; journal d’erreurs
Vous arrivez sur le formulaire par http:// ou sans www, alors que le site est en HTTPS ou avec wwwCookie posé pour un hôte ou un schéma, formulaire envoyé vers un autresiteurl et home, redirections, constantes WP_HOME et WP_SITEURL
Le cookie de test n’apparaît pas dans les en-têtes de wp-login.phpCache de page, CDN ou proxy qui retire Set-CookieRègles d’exclusion du cache pour wp-login.php et wp-admin
Le problème est apparu après un changement de domaine ou une migrationConstante COOKIE_DOMAIN ou adresses du site incohérenteswp-config.php, réglages Général, base de données

Les causes les plus fréquentes

  1. Des adresses incohérentes : le formulaire est affiché sur http://exemple.fr, envoyé vers https://www.exemple.fr, et le cookie de test, lié à un autre hôte ou marqué « secure », ne revient pas.
  2. Du contenu envoyé avant les en-têtes : un BOM UTF-8, une ligne vide avant <?php ou après un ?> final, un echo oublié, une notice ou un avertissement PHP affiché à l’écran.
  3. Un cache de page, un CDN ou un proxy qui met en cache wp-login.php ou supprime l’en-tête Set-Cookie.
  4. Un navigateur ou une extension de navigateur qui bloque les cookies du site (réglages de confidentialité, mode strict, bloqueur de traqueurs).
  5. Une constante COOKIE_DOMAIN, COOKIEPATH ou COOKIEHASH mal renseignée dans wp-config.php, souvent héritée d’un ancien domaine.
  6. Une extension de sécurité ou de connexion personnalisée qui modifie la page de connexion ou les cookies.

Solutions pas à pas

1. Tester en navigation privée et vider les cookies

À essayer en premier : ouvrez une fenêtre de navigation privée sans extension et connectez-vous. Si cela fonctionne, supprimez les cookies du site (ou tous les cookies si nécessaire) dans les réglages du navigateur, désactivez ponctuellement vos bloqueurs de publicité, puis réessayez. Vérifiez aussi que votre navigateur n’est pas réglé pour refuser les cookies tiers ou tous les cookies. WordPress renvoie vers sa documentation officielle, qui détaille l’activation des cookies navigateur par navigateur.

2. Utiliser la bonne adresse, de bout en bout

Saisissez l’adresse exacte du site, avec son schéma et son nom d’hôte définitifs (par exemple https://www.exemple.fr/wp-login.php). Si l’erreur disparaît, le problème est une redirection manquante ou des adresses incohérentes. Contrôlez les deux réglages en base :

wp option get siteurl
wp option get home

Les deux doivent utiliser le même schéma et le même hôte que celui visé par vos visiteurs. Si vous n’avez plus accès à l’administration, vous pouvez les imposer dans wp-config.php, avant la ligne « That’s all, stop editing! » :

define( 'WP_HOME', 'https://www.exemple.fr' );
define( 'WP_SITEURL', 'https://www.exemple.fr' );

Ces constantes remplacent les valeurs enregistrées en base. Ajoutez ensuite, si ce n’est pas fait, une redirection vers l’adresse canonique côté serveur, comme expliqué dans notre fiche sur les boucles de redirection, et corrigez les ressources en HTTP avec la fiche sur le contenu mixte et le passage en HTTPS.

3. Supprimer toute sortie avant les en-têtes

À appliquer si le message mentionne un « retour inattendu », ou si vous venez de modifier un fichier PHP. Activez la journalisation sans affichage dans wp-config.php pour repérer le fichier fautif :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Consultez ensuite wp-content/debug.log : une ligne « Cannot modify header information – headers already sent by (output started at …) » donne le fichier et la ligne qui ont produit la sortie. La fiche headers already sent détaille cette erreur. Quelques contrôles rapides en ligne de commande :

head -c 3 wp-config.php | xxd        # "efbbbf" = BOM UTF-8 à supprimer
tail -c 30 wp-config.php | xxd      # un ?> suivi de lignes vides est une cause classique

Enregistrez le fichier en « UTF-8 sans BOM », supprimez les ?> de fin de fichier et les lignes vides avant <?php. Notre article sur la ligne vide avant <?php dans functions.php montre le cas typique, et celui sur l’encodage fautif d’un fichier .mo une cause moins évidente. Désactivez ensuite le débogage.

4. Exclure la connexion du cache

Vérifiez que le cookie de test est bien envoyé :

curl -sI https://www.exemple.fr/wp-login.php | grep -i set-cookie

Vous devez voir une ligne wordpress_test_cookie=WP%20Cookie%20check. Si elle manque, une couche de cache la supprime. Excluez wp-login.php et /wp-admin/ de votre extension de cache, de votre CDN et de votre cache serveur. Exemple pour un cache FastCGI nginx :

set $skip_cache 0;
if ($request_uri ~* "/wp-login.php|/wp-admin/") {
    set $skip_cache 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

Sous Apache avec un cache de page en PHP, l’exclusion se configure dans l’extension elle-même. Purgez ensuite tous les caches. L’article sur les pages jamais mises en cache à cause d’un cookie explique comment les cookies interagissent avec le cache de page.

5. Contrôler les constantes de cookie

Ouvrez wp-config.php et cherchez COOKIE_DOMAIN, COOKIEPATH, SITECOOKIEPATH et COOKIEHASH. Sur un site classique, aucune n’est nécessaire : WordPress les calcule à partir de l’adresse du site. Une valeur laissée par un ancien domaine empêche le navigateur de renvoyer le cookie. Commentez la ligne concernée, rechargez la page de connexion et réessayez. Sur un multisite en sous-domaines, COOKIE_DOMAIN est géré par le cœur (wp-includes/ms-default-constants.php) ; ne la redéfinissez que si vous savez pourquoi.

6. Désactiver les extensions sans accès à l’administration

Si rien ne change, une extension perturbe peut-être la connexion. Par SFTP, renommez le dossier wp-content/plugins en plugins_off, tentez la connexion, puis remettez le nom d’origine et réactivez les extensions une à une. Avec WP-CLI :

wp plugin deactivate --all
# après la connexion, réactivez une par une :
wp plugin activate nom-de-l-extension

Notez la liste des extensions actives avant de tout désactiver (wp plugin list --status=active).

Prévenir l’erreur

  • Fixez une adresse canonique unique (HTTPS, avec ou sans www) et redirigez tout le reste vers elle côté serveur.
  • N’ajoutez jamais de ?> de fermeture en fin de fichier PHP et enregistrez vos fichiers en UTF-8 sans BOM.
  • Excluez systématiquement wp-login.php et /wp-admin/ de tous les niveaux de cache, y compris CDN.
  • Après une migration, vérifiez siteurl, home et les constantes de cookie de wp-config.php.
  • Gardez le débogage en journal, sans affichage à l’écran, pour qu’un avertissement PHP ne casse pas les en-têtes.

FAQ

Mon navigateur accepte pourtant les cookies, pourquoi ce message ?

Parce que WordPress teste son propre cookie de test. Il peut manquer à cause d’une adresse qui change (http/https, www), d’un cache qui supprime Set-Cookie ou d’une sortie PHP envoyée trop tôt. Essayez d’abord en navigation privée, puis contrôlez les adresses du site.

Que signifie « les cookies sont bloqués en raison d’un retour inattendu » ?

Du contenu (espace, BOM, message d’erreur PHP) a été envoyé avant les en-têtes HTTP. WordPress ne peut alors plus poser les cookies de connexion. Le fichier fautif est indiqué dans le journal de débogage, sur la ligne « headers already sent by ».

L’erreur est apparue juste après une migration, que faire ?

Vérifiez siteurl et home (wp option get siteurl), supprimez toute constante COOKIE_DOMAIN héritée de l’ancien domaine et contrôlez que le formulaire de connexion est servi sur l’adresse définitive.

Dois-je définir COOKIE_DOMAIN dans wp-config.php ?

Rarement. Par défaut, la constante est vide et WordPress limite le cookie à l’hôte courant, ce qui convient à un site classique. Ne la définissez que pour partager la session entre sous-domaines, et avec la valeur exacte du domaine.