Accès wp-admin bloqué : comment le rétablir vite

by | WordPress

Si vous tombez sur un “Erreur 500” ou un écran blanc dès que vous ouvrez /wp-admin, le plus frustrant, c’est de ne plus avoir accès aux réglages… donc aux outils qui permettraient de réparer. La bonne nouvelle : dans WordPress 6.9.4 (avril 2026), on peut presque toujours récupérer l’accès sans toucher au cœur (core) et sans “tout casser”.

Le problème

Le souci typique : vous essayez d’ouvrir https://votresite.tld/wp-admin/ (ou /wp-login.php) et vous obtenez une erreur, une redirection infinie, ou une page blanche.

Exemples de messages réellement vus côté navigateur / serveur :

# Navigateur
ERR_TOO_MANY_REDIRECTS

# Serveur (page blanche ou 500)
500 Internal Server Error

# WordPress (parfois visible)
Il y a eu une erreur critique sur ce site.

# PHP (dans les logs)
PHP Fatal error:  Uncaught Error: Call to undefined function ...
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted ...

Quand et où ça apparaît :

  • Admin uniquement : le front-office marche, mais /wp-admin affiche une erreur (souvent un plugin d’admin, un module de sécurité, ou un problème de cookies/SSL).
  • Admin + front : tout le site est KO (souvent une erreur fatale PHP, un thème cassé, ou un problème serveur).
  • Après un changement : mise à jour de plugin/thème, activation d’un snippet, migration, passage HTTPS, changement de PHP, ajout d’un plugin de cache/sécurité.

À qui s’adresse ce guide : si vous êtes blogueur·se débutant·e (ou intermédiaire) et que vous avez accès au FTP/SFTP, au panneau d’hébergement, ou à WP‑CLI, vous pourrez :

  • isoler la cause (plugin, thème, snippet, cache, serveur) ;
  • réactiver l’accès à wp-admin ;
  • corriger proprement, sans “bidouilles” dangereuses.

Résumé rapide

  • Commencez par désactiver les plugins sans wp-admin (renommer le dossier wp-content/plugins ou un plugin précis).
  • Passez temporairement sur un thème par défaut (renommer le dossier du thème actif) pour éliminer un thème cassé.
  • Activez les logs (WP_DEBUG + debug.log) pour voir l’erreur exacte.
  • Vérifiez l’URL du site (home/siteurl) et l’HTTPS pour stopper les redirections infinies.
  • Réparez les règles de réécriture (.htaccess / Nginx) si wp-login.php renvoie 404/403.
  • Si vous êtes bloqué : utilisez Health Check (mode dépannage), WP‑CLI, ou contactez l’hébergeur avec les logs.

Les symptômes

Voici les symptômes les plus fréquents quand wp-admin devient inaccessible. Je les liste volontairement “visuel d’abord”, parce que c’est comme ça que vous allez les rencontrer.

  • Erreur 500 / “Internal Server Error” en allant sur /wp-admin.
  • Page blanche (White Screen of Death) sur /wp-admin ou /wp-login.php.
  • “Il y a eu une erreur critique sur ce site” (souvent une erreur fatale PHP).
  • Redirection infinie (ERR_TOO_MANY_REDIRECTS) entre /wp-admin et /wp-login.php, ou HTTP ↔ HTTPS.
  • 403 Forbidden sur /wp-admin (règles serveur/WAF, permissions fichiers, plugin de sécurité).
  • 404 Not Found sur /wp-admin ou /wp-login.php (réécriture, cache, configuration Nginx/Apache).
  • Écran de login qui recharge en boucle (cookies, domaine, SSL, plugin de sécurité, cache agressif).
  • Admin partiellement cassée : menus vides, erreurs REST API, erreurs AJAX (souvent un plugin, un blocage JS, ou un WAF).

Tableau de diagnostic rapide (utile si vous voulez aller vite) :

Symptôme Cause probable Vérification Solution
Erreur 500 Erreur fatale PHP / mémoire / plugin Consulter debug.log ou logs serveur Solution 1 puis 2
Page blanche Fatal error masquée / cache Activer WP_DEBUG, désactiver cache Solution 2
Redirections infinies HTTPS mal configuré / URL site incorrecte Vérifier home, siteurl, règles proxy Solution 3
403 sur /wp-admin WAF/hébergement / plugin sécurité / permissions Désactiver plugin sécurité, vérifier permissions Solution 1 + “Si ça ne marche toujours pas”
404 sur wp-login.php Rewrite / cache / règle serveur Tester accès direct, vérifier .htaccess/Nginx Solution 3

Pourquoi ça arrive

Explication simple (débutants)

wp-admin n’est pas une “page” isolée : c’est un ensemble de scripts PHP qui chargent WordPress, puis chargent vos plugins, puis votre thème, puis exécutent des hooks (des “points d’accroche”). Si un plugin, un thème, ou un snippet provoque une erreur fatale, l’admin tombe avant même d’afficher quoi que ce soit.

Autre classique : la connexion. Si WordPress pense que votre site est en HTTP alors que vous forcez HTTPS (ou l’inverse), il peut entrer dans une boucle de redirections et vous ne verrez jamais l’écran de login.

Explication technique (intermédiaires / pros)

En coulisses, wp-admin passe par wp-admin/admin.php, charge wp-load.php, puis le bootstrap WordPress. Les plugins sont chargés via wp-settings.php. Un “Fatal error” n’est pas récupérable par WordPress : PHP stoppe l’exécution. Le “WSOD” est souvent un fatal error avec display_errors désactivé (ce qui est normal en production).

Les causes, du plus fréquent au plus rare (dans mon expérience de dépannage) :

  1. Plugin (cache, sécurité, builder, SEO) qui casse l’admin après une mise à jour.
  2. Snippet ajouté dans functions.php (ou plugin de snippets) avec une erreur de syntaxe (point-virgule oublié) ou un hook inadapté.
  3. Thème (souvent un thème enfant) qui déclenche une erreur PHP sous PHP 8.1+.
  4. URL site / HTTPS / proxy mal configuré : boucles de redirection, cookies invalides.
  5. Règles serveur : .htaccess cassé, règle Nginx manquante, WAF qui bloque wp-login.php.
  6. Ressources : mémoire PHP insuffisante, disque plein, inode saturé.
  7. Base de données : corruption de tables, options incohérentes (plus rare, mais ça arrive après une migration ratée).

Prérequis avant de commencer

Sauvegardez avant de modifier quoi que ce soit. Si vous ne pouvez pas sauvegarder via l’admin, faites au minimum :

  • une copie des fichiers (FTP/SFTP) ;
  • un export de la base (phpMyAdmin, Adminer, ou backup hébergeur).

Préparez aussi :

  • WordPress 6.9.4 (vous l’avez) et PHP 8.1+ recommandé. Si votre hébergeur est en PHP 7.4/8.0, vous êtes sur une zone à bugs (et à risques sécurité).
  • Accès SFTP/FTP ou gestionnaire de fichiers (cPanel, Plesk, etc.).
  • Accès aux logs (error_log Apache/Nginx, ou logs PHP).

Outils utiles (facultatifs mais très pratiques) :

Rappel sécurité : ne modifiez jamais les fichiers du core WordPress. Tout ce qui suit se passe dans wp-content, la config (wp-config.php) ou au niveau serveur.

Solution 1 : Désactiver un plugin ou le thème sans wp-admin (méthode “sûre”)

Quand wp-admin est inaccessible, 7 fois sur 10 le coupable est un plugin (souvent cache/sécurité/builder) ou un thème enfant. L’objectif : relancer WordPress avec le minimum, puis réactiver progressivement.

Où agir

  • Via SFTP/FTP : dossier wp-content/
  • Ou via le gestionnaire de fichiers de votre hébergeur

Étape A — Désactiver tous les plugins (sans perdre de données)

Renommez le dossier :

  • wp-content/plugins → wp-content/plugins.OFF

Ensuite, testez :

  • /wp-admin/
  • /wp-login.php

Si l’admin revient, vous avez la preuve que c’est un plugin. Remettez le dossier à son nom d’origine, puis désactivez un plugin à la fois.

Étape B — Désactiver un plugin précis

Dans wp-content/plugins/, renommez le dossier du plugin suspect, par exemple :

  • wp-content/plugins/mon-plugin-cache → wp-content/plugins/mon-plugin-cache.OFF

J’ai souvent vu des blocages admin après mise à jour sur des plugins de cache qui minifient aussi l’admin, ou des plugins de sécurité qui ajoutent des règles agressives.

Étape C — Basculer sur un thème par défaut

Si désactiver les plugins ne change rien, testez le thème. Renommez le dossier du thème actif (souvent un thème enfant) :

  • wp-content/themes/mon-theme-enfant → wp-content/themes/mon-theme-enfant.OFF

WordPress va tenter de charger un autre thème disponible. Idéalement, gardez toujours un thème standard installé (Twenty Twenty-Five ou équivalent). Si aucun thème valide n’est disponible, vous aurez une erreur de thème manquant.

Exemple AVANT / APRÈS : snippet cassé dans functions.php

Cas typique : un code copié-collé dans functions.php du thème enfant, avec une erreur de syntaxe. Résultat : fatal error, admin inaccessible.

AVANT (cassé) — point-virgule manquant :

<?php
// functions.php (thème enfant)
// ERREUR : point-virgule manquant, provoque une erreur fatale
add_action('init', function () {
    update_option('blogdescription', 'Mon blog')
});

APRÈS (corrigé) — syntaxe valide :

<?php
// functions.php (thème enfant)
// Correction : ajout du point-virgule
add_action('init', function () {
    update_option('blogdescription', 'Mon blog');
});

Pourquoi ça corrige : PHP ne “pardonne” pas les erreurs de syntaxe. Un seul caractère manquant stoppe tout chargement, y compris wp-admin.

Compatibilité Divi 5 / Elementor / Avada

Ces builders ajoutent beaucoup de code côté admin. Si vous avez activé/ mis à jour Divi 5, Elementor ou Avada juste avant le crash :

  • Désactivez d’abord leurs addons (packs de widgets, optimisations, “mega menu”, etc.). Ils cassent plus souvent que le plugin principal.
  • Si nécessaire, désactivez temporairement le builder lui-même via renommage de dossier (méthode ci-dessus). Vos pages ne sont pas supprimées : vous perdez seulement l’édition builder le temps du dépannage.

Solution 2 : Identifier et corriger une erreur fatale PHP (WP_DEBUG + logs)

Quand vous avez une page blanche ou une 500, votre meilleur allié, ce sont les logs. Sans l’erreur exacte, on tourne en rond.

Où agir

  • Fichier wp-config.php à la racine de WordPress (même niveau que wp-settings.php).

Activer le log WordPress (sans afficher les erreurs aux visiteurs)

Ajoutez (ou modifiez) ces constantes dans wp-config.php, idéalement juste avant la ligne “That’s all, stop editing!” :

<?php
// wp-config.php
// Sauvegardez avant de modifier. Une erreur ici peut bloquer tout le site.

// Active le mode debug
define('WP_DEBUG', true);

// Écrit les erreurs dans wp-content/debug.log
define('WP_DEBUG_LOG', true);

// Évite d'afficher les erreurs à l'écran (plus sûr en production)
define('WP_DEBUG_DISPLAY', false);

// Optionnel : forcer l'option PHP display_errors à off
@ini_set('display_errors', '0');

Ensuite, rechargez /wp-admin une fois. Puis ouvrez :

  • wp-content/debug.log

Documentation officielle : https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/

Lire les erreurs les plus fréquentes (et quoi faire)

1) “Call to undefined function …”

Ça arrive quand un plugin/thème appelle une fonction qui n’existe pas (version trop ancienne, mauvais hook, ou dépendance non chargée).

Exemple de log :

PHP Fatal error:  Uncaught Error: Call to undefined function ma_fonction_magique()
in /wp-content/plugins/mon-plugin/mon-plugin.php:42

Action :

  • Désactivez le plugin fautif (Solution 1).
  • Mettez-le à jour via FTP (remplacer le dossier par la dernière version) si vous êtes certain de la source.
  • Si c’est votre code, corrigez le hook (voir l’exemple plus bas).

2) “Allowed memory size exhausted”

Souvent déclenché par un builder, un plugin de stats, ou une génération d’images. L’admin charge plus de choses que le front, donc elle “tombe” en premier.

Exemple :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)

Correctif (propre) : augmentez la mémoire côté hébergement (PHP memory_limit). En dépannage, vous pouvez aussi définir :

<?php
// wp-config.php
// Dépannage : augmente la limite mémoire WordPress (si le serveur l'autorise)
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Si votre hébergeur bloque, ça ne suffira pas. Référence : https://developer.wordpress.org/apis/wp-config-php/#increasing-memory-allocated-to-php

3) Erreur de syntaxe (Parse error)

C’est le cas “j’ai collé un snippet” : une parenthèse ou un point-virgule manquant. Là, vous devez corriger le fichier indiqué dans le log (souvent functions.php ou un plugin de snippets).

Exemple :

PHP Parse error: syntax error, unexpected token "}" in /wp-content/themes/mon-theme-enfant/functions.php on line 123

Action :

  • Ouvrez le fichier, allez à la ligne, corrigez la syntaxe.
  • Si vous ne trouvez pas, renommez le thème (Solution 1) pour récupérer l’admin, puis corrigez à froid.

Exemple AVANT / APRÈS : mauvais hook (fonction appelée trop tôt)

Définition rapide : un hook est un point d’accroche dans WordPress. Une action exécute du code à un moment donné. Un filtre modifie une valeur et la retourne.

Erreur fréquente : appeler une fonction qui dépend de l’admin (ou d’un plugin) trop tôt, par exemple au chargement du fichier, sans attendre un hook adapté.

AVANT (fragile) — exécution immédiate :

<?php
// mu-plugin ou functions.php
// Problème : ce code s'exécute dès l'inclusion du fichier.
// Si WordPress n'est pas complètement chargé, ça peut casser.
wp_redirect(admin_url());
exit;

APRÈS (correct) — exécution au bon moment, et uniquement sur le front :

<?php
// functions.php (thème enfant) ou plugin custom
// Correction : on attend le hook template_redirect, et on évite l'admin.
add_action('template_redirect', function () {
    if (is_admin()) {
        return;
    }

    // Exemple : rediriger uniquement si l'utilisateur est connecté
    if (is_user_logged_in()) {
        wp_safe_redirect(admin_url());
        exit;
    }
});

Pourquoi ça corrige : template_redirect se déclenche après que WordPress a résolu la requête. Et wp_safe_redirect() limite les redirections aux hôtes autorisés (plus sûr).

Solution 3 : Réparer l’URL de connexion, les règles de réécriture et l’accès serveur (WP‑CLI / .htaccess)

Si vous avez une boucle de redirections, un 404/403 sur wp-login.php, ou un /wp-admin qui renvoie vers une mauvaise URL, le problème est souvent : URL du site, HTTPS, proxy/CDN, ou règles de réécriture.

Cas A — Redirections infinies après passage en HTTPS (ou derrière Cloudflare / proxy)

J’ai souvent croisé ce cas après activation d’un plugin “Force SSL” ou après une migration vers un hébergeur avec reverse proxy. WordPress croit être en HTTP, mais le navigateur est en HTTPS, donc ça boucle.

Vérifier/corriger home & siteurl

Si vous avez accès à la base (phpMyAdmin), regardez dans la table wp_options :

  • home
  • siteurl

Les deux doivent correspondre (même domaine, même schéma http/https). Exemple attendu :

  • https://votresite.tld

Si vous avez WP‑CLI, c’est plus propre (et réversible) :

# Vérifier
wp option get home
wp option get siteurl

# Corriger (adaptez le domaine)
wp option update home 'https://votresite.tld'
wp option update siteurl 'https://votresite.tld'

Référence WP‑CLI (officiel) : https://developer.wordpress.org/cli/commands/option/

Si vous êtes derrière un proxy (HTTPS terminé en amont)

Dans ce cas, WordPress peut ne pas détecter HTTPS correctement. Un correctif courant consiste à s’assurer que $_SERVER['HTTPS'] est bien défini quand le proxy envoie l’en-tête X-Forwarded-Proto.

Où mettre ce code : dans wp-config.php, très tôt (après <?php), avant que WordPress ne charge tout.

<?php
// wp-config.php
// Dépannage proxy : forcer la détection HTTPS si le proxy indique https.
// À utiliser seulement si vous êtes réellement derrière un reverse proxy/CDN.
if (
    isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'
) {
    $_SERVER['HTTPS'] = 'on';
}

Risques : si vous forcez HTTPS alors que votre site n’est pas servi en HTTPS, vous allez créer des redirections/cookies cassés. Testez prudemment.

Cas B — 404 sur wp-admin / wp-login.php (réécriture cassée)

Sur Apache, un .htaccess corrompu ou une règle ajoutée par un plugin peut empêcher l’accès aux fichiers.

Réparer .htaccess (Apache)

Où agir : fichier .htaccess à la racine du site (même niveau que wp-config.php).

Test simple : renommez temporairement .htaccess en .htaccess.OFF, puis testez /wp-login.php. Si ça revient, le problème est dedans.

Exemple de .htaccess WordPress standard (à adapter si votre hébergeur impose des règles) :

# .htaccess (Apache)
# Sauvegardez avant de modifier.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Référence : https://developer.wordpress.org/advanced-administration/server/web-server/apache/

Cas C — 403 Forbidden (WAF, permissions, règle serveur)

Un 403 sur /wp-admin est très souvent externe à WordPress : pare-feu applicatif (WAF), ModSecurity, règles anti-bot, ou permissions de fichiers.

Vérifications rapides :

  • Désactivez temporairement le plugin de sécurité (Solution 1).
  • Regardez si votre hébergeur a un “WAF” activé (cPanel/Cloudflare) et testez en le désactivant 2 minutes.
  • Vérifiez les permissions : en général 755 pour dossiers, 644 pour fichiers (ça varie selon l’hébergement, donc évitez les 777).

Référence PHP (pour comprendre les erreurs fatales et le comportement) : https://www.php.net/manual/en/errorfunc.configuration.php

Vérifications après correction

Une fois que /wp-admin réaffiche l’écran de login (ou le tableau de bord), ne vous arrêtez pas là. Vérifiez que le site est stable.

  • Test 1 : connexion + navigation dans 3 pages d’admin (Articles, Extensions, Réglages).
  • Test 2 : ouvrir le front-office en navigation privée.
  • Test 3 : vérifier la médiathèque (upload d’une image) si vous suspectez un souci mémoire/droits.
  • Test 4 : si vous avez eu une boucle HTTPS, vérifiez que les URL sont correctes dans Réglages > Général.
  • Test 5 : si c’était un plugin, réactivez-les un par un en testant /wp-admin entre chaque.

Si vous aviez activé WP_DEBUG, gardez WP_DEBUG_LOG un moment, mais remettez WP_DEBUG à false après dépannage sur un site en production.

Si ça ne marche toujours pas

Ici, on passe en mode procédure. Suivez l’ordre : il est conçu pour éliminer les causes les plus probables sans empirer la situation.

  1. Videz les caches :
    • cache navigateur (testez en navigation privée) ;
    • cache CDN (Cloudflare) ;
    • cache serveur (LiteSpeed, Nginx FastCGI cache) ;
    • cache plugin (si vous l’avez désactivé, supprimez temporairement son cache dans wp-content si nécessaire).
  2. Désactivez tous les plugins + thème (Solution 1), puis retestez.
  3. Activez les logs (Solution 2) et lisez wp-content/debug.log.
  4. Consultez les logs serveur (souvent plus précis que debug.log) :
    • Apache/Nginx error log
    • PHP-FPM log
  5. Vérifiez l’espace disque : un disque plein peut provoquer 500, sessions/cookies cassés, uploads impossibles.
  6. Vérifiez la version PHP : passez en PHP 8.1+ si possible. Certains vieux plugins cassent en PHP 8.x : dans ce cas, la désactivation ciblée est la bonne approche.
  7. Testez sans .htaccess (Apache) ou vérifiez la config Nginx si vous êtes sur Nginx (Solution 3).
  8. Testez Health Check en mode dépannage si vous avez encore accès à l’admin sur un autre compte/une autre URL (rare mais possible). Le mode dépannage n’affecte que votre session.
  9. Si vous avez WP‑CLI :
    • listez les plugins actifs : wp plugin list --status=active
    • désactivez tout : wp plugin deactivate --all
    • passez sur un thème standard : wp theme activate twentytwentyfive (si installé)

Si vous suspectez une corruption base de données (messages “database error”, admin qui boucle sans log PHP), vérifiez l’état via l’hébergeur. Évitez les “réparations” au hasard sur la base sans sauvegarde.

Pièges et erreurs courantes

Ce sont les erreurs que je vois le plus chez les débutants quand ils tentent de récupérer l’accès.

Symptôme Cause probable Solution recommandée
Le site ne marche plus après modification de wp-config.php Code collé au mauvais endroit / guillemets typographiques Revenir en arrière, coller uniquement des guillemets simples ' et vérifier la syntaxe
Impossible de désactiver un plugin (il “revient”) Cache objet persistant / mu-plugin qui réactive / gestion centralisée Vérifier wp-content/mu-plugins et désactiver via renommage dossier
Admin OK mais pages builder cassées Builder désactivé temporairement Réactiver le builder après avoir corrigé la cause initiale, puis purger les caches
Redirection infinie Mismatch HTTP/HTTPS ou home/siteurl Corriger options via WP‑CLI / base de données, puis vérifier proxy
Erreur critique après avoir copié un snippet Parenthèse/point-virgule oublié, ou hook inadapté Corriger le fichier indiqué dans debug.log ou désactiver thème/snippet
404 sur wp-login.php Règle serveur / plugin sécurité / rewrite cassée Tester sans .htaccess, corriger règles, désactiver WAF/plugin

Erreurs “bêtes” mais fréquentes :

  • Copier le code au mauvais endroit : un snippet destiné à functions.php collé dans wp-config.php peut casser tout le site.
  • Oublier de vider le cache et croire que “ça ne marche pas”.
  • Tester en production sans sauvegarde : la seule fois où ça tourne mal, ça tombe pendant un pic de trafic.
  • Utiliser un vieux tutoriel : j’en vois encore qui recommandent des hacks obsolètes, ou des fonctions retirées de plugins. En 2026, visez WordPress 6.9.4+ et PHP 8.1+.

Variante / alternative

Méthode sans code : mode dépannage (si vous arrivez à vous connecter)

Si vous parvenez à afficher wp-login.php et à vous connecter, mais que l’admin casse ensuite, le plugin Health Check est redoutable : il permet de désactiver plugins/thème uniquement pour votre session.

Avantage : vos visiteurs ne voient aucune coupure pendant que vous testez.

Méthode avancée : mu-plugin “panic button” (à utiliser avec prudence)

Un mu-plugin (Must-Use Plugin) est un plugin chargé automatiquement depuis wp-content/mu-plugins. C’est pratique pour un “bouton panique” temporaire quand l’admin est instable.

Objectif : forcer la désactivation de certains plugins connus pour casser l’admin, uniquement si vous ajoutez un paramètre secret dans l’URL. Attention : c’est puissant, donc à retirer après usage.

Où créer le fichier : wp-content/mu-plugins/panic-admin.php (créez le dossier mu-plugins s’il n’existe pas).

<?php
/**
 * Plugin Name: Panic Admin (temporaire)
 * Description: Désactive temporairement des plugins si un paramètre secret est présent.
 * Author: Dépannage local
 *
 * ATTENTION : à supprimer après usage. Ne laissez pas un "backdoor" traîner.
 */

if (!defined('ABSPATH')) {
    exit;
}

// Changez ce jeton (ne laissez pas "1234")
$token = 'changez-moi-avec-un-long-jeton';

if (!isset($_GET['panic']) || !hash_equals($token, (string) $_GET['panic'])) {
    return;
}

// Liste de dossiers de plugins à désactiver (adaptez à votre cas)
$plugins_a_desactiver = array(
    'mon-plugin-cache/mon-plugin-cache.php',
    'mon-plugin-securite/mon-plugin-securite.php',
);

// On attend que WordPress ait chargé les fonctions de plugins
add_action('plugins_loaded', function () use ($plugins_a_desactiver) {
    if (!function_exists('deactivate_plugins')) {
        return;
    }

    // Désactive pour cette requête (et met à jour l'option active_plugins)
    deactivate_plugins($plugins_a_desactiver, true);

    // Message minimal dans les logs si WP_DEBUG_LOG est actif
    if (defined('WP_DEBUG_LOG') && WP_DEBUG_LOG) {
        error_log('[panic-admin] Plugins désactivés temporairement via jeton URL.');
    }
}, 1);

Pourquoi ça peut aider : si votre admin plante avant que vous puissiez désactiver un plugin, ce mu-plugin peut “reprendre la main” suffisamment tôt pour vous laisser entrer.

Risques :

  • Si le jeton fuite, quelqu’un pourrait désactiver vos plugins (impact fonctionnel). Retirez ce fichier dès que l’accès est récupéré.
  • Si le plugin cassant est un mu-plugin, cette méthode ne l’empêchera pas (les mu-plugins sont chargés avant).

Éviter ce problème à l’avenir

Les blocages wp-admin reviennent souvent sur les mêmes sites : beaucoup de plugins, snippets copiés-collés, mises à jour en production, et pas de logs.

  • Gardez un thème par défaut installé (utile pour basculer en cas de thème enfant cassé).
  • Évitez de coller du code dans le thème : créez un petit plugin custom (ou un mu-plugin) pour vos snippets. Ça survit aux changements de thème.
  • Faites les mises à jour par lots :
    • 1 plugin à la fois sur les sites sensibles
    • test rapide admin/front après chaque update
  • Activez un monitoring d’erreurs : au minimum, gardez la possibilité d’accéder aux logs PHP.
  • Évitez les plugins de cache qui touchent l’admin (minification admin, regroupement agressif). Si vous le faites, testez sur staging.

Si vous avez un staging (environnement de test), utilisez-le. Même un clone temporaire chez l’hébergeur évite 80% des sueurs froides.

Ressources

Questions fréquentes

Je peux ouvrir le site, mais pas /wp-admin. C’est forcément un plugin ?

Très souvent oui, mais pas uniquement. Ça peut aussi être un plugin de sécurité/WAF qui bloque uniquement /wp-admin, ou une boucle HTTPS qui touche surtout la page de login. Commencez par Solution 1 (plugins), puis Solution 3 (HTTPS/URL).

Renommer le dossier plugins, ça supprime mes réglages ?

Non. Vous désactivez les plugins, mais leurs données restent en base. Quand vous remettez le dossier et réactivez, les réglages reviennent (sauf plugins qui “nettoient” à la désactivation, ce qui est rare et généralement annoncé).

Je n’ai pas de debug.log, c’est normal ?

Oui si WordPress n’a pas pu écrire dans wp-content (permissions), ou si l’erreur se produit avant l’initialisation complète. Dans ce cas, regardez les logs serveur (error_log).

J’ai “ERR_TOO_MANY_REDIRECTS” uniquement sur la page de login

Ça pointe presque toujours vers un mismatch HTTP/HTTPS, un cookie de domaine, ou une valeur incohérente de home/siteurl. Corrigez ces options (Solution 3) et testez en navigation privée.

Je suis sur Elementor/Divi/Avada et l’admin casse après une mise à jour

Désactivez d’abord les addons (packs de widgets) puis le builder si nécessaire. Vérifiez aussi la mémoire PHP : ces builders consomment plus en admin, donc un memory exhausted est fréquent.

Est-ce que je peux “réinstaller WordPress” pour corriger ?

Réinstaller le core peut aider si des fichiers WordPress ont été modifiés, mais ce n’est pas la première étape. La majorité des blocages wp-admin viennent de wp-content (plugins/thèmes/snippets) ou de la config serveur.

J’ai une 403, mais seulement depuis mon IP

Ça ressemble à un blocage WAF (Cloudflare, ModSecurity) ou à une règle anti-bruteforce. Testez via un autre réseau (4G), puis vérifiez les règles de sécurité côté hébergeur/plugin.

Que faire si je n’ai ni FTP ni accès hébergeur ?

Sans accès fichiers ni base, vous êtes limité. Essayez de récupérer l’accès via votre hébergeur (reset accès, activer SFTP), ou demandez à une personne ayant les accès. C’est aussi une bonne raison de garder un accès “owner” documenté.

Dois-je laisser WP_DEBUG activé ?

Non sur un site public. Gardez plutôt WP_DEBUG à false et activez des logs serveur/monitoring. Pendant le dépannage, WP_DEBUG_LOG est très utile, mais retirez-le une fois la cause corrigée.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.