Ce guide montre comment diagnostiquer cURL 28 dans WordPress à partir de vérifications ciblées et d’une validation explicite, sans multiplier les changements inutiles. WP_DEBUG_LOG écrit généralement dans wp-content/debug.log seulement si WP_DEBUG est activé et si le processus PHP peut écrire le fichier.
Étapes à suivre
-
1
Identifier les critères déterminants
WP_DEBUG_LOG écrit généralement dans wp-content/debug.log seulement si WP_DEBUG est activé et si le processus PHP peut écrire le fichier.
-
2
Recouper le contexte technique
Renommer le dossier d’un plugin désactive son chargement sans modifier la base, ce qui est utile quand wp-admin est inaccessible.
-
3
Récupération contrôlée
Isoler le plugin ou la couche fautive, garder les logs, puis réactiver un composant à la fois.
-
4
Écarter les erreurs de diagnostic
Supprimer .maintenance, un plugin ou le cache sans noter l’état initial peut faire disparaître le symptôme sans expliquer la cause.
-
5
Valider le résultat
Le site charge avec les logs propres et le composant fautif est identifié, pas seulement désactivé. Les constantes de debug temporaires sont retirées ou adaptées après l’intervention.
Commandes utiles
curl -v https://example.com
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
À retenir
- WP_MEMORY_LIMIT ne peut pas dépasser les limites réellement accordées par PHP/hébergeur ; une erreur mémoire exige de lire memory_limit et le pic.
- Une boucle de redirection peut venir de WordPress, du proxy/CDN, HTTPS ou d’un plugin : vérifier chaque couche séparément.
- Les constantes de debug temporaires sont retirées ou adaptées après l’intervention.
WordPress : enrichir le diagnostic sans masquer la cause
Repères techniques
- WP_DEBUG_LOG écrit généralement dans wp-content/debug.log seulement si WP_DEBUG est activé et si le processus PHP peut écrire le fichier.
- Renommer le dossier d’un plugin désactive son chargement sans modifier la base, ce qui est utile quand wp-admin est inaccessible.
- WP_MEMORY_LIMIT ne peut pas dépasser les limites réellement accordées par PHP/hébergeur ; une erreur mémoire exige de lire memory_limit et le pic.
Récupération contrôlée
Isoler le plugin ou la couche fautive, garder les logs, puis réactiver un composant à la fois.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Pièges spécifiques
- Supprimer .maintenance, un plugin ou le cache sans noter l’état initial peut faire disparaître le symptôme sans expliquer la cause.
- Une boucle de redirection peut venir de WordPress, du proxy/CDN, HTTPS ou d’un plugin : vérifier chaque couche séparément.
Comment valider
- Le site charge avec les logs propres et le composant fautif est identifié, pas seulement désactivé.
- Les constantes de debug temporaires sont retirées ou adaptées après l’intervention.