Si vous avez déjà vu “500 Internal Server Error” juste après avoir activé un plugin ou modifié un bout de code, vous avez probablement eu le bon réflexe : rafraîchir… puis paniquer quand tout reste cassé. Une 500 est frustrante parce qu’elle ne dit pas pourquoi ça casse. La bonne nouvelle : sur WordPress 6.9.4 (avril 2026) et PHP 8.1+, on peut presque toujours remonter à la cause en moins de 30 minutes avec une méthode propre.
Le problème
Le navigateur affiche une erreur serveur générique. Selon l’hébergeur, vous voyez l’un de ces messages.
500 Internal Server ErrorOu parfois :
HTTP ERROR 500Ou encore dans certaines configurations Nginx/Cloudflare :
The server returned a "500 Internal Server Error".Ça peut arriver :
- Sur le front-end (page d’accueil, articles, pages Elementor/Divi/Avada).
- Dans l’admin (wp-admin inaccessible, écran blanc après connexion).
- Sur des endpoints AJAX/REST (éditeur de blocs, sauvegarde d’un article, bibliothèque de médias, API REST).
- Sur WP-Cron (tâches planifiées qui échouent en silence, emails non envoyés).
Circonstances typiques que je croise le plus :
- Juste après une mise à jour (WordPress, plugin, thème).
- Après avoir collé un snippet trouvé sur un vieux tutoriel (souvent incompatible PHP 8.1+).
- Après un changement de version PHP dans le panneau d’hébergement.
- Après activation d’un plugin de cache/sécurité qui modifie le serveur (.htaccess, règles Nginx, WAF).
À la fin, vous saurez :
- Obtenir l’erreur exacte (au lieu du simple “500”).
- Isoler rapidement si la cause vient d’un plugin, d’un thème ou du serveur.
- Corriger les cas fréquents (fatal error PHP, .htaccess corrompu, permissions, mémoire, PHP-FPM).
- Remettre votre site en ligne sans bricolage dangereux.
Résumé rapide
- Une 500 est presque toujours un fatal error PHP ou un problème serveur (règles, permissions, limite mémoire, PHP-FPM).
- Commencez par activer les logs (WP_DEBUG + debug.log) et/ou consultez les logs serveur.
- Si vous n’avez plus accès à wp-admin : désactivez les plugins en renommant
wp-content/plugins. - Testez avec un thème par défaut (ou basculez temporairement via la base de données si nécessaire).
- Réparez les classiques : .htaccess, permissions, mémoire PHP, version PHP, cache.
- Une fois le site revenu, installez Health Check et Query Monitor pour confirmer la cause.
Les symptômes
Une erreur 500 se manifeste rarement seule. Voici ce que vous pouvez observer.
- Erreur 500 sur toutes les pages (front + admin) : souvent .htaccess, permissions, PHP-FPM, ou fatal error dès le bootstrap.
- Erreur 500 uniquement sur wp-admin : plugin d’admin, thème qui charge du code côté admin, mémoire insuffisante, WAF.
- Écran blanc (White Screen of Death) sans message : fatal error avec affichage d’erreurs désactivé.
- Éditeur qui ne sauvegarde plus : appels REST en 500, blocage par sécurité/caching, erreur PHP dans un endpoint.
- AJAX en échec (ex: chargement de médias, recherche) :
admin-ajax.phprenvoie 500. - Ça marche en local, pas en production : différence de PHP (8.1 vs 7.x), extensions manquantes, limites mémoire, règles serveur.
- Shortcodes ou modules page builder qui “cassent” : un module Divi/Elementor/Avada déclenche un fatal error dans un hook.
- Erreurs intermittentes : surcharge PHP-FPM, limite de processus, cache/CDN, ou conflit avec OPcache.
Diagnostic express côté navigateur : ouvrez la console (F12) > onglet Réseau, et regardez la requête qui échoue (REST/AJAX). Si vous voyez un 500 sur /wp-json/ ou admin-ajax.php, vous avez une piste claire.
Pourquoi ça arrive
Version simple : le serveur a rencontré une erreur et n’a pas pu générer la page. WordPress n’a pas toujours le temps d’afficher un message propre, donc vous ne voyez qu’un code HTTP.
Ce qui se passe en coulisses : WordPress (6.9.4) démarre, charge wp-config.php, les plugins, le thème, puis exécute des hooks. Un hook est un “point d’accroche” dans l’exécution : une action exécute du code à un moment donné, un filtre modifie une valeur. Si un plugin ou votre thème déclenche une Fatal error PHP (fonction inexistante, type invalide, erreur de syntaxe), PHP s’arrête net et le serveur renvoie 500.
Causes probables (du plus fréquent au plus rare) :
- Erreur PHP après ajout de code (parenthèse manquante, point-virgule oublié, appel à une fonction non chargée).
- Incompatibilité PHP 8.1+ (code ancien : paramètres mal typés, fonctions dépréciées supprimées, erreurs strictes).
- Plugin ou thème bugué (mise à jour récente, conflit entre deux plugins).
- Cache/WAF/CDN (règles de sécurité qui bloquent REST/AJAX, cache qui sert une réponse cassée).
- .htaccess corrompu ou règles réécriture invalides (Apache/LiteSpeed).
- Permissions fichiers/dossiers incorrectes (souvent après migration FTP ou restauration).
- Limite mémoire / timeout (génère parfois 500 selon la config).
- PHP-FPM saturé (Nginx/Apache+FPM) ou crash du pool.
- Extension PHP manquante (rare, mais arrive après changement de version PHP).
Variante classique : “500 uniquement sur une page”. J’ai souvent vu ça sur des pages Elementor/Divi très lourdes : un module déclenche une requête plus gourmande, dépasse la mémoire, ou appelle une fonction d’un plugin désactivé.
Prérequis avant de commencer
Sauvegardez avant de modifier quoi que ce soit. Si vous n’avez plus accès à l’admin, faites au minimum une copie de wp-config.php et du dossier wp-content, et exportez la base si possible via phpMyAdmin.
- Version cible : WordPress 6.9.4, PHP 8.1+ (recommandé). Si vous êtes encore en PHP 7.4/8.0, attendez-vous à des incompatibilités et corrigez d’abord la version PHP.
- Accès nécessaire : FTP/SFTP ou gestionnaire de fichiers de l’hébergeur. Idéalement accès aux logs (cPanel, Plesk, panel custom, ou SSH).
- Outils utiles :
- Query Monitor (diagnostic PHP, requêtes, hooks, REST).
- Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs).
- WP-CLI si disponible : WP-CLI Commands.
Règle d’or : ne modifiez jamais le core (dossier wp-includes, wp-admin). Corrigez via plugin, thème enfant, ou configuration serveur.
Solution 1 : activer les logs et trouver l’erreur PHP réelle
Quand vous voyez une 500, votre objectif n’est pas de “tenter des trucs”. Votre objectif est de lire l’erreur exacte. Une fois l’erreur en main, la correction est généralement évidente.
Où faire la modification
Dans wp-config.php, à la racine de votre WordPress. Sauvegardez le fichier avant.
AVANT (configuration typique qui masque l’erreur)
<?php
// ... contenu existant ...
/* C'est souvent vide ou absent : aucune trace exploitable en cas de 500 */APRÈS (activer le log sans afficher les erreurs aux visiteurs)
<?php
// ... contenu existant ...
/* Sauvegardez avant de modifier : une erreur de syntaxe ici peut bloquer tout le site. */
define( 'WP_DEBUG', true );
/* Écrit les erreurs dans wp-content/debug.log */
define( 'WP_DEBUG_LOG', true );
/* N'affiche pas les erreurs à l'écran (évite de divulguer des infos sensibles) */
define( 'WP_DEBUG_DISPLAY', false );
/* Optionnel : force le non-affichage côté PHP */
@ini_set( 'display_errors', '0' );
/* ... gardez cette ligne en dernier si elle existe déjà */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
Pourquoi ça corrige (ou plutôt : pourquoi ça aide) : la 500 est un symptôme. Là, vous forcez WordPress à écrire l’erreur dans un fichier lisible.
Que lire ensuite
Ouvrez wp-content/debug.log. Cherchez :
- PHP Fatal error
- Uncaught TypeError
- Allowed memory size exhausted
- Call to undefined function
- Class not found
Exemple réel que je vois tout le temps après un copier-coller dans functions.php :
PHP Parse error: syntax error, unexpected token "}" in /wp-content/themes/mon-theme-enfant/functions.php on line 42Dans ce cas, la correction est mécanique : vous avez une accolade en trop, ou une parenthèse manquante.
Exemple “AVANT” (cassé) : snippet collé au mauvais endroit + syntaxe
Où ça casse : wp-content/themes/votre-theme-enfant/functions.php (ou un plugin de snippets). Sauvegardez avant.
<?php
add_action( 'init', 'bpcab_enregistrer_cpt' );
function bpcab_enregistrer_cpt() {
register_post_type( 'livre', array(
'public' => true,
'label' => 'Livres',
) );
} // <-- Jusque-là OK
} // <-- Accolade en trop : fatal error (parse error)Exemple “APRÈS” (corrigé)
<?php
add_action( 'init', 'bpcab_enregistrer_cpt' );
function bpcab_enregistrer_cpt() {
register_post_type(
'livre',
array(
'public' => true,
'label' => 'Livres',
)
);
}
Autre cas fréquent : fonction appelée trop tôt (hook inadapté)
Un hook inadapté peut provoquer une erreur si vous utilisez une API avant qu’elle soit disponible (ou si un plugin n’a pas encore chargé ses classes). Ça peut finir en 500.
AVANT : appel d’une fonction d’un plugin supposé actif, sans vérification.
<?php
add_action( 'init', function () {
// Exemple : vous supposez qu'une fonction de plugin existe
ma_fonction_de_plugin_tiers(); // Fatal error si le plugin est désactivé
} );
APRÈS : vérification défensive + fallback.
<?php
add_action( 'init', function () {
/* On vérifie l'existence avant d'appeler : évite une 500 si le plugin manque */
if ( function_exists( 'ma_fonction_de_plugin_tiers' ) ) {
ma_fonction_de_plugin_tiers();
return;
}
// Fallback : loggez l'info pour corriger proprement ensuite
if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
error_log( '[bpcab] ma_fonction_de_plugin_tiers() indisponible : plugin tiers manquant ?' );
}
} );
Références officielles utiles :
Solution 2 : isoler un conflit plugin/thème sans casser le site
Quand vous n’avez plus accès à l’admin, vous devez reprendre le contrôle “par l’extérieur”. Le but est de revenir à un WordPress minimal, puis de réactiver une chose à la fois.
Étape A — Désactiver tous les plugins (sans wp-admin)
Où : via FTP/SFTP ou gestionnaire de fichiers.
- Allez dans
wp-content/. - Renommez le dossier
pluginsenplugins.off. - Testez votre site et
/wp-admin.
Si le site revient : vous avez un plugin fautif (ou un conflit entre plugins). Remettez le dossier en plugins, puis renommez plugin par plugin :
wp-content/plugins/nom-plugin→nom-plugin.off
Dans mon expérience, les 500 “post update” viennent souvent d’un plugin qui a introduit une dépendance PHP (extension manquante) ou un bug fatal sur une route REST.
Étape B — Tester le thème (y compris Divi 5 / Avada / thème custom)
Si désactiver les plugins ne change rien, testez le thème.
- Renommez le dossier de votre thème actif dans
wp-content/themes/(ex :divi→divi.off,avada→avada.off). - WordPress basculera sur un thème disponible (souvent un thème par défaut s’il est installé).
Note page builders :
- Divi 5 : une 500 peut venir d’un module/extension Divi tiers. Le test “désactiver plugins” le révèle vite.
- Elementor : les 500 sur
/wp-json/ou lors de l’édition sont fréquentes en cas de conflit avec sécurité/cache. Le test plugins + logs est le plus rentable. - Avada : attention aux caches (Fusion/Avada + plugin cache + CDN). Une 500 peut être masquée par une page d’erreur cache.
Étape C — Diagnostic propre via Health Check (si vous avez accès à l’admin)
Si vous pouvez entrer dans wp-admin (même partiellement), installez Health Check & Troubleshooting. Son mode “Troubleshooting” désactive plugins/thème uniquement pour vous, sans impacter les visiteurs. C’est la méthode la plus sûre sur un site en production.
Exemple de code “AVANT/APRÈS” typique d’un conflit
Cas réel : un snippet ajoute un filtre, mais retourne le mauvais type. Sur PHP 8.1+ et des plugins stricts, ça peut déclencher un TypeError et une 500 sur certaines pages.
AVANT (cassé) : le filtre doit retourner une chaîne, mais retourne un tableau.
<?php
/* À coller dans functions.php du thème enfant (ou mieux : un plugin custom) */
add_filter( 'the_content', 'bpcab_filtre_contenu_casse' );
function bpcab_filtre_contenu_casse( $content ) {
// Mauvaise idée : on retourne un tableau au lieu du contenu
return array( 'contenu' => $content );
}
APRÈS (corrigé) : on retourne bien une chaîne.
<?php
add_filter( 'the_content', 'bpcab_filtre_contenu_ok' );
function bpcab_filtre_contenu_ok( $content ) {
/* Un filtre doit retourner la valeur filtrée, ici une chaîne */
return (string) $content;
}
Si vous utilisez un plugin de snippets, désactivez-le aussi : j’ai déjà vu une 500 persistante parce que le plugin de snippets chargeait un code cassé même après changement de thème.
Solution 3 : corriger les causes serveur fréquentes (.htaccess, permissions, PHP-FPM, mémoire)
Quand ce n’est pas un plugin/thème, c’est souvent “en dessous” : règles Apache, permissions, ou ressources PHP.
.htaccess corrompu (Apache / LiteSpeed)
Symptôme typique : 500 sur tout le site, y compris une simple page, parfois juste après modification des permaliens ou installation d’un plugin de cache.
Diagnostic
Renommez .htaccess (à la racine) en .htaccess.off, puis retestez. Si ça revient, le problème est là.
Réparation
Créez un nouveau .htaccess minimal WordPress, puis allez dans Réglages > Permaliens et cliquez “Enregistrer” pour régénérer.
# Fichier : /.htaccess
# Sauvegardez avant de modifier. Ce fichier est critique sur Apache/LiteSpeed.# Les directives ci-dessous ne sont pas du PHP.
# Je les fournis ici comme référence : collez-les dans .htaccess (texte brut).
# 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 officielle : WordPress on Apache
Permissions fichiers/dossiers
Après une migration, je vois souvent des permissions trop strictes (403/500) ou trop ouvertes (risque sécurité). Une 500 peut survenir si PHP n’arrive pas à lire un fichier nécessaire.
- Dossiers : 755
- Fichiers : 644
wp-config.php: souvent 640 ou 600 selon l’hébergement
Si vous avez SSH, vous pouvez corriger (à adapter à votre contexte). Attention : une commande mal lancée au mauvais endroit peut casser d’autres sites sur le serveur.
# À lancer à la racine du site WordPress
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;Référence : Hardening WordPress: File permissions
Limite mémoire / timeouts (souvent déguisés en 500)
Sur des pages lourdes (Elementor, Divi 5, Avada, import de démos), un manque de mémoire peut provoquer une 500 ou un crash PHP.
Dans debug.log, vous verrez souvent :
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted ...Vous pouvez augmenter la mémoire WordPress dans wp-config.php.
<?php
/* À placer dans wp-config.php, avant "That's all, stop editing!" */
/* Sauvegardez avant de modifier. */
define( 'WP_MEMORY_LIMIT', '256M' );
/* Mémoire pour l'admin (éditeur, imports) */
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Si votre hébergeur limite PHP à 128M côté serveur, cette modification ne suffira pas. Dans ce cas, ajustez la limite PHP via le panel (ou demandez au support).
Référence : Increasing memory allocated to PHP
PHP-FPM saturé (Nginx/Apache + FPM)
Symptôme : erreurs 500 intermittentes, surtout en trafic, parfois uniquement sur admin-ajax.php ou wp-json. Les logs serveur montrent des messages FPM (ex : “server reached pm.max_children”).
Vous ne corrigerez pas ça avec un snippet WordPress. Il faut :
- Augmenter les ressources (CPU/RAM) ou ajuster la config FPM.
- Réduire la charge (cache, optimisation, limiter plugins gourmands).
- Vérifier les logs Nginx/Apache + FPM.
Si vous êtes sur mutualisé : transmettez au support l’heure exacte + URL en échec + votre IP. Ça accélère beaucoup.
Version PHP non conforme / extension manquante
WordPress 6.9.4 tourne très bien en PHP 8.1+. Si vous êtes en dessous, des plugins modernes peuvent casser. À l’inverse, si vous venez de passer en PHP 8.3/8.4 et qu’un vieux plugin traîne, vous pouvez aussi avoir une 500.
Vérifiez la version PHP dans l’hébergement, et consultez les exigences PHP côté WordPress :
Tableau de diagnostic rapide (symptôme → vérification → solution)
| Symptôme | Cause probable | Vérification | Solution |
|---|---|---|---|
| 500 partout (front + admin) | .htaccess cassé / fatal error au chargement | Renommer .htaccess, activer debug.log | Régénérer .htaccess + corriger l’erreur PHP |
| 500 après activation d’un plugin | Bug plugin / incompatibilité PHP | Renommer wp-content/plugins | Réactiver plugin par plugin, mettre à jour/remplacer |
| 500 uniquement sur wp-admin | Plugin admin / mémoire / WAF | debug.log + logs serveur + test sans plugins | Augmenter mémoire, désactiver plugin fautif, ajuster sécurité |
| REST API en 500 (éditeur qui ne sauvegarde pas) | Erreur PHP sur route REST / blocage sécurité | Console navigateur + Query Monitor | Corriger fatal error, whitelister /wp-json/ dans WAF |
| 500 intermittente | PHP-FPM saturé / cache/CDN | Logs FPM + corrélation avec trafic | Ajuster FPM / ressources, optimiser, cache correct |
Vérifications après correction
Une fois la 500 disparue, testez méthodiquement. Sinon vous risquez de “croire” que c’est réparé alors que ça cassera sur une action précise (upload, sauvegarde, checkout).
- Front-end : page d’accueil, un article, une page builder (Elementor/Divi/Avada), une page avec formulaire.
- Admin : connexion, édition d’un article, mise à jour d’un menu, upload d’une image.
- REST API : testez
https://votre-site.tld/wp-json/(doit renvoyer du JSON, pas une 500). - AJAX : ouvrez la console navigateur, vérifiez qu’il n’y a pas de requêtes en 500.
- Logs : relisez
wp-content/debug.loget assurez-vous qu’il n’y a plus de “Fatal error”.
Quand tout est stable, désactivez le debug “verbeux” en production (gardez éventuellement le log si vous savez le surveiller). Un debug.log exposé ou énorme est un risque (informations sensibles + espace disque).
Si ça ne marche toujours pas
Voici une procédure qui fonctionne même quand le site est “totalement down”. Suivez l’ordre. Ne sautez pas d’étape.
1) Vérifier les logs serveur (plus fiable que tout)
Selon votre stack :
- Apache :
error_log - Nginx :
error.log - PHP-FPM : log du pool
Vous cherchez l’heure exacte du 500 + le fichier PHP en cause. Si vous n’y avez pas accès, demandez au support : “Pouvez-vous me donner la ligne d’erreur correspondante à telle heure sur telle URL ?”.
2) Forcer un WordPress minimal (plugins off + thème off)
- Renommez
wp-content/plugins→plugins.off - Renommez votre thème actif →
theme.off - Retestez
Si ça ne revient toujours pas, vous êtes probablement sur un problème serveur, un fichier core corrompu, ou un mu-plugin.
3) Vérifier les mu-plugins
Les mu-plugins (Must-Use plugins) se chargent automatiquement depuis wp-content/mu-plugins. Beaucoup de sites gérés (et certains hébergeurs) en installent. Un mu-plugin bugué = 500 persistante même si vous “désactivez tous les plugins”.
- Vérifiez
wp-content/mu-plugins/ - Renommez temporairement un fichier suspect (ex :
xxx.php→xxx.php.off)
4) Vérifier un cache agressif / CDN
J’ai déjà vu une 500 “fantôme” servie par un proxy alors que le serveur répondait déjà correctement.
- Videz le cache du plugin (si accessible).
- Videz le cache serveur (LiteSpeed Cache, Nginx cache, Varnish).
- Si Cloudflare/équivalent : purge, puis test en contournant (mode dev, ou désactivation temporaire).
- Testez en navigation privée + en changeant de réseau (4G) pour éliminer un cache local.
5) Réécriture / permaliens
Si seules certaines URLs cassent (souvent les “jolis permaliens”), régénérez les règles :
- wp-admin > Réglages > Permaliens > “Enregistrer”.
Si vous n’avez pas accès à l’admin, la régénération manuelle passe par .htaccess (Apache) ou la config Nginx (support/hébergeur).
6) Vérifier les fichiers core (corruption / upload incomplet)
Après une mise à jour interrompue, un fichier core peut être incomplet. La méthode propre :
- Re-téléchargez WordPress 6.9.4 depuis wordpress.org/download
- Remplacez uniquement
wp-adminetwp-includes(ne touchez pas àwp-content)
7) WP-CLI (cas avancé, très efficace)
Si vous avez SSH/WP-CLI, vous pouvez lister les plugins et désactiver proprement, même si l’admin est KO.
# Vérifie que WP-CLI voit bien l'installation
wp core version
# Liste les plugins
wp plugin list
# Désactive tous les plugins
wp plugin deactivate --all
# Active un plugin à la fois
wp plugin activate nom-du-plugin
Référence : wp plugin (WP-CLI)
Pièges et erreurs courantes
| Symptôme | Cause probable | Solution recommandée |
|---|---|---|
| 500 juste après avoir collé un code | Code collé dans le mauvais fichier ou syntaxe (; | Activer debug.log, corriger la ligne, tester en staging |
| 500 après mise à jour PHP | Plugin/thème non compatible PHP 8.1+ | Désactiver plugin, mettre à jour, remplacer, ou revenir temporairement à PHP 8.1/8.2 |
| Tout refonctionne après avoir renommé plugins | Conflit entre plugins | Réactiver un par un, garder Query Monitor pour repérer l’erreur |
| 500 seulement sur l’éditeur (Gutenberg) | REST API bloquée (WAF) ou fatal error sur une route REST | Console navigateur + debug.log + whitelisting /wp-json/ |
| 500 intermittente | PHP-FPM saturé / limite ressources | Logs FPM + optimisation + upgrade hébergement |
| Vous “corrigez” mais ça revient | Cache/CDN sert une ancienne réponse | Purge plugin + serveur + CDN + cache navigateur |
| Snippet “cassé” même après changement de thème | Plugin de snippets ou mu-plugin charge toujours le code | Désactiver plugin de snippets / vérifier mu-plugins |
Erreurs que je vois souvent chez les débutants :
- Modifier functions.php du thème parent au lieu du thème enfant : la mise à jour écrase tout, et parfois le fichier devient incohérent.
- Copier un code “2020” utilisant des pratiques obsolètes : sur PHP 8.1+, ça peut devenir fatal.
- Confondre action et filtre : ne rien retourner dans un filtre, ou retourner une valeur dans une action.
- Oublier de vider les caches et croire que “ça ne marche pas”.
- Tester directement en production sans sauvegarde : ça transforme un bug simple en incident.
Variante / alternative
Méthode sans code (plus “débutant-friendly”)
Si vous avez encore accès à wp-admin, la combinaison la plus simple :
- Installez Health Check & Troubleshooting
- Activez le mode Troubleshooting
- Désactivez tous les plugins dans ce mode, testez
- Réactivez un par un jusqu’à reproduire la 500
Méthode plus avancée (développeurs / agences)
Créez un mu-plugin temporaire de diagnostic qui logge l’erreur et coupe proprement certaines fonctionnalités. Utile quand un site est instable et que vous devez tracer sans dépendre de l’admin.
Où : créez wp-content/mu-plugins/bpcab-diagnostic.php (créez le dossier s’il n’existe pas).
<?php
/**
* Plugin Name: BPCAB Diagnostic temporaire
* Description: Logs de diagnostic pour traquer une erreur 500. À supprimer une fois le problème résolu.
*/
/* Sécurité : empêche l'accès direct au fichier */
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
/* Log minimal au chargement */
add_action( 'muplugins_loaded', function () {
if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
error_log( '[bpcab] mu-plugin diagnostic chargé - ' . gmdate( 'c' ) );
}
}, 1 );
/* Capture des erreurs fatales à la fin du script (utile si le serveur ne logge pas bien) */
register_shutdown_function( function () {
$erreur = error_get_last();
if ( empty( $erreur ) ) {
return;
}
$types_fatals = array( E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR );
if ( ! in_array( $erreur['type'], $types_fatals, true ) ) {
return;
}
error_log(
sprintf(
'[bpcab] Fatal capturée: %s dans %s:%d',
$erreur['message'],
$erreur['file'],
(int) $erreur['line']
)
);
} );
Risque : un mu-plugin est chargé à chaque requête. Supprimez-le dès que vous avez trouvé la cause, sinon vous gardez du bruit dans les logs.
Éviter ce problème à l’avenir
- Travaillez en staging : un clone de votre site pour tester mises à jour et snippets.
- Évitez les snippets “magiques” sans source et sans date. Si un code ne mentionne pas PHP 8.1+ et une version WordPress récente, méfiance.
- Gardez un thème enfant (Divi/Avada) et un plugin custom pour vos ajouts. J’ai souvent récupéré des sites où 30 snippets étaient dans le mauvais endroit.
- Surveillez les logs (même une fois par semaine). Une notice aujourd’hui peut devenir un fatal demain après mise à jour.
- Limitez les plugins redondants (3 caches, 2 sécurités, 4 optimiseurs) : c’est un terrain parfait pour des 500 intermittentes.
Bonne pratique : mettre vos snippets dans un mini-plugin (plutôt que functions.php)
Un mini-plugin évite que votre code disparaisse au changement de thème, et il se désactive d’un clic (ou via WP-CLI).
Où : créez wp-content/plugins/bpcab-snippets/bpcab-snippets.php, puis activez-le.
<?php
/**
* Plugin Name: BPCAB Snippets
* Description: Snippets personnalisés du site (WordPress 6.9.4+, PHP 8.1+).
* Version: 1.0.0
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
/* Exemple : un hook (action) exécuté après chargement du thème */
add_action( 'after_setup_theme', function () {
// Code sûr et minimal. Ajoutez vos fonctions ici, testées en staging.
} );
Référence sur les plugins : Plugin Handbook: Plugin Basics
Ressources
- Debugging in WordPress (WP_DEBUG, logs)
- File permissions (hardening)
- WordPress on Apache (.htaccess / mod_rewrite)
- WordPress requirements (PHP/MySQL)
- WP-CLI Commands
- WordPress core sur GitHub (wordpress-develop)
- WordPress Core Trac (tickets)
- Manuel PHP (php.net)
Questions fréquentes
Est-ce qu’une erreur 500 vient toujours de WordPress ?
Non. WordPress peut déclencher la 500 (fatal error PHP), mais un .htaccess cassé, une saturation PHP-FPM, ou un WAF peuvent faire la même chose. C’est pour ça que les logs serveur sont souvent la source la plus fiable.
Pourquoi je vois une 500 mais pas d’erreur dans WordPress ?
Parce que WordPress n’a parfois pas le temps d’écrire quoi que ce soit si l’erreur arrive très tôt, ou parce que les logs sont désactivés. Activez WP_DEBUG_LOG et vérifiez aussi les logs Apache/Nginx/PHP.
Je ne peux plus accéder à wp-admin. Je fais quoi en premier ?
Renommez wp-content/plugins pour désactiver tous les plugins. Si ça ne suffit pas, testez le thème (renommer le dossier du thème actif), puis vérifiez wp-content/mu-plugins.
Est-ce dangereux d’activer WP_DEBUG sur un site en production ?
Ça peut l’être si vous affichez les erreurs à l’écran. Utilisez WP_DEBUG_DISPLAY à false et loggez dans un fichier. Ne laissez pas le debug activé indéfiniment.
Une 500 peut venir d’un plugin de cache ?
Oui. Certains plugins ajoutent des règles serveur (Apache/Nginx), minifient des scripts, ou interfèrent avec REST/AJAX. Si vous suspectez ça, purge cache + désactivation temporaire + test sans cache/CDN.
Pourquoi ça casse seulement sur certaines pages Elementor/Divi/Avada ?
Ces pages peuvent déclencher plus de requêtes, plus de mémoire, ou charger un module tiers. Le debug.log vous dira souvent “Allowed memory size exhausted” ou pointera un fichier de module/plugin précis.
Dois-je réinstaller WordPress ?
Pas en premier. Réinstaller wp-admin et wp-includes peut aider si des fichiers core sont corrompus, mais la majorité des 500 viennent d’un plugin, d’un thème, ou d’une config serveur.
J’ai corrigé le code mais je vois encore la 500.
Videz tous les caches (plugin, serveur, CDN, navigateur). Ensuite, relisez les logs : vous avez peut-être une seconde erreur derrière la première, ou un fichier qui n’a pas été déployé correctement.
Comment éviter de “copier-coller” un snippet qui casse tout ?
Testez en staging, mettez vos snippets dans un mini-plugin, et gardez WP-CLI ou un accès FTP prêt. Un snippet dans wp-config.php ou functions.php sans sauvegarde est la cause n°1 des 500 que je dépanne.