Dépannage WordPress
Erreur de connexion à la base WordPress : diagnostic sans fuite de secret
L’erreur de connexion à la base peut provenir d’un service arrêté, d’une saturation, du réseau, d’identifiants ou droits devenus invalides, ou plus rarement de tables endommagées. Ne copiez jamais le fichier de configuration dans un ticket ou un outil public.
Ce que ce symptôme signifie réellement
Si plusieurs applications sont touchées, l’infrastructure est prioritaire. Si une seule instance échoue après un changement, sa configuration ou son utilisateur sont suspects.
Une réparation de tables n’est pas un premier réflexe : elle écrit dans la base et doit suivre une sauvegarde vérifiée.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Depuis l’hôte applicatif, contrôlez disponibilité du service, socket/port et capacité à se connecter sans afficher les secrets.
- Vérifier processus, espace disque, mémoire et connexions du serveur de base.
- Tester réseau et résolution vers l’hôte configuré.
- Comparer les paramètres à une source secrète autorisée sans les journaliser.
- Lire les erreurs serveur et vérifier l’intégrité en lecture seule.
Correction : appliquer une action ciblée et réversible
Rétablissez le service, le réseau ou les droits confirmés ; ne remplacez pas la base par une copie locale.
- Redémarrer le service seulement après collecte de son état.
- Corriger l’hôte ou les privilèges minimaux du compte applicatif.
- Libérer les ressources sans supprimer les journaux ou sauvegardes utiles.
- Réparer une table uniquement après dump vérifié et test isolé.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Connexion applicative et requêtes de lecture/écriture attendues fonctionnent.
- Comptes et privilèges restent minimaux.
- Aucune donnée ou secret dans les traces.
Quand arrêter et demander une intervention
En cas de corruption, réplication ou volume plein, bloquez les écritures si nécessaire et faites valider le plan de restauration avant toute commande destructive.