Contexte
Un site WordPress utilisé pour la génération de demandes (formulaires et appels) est devenu indisponible suite à une mise à jour. Le navigateur retournait une erreur HTTP 500, parfois seulement sur /wp-admin, parfois sur l’ensemble du site. L’objectif était de rétablir rapidement le service, puis d’identifier la cause précise afin d’éviter une récidive.
Symptômes observés
- Réponse serveur:
500 Internal Server Error. - Accès admin instable: connexion impossible ou page blanche après login.
- Pages publiques parfois accessibles, mais erreurs lors de requêtes spécifiques.
- Dernier changement rapporté: mise à jour d’un plugin + modification mineure sur un formulaire.
Objectifs du dépannage
- Remettre le site en ligne et stabiliser l’accès
/wp-admin. - Identifier le déclencheur (plugin, thème, config PHP, .htaccess).
- Corriger durablement, sans restauration globale si évitable.
- Améliorer la prévention: sauvegardes, monitoring, procédure de mise à jour.
Diagnostic (méthode)
- Lecture des logs serveur (PHP error log) pour localiser le point d’échec.
- Contrôle PHP: mémoire et temps d’exécution, surtout sur actions admin (plugins, médias).
- Isolation: désactivation progressive des plugins (par lots), puis réactivation un par un.
- Vérification .htaccess (si Apache) et règles de réécriture.
Cause identifiée
Un plugin déclenchait une boucle de traitement au moment du chargement de l’admin (requêtes lourdes + timeout). Le problème était amplifié par une limite mémoire PHP trop basse pour l’environnement actuel.
Exemple technique : activer les logs WordPress (sans affichage public)
Permet d’obtenir une trace sans exposer d’informations aux visiteurs.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Exemple technique : désactiver tous les plugins (FTP) puis réactiver par étapes
Approche rapide quand l’admin est inaccessible.
/wp-content/plugins/
→ /wp-content/plugins-disabled/Exemple technique : diagnostic et gestion via WP-CLI
Très utile quand l’accès admin est instable.
wp plugin deactivate --all
wp plugin activate plugin-a
wp plugin activate plugin-b
wp plugin statusExemple technique : augmenter la mémoire PHP côté WordPress
Selon hébergeur, la limite réelle se règle aussi côté panneau d’hébergement.
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');Exemple technique : régénérer un .htaccess WordPress (Apache)
À utiliser si les règles sont corrompues ou dupliquées.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressCorrectifs appliqués
- Désactivation du plugin à l’origine des requêtes lourdes, puis remplacement par une alternative maintenue.
- Augmentation des limites PHP (mémoire, exécution) pour correspondre à l’usage réel du site.
- Nettoyage des tâches planifiées (cron) liées au plugin, afin d’éviter des erreurs en arrière-plan.
- Contrôle complet des parcours: page d’accueil, pages services, formulaire, admin (plugins, médias).
Résultats
- Site stabilisé, admin accessible et rapide sur les écrans critiques.
- Erreur 500 supprimée sur front et back-office.
- Maintenance future plus sûre grâce à une procédure de test et des limites adaptées.
Prévention mise en place
- Checklist de mise à jour: sauvegarde, staging si disponible, validation pages clés.
- Monitoring disponibilité (uptime) et alertes en cas d’erreur.
- Politique plugins: privilégier ceux maintenus, limiter les doublons fonctionnels.
- Contrôle trimestriel des ressources PHP en fonction de l’évolution du site.
Points clés à retenir
- Une erreur 500 est souvent un mélange de cause applicative (plugin) et de limites serveur (PHP).
- La lecture des logs est la voie la plus courte vers un correctif durable.
- Réactiver les plugins un par un reste la méthode la plus fiable pour isoler un conflit.
