Trouver le plugin en conflit sur WordPress facilement

Si vous avez déjà vu un écran blanc juste après “J’active le plugin”, vous avez probablement vécu un conflit de plugins — et le plus frustrant, c’est que WordPress ne vous dit pas toujours lequel.

Le problème

Un conflit de plugins se manifeste quand deux extensions (ou une extension et votre thème) se marchent dessus : mêmes fonctions, mêmes hooks, mêmes bibliothèques JS, mêmes endpoints REST, ou simplement une erreur PHP déclenchée par une combinaison précise.

Voici des messages typiques que je retrouve dans les logs sur des sites WordPress 6.9.4 (PHP 8.1+) :

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

Fatal error: Cannot redeclare my_plugin_init()
(previously declared in /wp-content/plugins/plugin-a/plugin-a.php:10)
in /wp-content/plugins/plugin-b/plugin-b.php on line 10

Warning: Cannot modify header information - headers already sent by
(output started at /wp-content/plugins/plugin-x/plugin-x.php:1)
in /wp-includes/pluggable.php on line 1535

Quand et où ça apparaît :

Front-end : page blanche, 500, layout cassé, formulaire qui ne part plus, panier WooCommerce bloqué.
Admin : impossible d’accéder à /wp-admin, écran blanc sur l’éditeur, menus qui disparaissent.
AJAX / REST API : erreurs 401/403 (nonce), 404 sur endpoints, ou 500 sur /wp-json/.
Cron : tâches planifiées qui n’exécutent plus rien (souvent visible via des emails d’erreur ou des logs).

Circonstances typiques :

Juste après une mise à jour (plugin, thème, WordPress 6.9.4).
Après l’activation d’un nouveau plugin “simple” (cache, SEO, sécurité).
Après un changement de builder (Divi 5 / Elementor / Avada) ou l’ajout d’un addon.

À la fin, vous saurez :

Identifier le plugin (ou la combinaison) responsable sans tâtonner.
Confirmer la cause via logs, debug et outils de diagnostic.
Appliquer une correction pratique (ou un contournement) sans modifier le cœur de WordPress.

Résumé rapide

Commencez par reproduire le bug et notez “quoi/Quand” (page, action, heure).
Activez WP_DEBUG + log pour obtenir un message exploitable (sans afficher les erreurs aux visiteurs).
Si vous pouvez : utilisez Health Check pour tester des désactivations uniquement pour vous.
Sinon : désactivez les plugins par lots (moitié/moitié), puis isolez.
Avec accès serveur : WP-CLI + logs = diagnostic le plus rapide.
Une fois le coupable trouvé : cherchez une mise à jour, un réglage, ou remplacez le plugin. Ne patcher le code qu’en dernier.

Les symptômes

Un conflit de plugins ne ressemble pas toujours à une “erreur”. Souvent, tout marche “sauf un truc”. Voici les symptômes que je vois le plus en dépannage.

Erreur 500 ou page blanche (WSOD) après activation/mise à jour.
Impossible de se connecter (boucle de login), ou redirection vers /wp-admin/ qui tourne en rond.
Éditeur cassé : blocs qui ne se chargent pas, écran gris, “La réponse n’est pas un JSON valide”.
REST API KO : /wp-json/ renvoie 500 ou 403, Elementor n’arrive plus à charger l’aperçu.
AJAX KO : formulaire qui ne soumet plus, recherche live qui ne répond plus, panier WooCommerce bloqué.
Shortcodes non rendus (affichés en texte) après ajout d’un plugin de cache/minification.
JS/CSS non chargés ou chargés dans le mauvais ordre (souvent après optimisation).
Bug “uniquement en production” (cache, PHP différent, minification activée, CDN).
Hooks non exécutés : un plugin attend un hook, mais un autre interrompt l’exécution via fatal error.
Problèmes de permissions / nonce : 403 “Vous n’avez pas l’autorisation…” après ajout d’un plugin sécurité.

Tableau de diagnostic rapide (symptôme → vérification → solution) :

Symptôme	Cause probable	Vérification	Solution
Écran blanc / 500 après activation	Fatal error PHP (fonction redeclarée, incompatibilité PHP)	Lire wp-content/debug.log ou logs serveur	Désactiver plugin fautif, mettre à jour, corriger le code/contacter l’éditeur
“La réponse n’est pas un JSON valide”	Sortie parasite (echo, BOM) ou erreur PHP	Console navigateur + debug.log	Désactiver plugins par lots, corriger sortie/erreur
Elementor/Divi n’affiche plus l’aperçu	Conflit JS, optimisation agressive, REST bloquée	Console + onglet Réseau (Network)	Désactiver minification, exclure scripts, tester en mode Health Check
Admin très lent	Requêtes DB lourdes, hooks admin surchargés	Query Monitor (requêtes, hooks)	Identifier plugin, désactiver/remplacer, optimiser
403 sur AJAX/REST	Plugin sécurité, règles WAF, nonce cassé	Logs sécurité + réponse HTTP	Ajuster règles, exclusions, vérifier nonces

Pourquoi ça arrive

Version “débutant” : chaque plugin ajoute du code à WordPress. Parfois, deux plugins veulent faire la même chose (ou le font différemment). Quand ils se croisent, ça casse.

Voici ce qui se passe en coulisses (version plus technique) :

WordPress charge les plugins, puis exécute des hooks. Un hook est un “point d’accroche” dans WordPress où du code peut s’exécuter. Il existe des actions (faire quelque chose) et des filtres (modifier une valeur).
Deux plugins peuvent s’accrocher au même hook, dans le mauvais ordre (problème de priorité), ou modifier une donnée attendue par l’autre.
Un plugin peut inclure une bibliothèque PHP/JS qui entre en conflit (versions différentes, noms globaux identiques).
Un plugin peut dépendre d’une fonction qui n’est pas encore chargée (ex : appel à une fonction d’admin côté front).

Causes classées du plus fréquent au plus rare (sur WordPress 6.9.4) :

Incompatibilité après mise à jour : plugin pas encore compatible avec votre version PHP (8.1+) ou votre builder.
Erreur PHP (fatal) : fonction redeclarée, classe redeclarée, appel de fonction inexistante.
Conflit JS : minification/combinaison, scripts chargés deux fois, ordre de chargement cassé.
Plugin de sécurité qui bloque REST/AJAX ou modifie les headers/cookies.
Cache (plugin, serveur, CDN) qui sert une version “ancienne” et vous fait croire que la correction ne marche pas.
Règles de réécriture (permalinks) incohérentes après ajout d’un CPT ou d’un plugin SEO.

Prérequis avant de commencer

Sauvegardez avant toute manipulation. Ne testez pas “au hasard” sur un site e-commerce en production sans plan de retour arrière.

WordPress : 6.9.4 (avril 2026) ou plus récent.
PHP : 8.1 minimum recommandé (vérifiez dans Outils → Santé du site). Référence : versions supportées de PHP.
Une sauvegarde fichiers + base de données (ou un snapshot chez l’hébergeur).
Un environnement de test si possible (staging). Beaucoup d’hébergeurs le proposent.

Outils utiles (gratuits) :

Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs) : plugin Health Check.
Query Monitor (requêtes DB, hooks, erreurs PHP, REST) : plugin Query Monitor.

Activer le debug proprement (sans afficher les erreurs au public) :

Ouvrez wp-config.php (à la racine de WordPress) et définissez ces constantes. Sauvegardez avant de modifier.

/** 
 * Debug WordPress (WordPress 6.9.4+)
 * À placer dans wp-config.php, avant "/* That's all, stop editing! */"
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // Écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // N'affiche pas les erreurs aux visiteurs

Docs officielles : Debug WordPress.

Solution 1 : Isoler le conflit par désactivation structurée (sans casser le site)

Cette méthode marche même si vous n’avez pas WP-CLI ni staging. Elle est plus lente, mais fiable si vous êtes méthodique.

Étape 1 — Revenir à un accès admin (si /wp-admin est cassé)

Si vous ne pouvez plus accéder à l’admin, passez par FTP/SFTP (ou le gestionnaire de fichiers de l’hébergeur) :

Allez dans /wp-content/plugins/
Renommez le dossier du plugin suspect, par exemple :
mon-plugin → mon-plugin-OFF

WordPress désactive automatiquement un plugin si son dossier disparaît. C’est souvent le moyen le plus rapide de récupérer l’admin.

J’ai souvent vu ce problème après l’activation d’un plugin “snippets” ou d’optimisation qui déclenche un fatal error immédiatement.

Étape 2 — Désactivation par lots (méthode “moitié/moitié”)

Objectif : identifier le coupable en réduisant le nombre de tests.

Dans l’admin, allez dans Extensions → Extensions installées.
Désactivez la moitié des plugins (gardez une note).
Testez le bug (même page, même action).
Si le bug disparaît : le coupable est dans la moitié désactivée. Réactivez l’autre moitié et continuez en subdivisant.
Si le bug persiste : le coupable est dans la moitié restée active. Désactivez encore la moitié de ce groupe.

Astuce pratique : faites une liste dans un bloc-notes avec 3 colonnes “Actifs”, “Désactivés”, “Test OK/KO”. Ça évite de tourner en rond.

Étape 3 — Tester les conflits “à deux” (le vrai piège)

Parfois, aucun plugin n’est “le coupable” seul. C’est la combinaison A + B.

Une fois que vous avez trouvé “A”, laissez A actif.
Réactivez les autres plugins un par un jusqu’à faire réapparaître le bug.
Vous obtenez la paire (ou trio) responsable.

Exemple concret : conflit de fonctions redeclarées

Cas réel : deux plugins déclarent la même fonction globale. Sur PHP 8.1, ça finit en fatal error.

AVANT (cassé) — dans /wp-content/plugins/plugin-a/plugin-a.php :

<?php
/**
 * Plugin A
 */

function my_plugin_init() {
    // Code d'initialisation
}
add_action( 'init', 'my_plugin_init' );

AVANT (cassé) — dans /wp-content/plugins/plugin-b/plugin-b.php :

<?php
/**
 * Plugin B
 */

function my_plugin_init() {
    // Autre code d'initialisation
}
add_action( 'init', 'my_plugin_init' );

Résultat :

Fatal error: Cannot redeclare my_plugin_init()

APRÈS (corrigé) — correction côté plugin (idéalement via l’éditeur du plugin, ou via un patch si vous maintenez le code). Le principe : éviter les fonctions globales, utiliser un préfixe unique, ou une classe.

<?php
/**
 * Plugin B (corrigé)
 * Correction : fonction renommée avec un préfixe unique
 */

function plugin_b_my_plugin_init() {
    // Autre code d'initialisation
}
add_action( 'init', 'plugin_b_my_plugin_init' );

Pourquoi ça corrige : en PHP, deux fonctions globales ne peuvent pas avoir le même nom. Le préfixage (ou les namespaces/classes) évite les collisions.

Où appliquer ? Ne modifiez pas directement un plugin du répertoire WordPress.org si vous pouvez éviter : la modification sautera à la prochaine mise à jour. Si vous avez identifié ce cas :

cherchez une mise à jour du plugin,
ouvrez un ticket support chez l’éditeur,
ou remplacez le plugin.

Compatibilité Divi 5 / Elementor / Avada

Sur des sites Divi 5, Elementor ou Avada, les conflits sont souvent liés à :

plugins d’optimisation (minification/combinaison JS),
addons de builder (widgets/modules tiers),
plugins de sécurité qui bloquent l’aperçu (REST/AJAX).

Dans la méthode “par lots”, commencez souvent par désactiver temporairement : optimisation, sécurité, addons de builder. C’est là que je trouve le plus de “coupables”.

Solution 2 : Mode “sans échec” avec Health Check (diagnostic sans impacter les visiteurs)

C’est la méthode la plus “safe” quand vous débutez : vous pouvez désactiver des plugins pour vous uniquement, pendant que le site continue de fonctionner normalement pour les visiteurs.

Ce que fait Health Check (et ce qu’il ne fait pas)

Il active un mode dépannage sur votre session admin uniquement.
Vous pouvez désactiver des plugins et changer de thème sans effet public.
Il ne “répare” rien automatiquement : il sert à isoler.

Installation : Health Check & Troubleshooting.

Étapes (méthode la plus simple)

Installez et activez le plugin.
Allez dans Outils → Santé du site → onglet “Dépannage”.
Cliquez “Activer le mode dépannage”.
Désactivez tous les plugins dans le mode dépannage.
Réactivez uniquement le plugin/builder nécessaire (ex : Elementor, Divi, WooCommerce), puis ajoutez les autres un par un jusqu’à reproduire le bug.

Pourquoi c’est efficace : vous contrôlez l’environnement de test sans casser la prod. Sur des sites à fort trafic, c’est souvent la seule méthode acceptable.

Exemple concret : conflit REST API (Elementor/éditeur) causé par une sortie parasite

J’ai déjà vu un plugin ajouter un echo en dehors de tout hook. Résultat : la réponse REST n’est plus du JSON “propre”. L’éditeur (Gutenberg/Elementor) affiche des erreurs.

AVANT (cassé) — exemple typique dans un plugin (ou un snippet copié trop vite) :

<?php
/**
 * Mauvais exemple : sortie directe au chargement du plugin
 */
echo "debug"; // Sortie parasite : casse AJAX/REST

add_action( 'init', function () {
    // ...
} );

APRÈS (corrigé) — on loggue au lieu d’afficher, et uniquement si nécessaire :

<?php
/**
 * Bon exemple : pas de sortie directe, on loggue en debug
 */
add_action( 'init', function () {
    if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
        // Écrit dans wp-content/debug.log si WP_DEBUG_LOG est activé
        error_log( 'Init exécuté (debug).' );
    }
} );

Où appliquer : si c’est votre code, mettez-le dans :

un plugin custom (recommandé),
ou functions.php du thème enfant (moins idéal),
ou un mu-plugin si vous voulez qu’il soit toujours chargé (voir plus bas).

Si c’est un plugin tiers : contactez l’éditeur. Une sortie directe dans un plugin est un bug.

Note sur les hooks (action vs filtre)

Une action déclenche du code (ex : add_action( 'init', ... )). Un filtre modifie une valeur et doit retourner quelque chose (ex : add_filter( 'the_content', ... )). Confondre les deux crée des comportements bizarres, parfois perçus comme “conflits”.

Docs officielles : Hooks (actions & filtres).

Solution 3 : WP-CLI + logs (la méthode la plus rapide si vous avez accès serveur)

Si vous avez un accès SSH, WP-CLI vous fait gagner un temps énorme. Sur des sites avec 30–80 plugins, c’est souvent la seule méthode “propre”.

Référence officielle : WP-CLI.

Étape 1 — Lister les plugins et désactiver tout (rapidement)

# Liste
wp plugin list

# Désactive tout
wp plugin deactivate --all

Puis réactivez le minimum vital :

# Exemple : réactiver WooCommerce et Elementor
wp plugin activate woocommerce elementor

Testez. Puis réactivez les autres par groupes :

# Réactiver un groupe (exemple)
wp plugin activate plugin-cache plugin-seo plugin-securite

Étape 2 — Lire les logs au bon endroit

Avec WP_DEBUG_LOG activé, le fichier est généralement :

wp-content/debug.log

Commande utile :

tail -n 200 wp-content/debug.log

Si le site plante avant même d’écrire dans debug.log, regardez les logs PHP côté serveur (selon hébergeur : error_log, logs Apache/Nginx, ou interface).

Étape 3 — Capturer un “stack trace” exploitable (option avancée)

Sur certains fatals, vous aurez juste “Call to undefined function…”. Le fichier/ligne est déjà une piste suffisante. Si vous avez besoin d’aller plus loin, Query Monitor peut afficher les erreurs et contexte côté admin.

Query Monitor : plugin Query Monitor.

Exemple concret : appel à is_plugin_active() au mauvais endroit

Erreur fréquente : un plugin appelle is_plugin_active() sans charger le fichier qui la définit. Cette fonction est dans un fichier d’admin. Sur le front-end, elle n’est pas forcément disponible.

AVANT (cassé) — dans un plugin custom ou snippet :

<?php
/**
 * Mauvais exemple : is_plugin_active() appelée sans inclure le fichier admin
 */
if ( is_plugin_active( 'woocommerce/woocommerce.php' ) ) {
    add_action( 'init', function () {
        // ...
    } );
}

APRÈS (corrigé) — inclure explicitement le fichier requis (et éviter de le faire trop tôt) :

<?php
/**
 * Bon exemple : on inclut le fichier qui contient is_plugin_active()
 * À mettre dans un plugin custom (recommandé) ou functions.php du thème enfant.
 */
add_action( 'plugins_loaded', function () {
    // Sauvegardez avant de modifier quoi que ce soit.
    if ( ! function_exists( 'is_plugin_active' ) ) {
        // Fichier d'admin : nécessaire si on veut utiliser is_plugin_active() côté front
        require_once ABSPATH . 'wp-admin/includes/plugin.php';
    }

    if ( is_plugin_active( 'woocommerce/woocommerce.php' ) ) {
        // Votre code dépendant de WooCommerce
        add_action( 'init', function () {
            // ...
        } );
    }
} );

Pourquoi ça corrige : vous garantissez que la fonction existe. Le hook plugins_loaded s’exécute après le chargement des plugins, ce qui évite d’évaluer trop tôt des dépendances.

Docs : Hook plugins_loaded.

Où coller votre code proprement (recommandé)

Si vous ajoutez du code de diagnostic/correctif, évitez de le coller dans un plugin tiers.

Option 1 (recommandée) : créez un plugin custom (ex : site-diagnostics).
Option 2 : functions.php du thème enfant (risque : dépendance au thème).
Option 3 : mu-plugin (chargé automatiquement).

Exemple de mu-plugin (fichier) : créez /wp-content/mu-plugins/diagnostic.php (créez le dossier si besoin).

<?php
/**
 * Plugin Name: Diagnostic site (MU)
 * Description: Petits diagnostics temporaires. À retirer une fois le problème résolu.
 * Author: Vous
 */

// Sécurité : empêche l'accès direct au fichier.
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', function () {
    // Exemple : log d'un passage pour confirmer que WordPress charge bien ce fichier
    if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
        error_log( '[MU Diagnostic] init OK' );
    }
} );

Attention : un mu-plugin est “toujours actif”. N’y laissez pas du code de debug trop bavard.

Vérifications après correction

Une fois le plugin (ou la combinaison) identifié(e) et corrigé(e), testez comme si vous étiez un visiteur et comme si vous étiez un admin.

Front-end : page d’accueil, un article, une page builder, une page avec formulaire.
Admin : édition d’un article, médiathèque, personnalisation, page du plugin concerné.
REST API : ouvrez /wp-json/ dans le navigateur (vous devez obtenir du JSON, pas une page blanche).
Console navigateur (F12) : vérifiez l’absence d’erreurs JS rouges sur les pages concernées.
Cache : videz cache plugin + cache serveur + cache CDN + cache navigateur.
Permaliens : si le bug touche des 404, allez dans Réglages → Permaliens et cliquez “Enregistrer” (ça régénère les règles).

Si vous avez activé WP_DEBUG_LOG, vérifiez que debug.log ne se remplit plus d’erreurs répétées.

Si ça ne marche toujours pas

Quand le conflit n’est pas évident, suivez cette procédure dans l’ordre. Elle évite les fausses pistes.

Reproduisez le problème de façon fiable (même URL, même action, même compte utilisateur).
Vérifiez les versions : WordPress 6.9.4, PHP 8.1+, plugins à jour. Un plugin non maintenu est un suspect sérieux.
Activez le debug (WP_DEBUG_LOG) et récupérez le message exact.
Testez en mode Health Check (si possible) pour isoler sans impacter la prod.
Désactivez les plugins d’optimisation (cache/minify) en premier si le bug est visuel/JS.
Changez temporairement de thème (en mode Health Check) : certains “conflits plugin” sont en fait des conflits plugin/thème.
Vérifiez la mémoire PHP : une limite trop basse peut déclencher des erreurs lors de l’admin/builder.
Inspectez la console : erreurs CORS, 404 sur scripts, erreurs “Unexpected token”, etc.
Vérifiez REST/AJAX : onglet Réseau (Network) → requêtes vers admin-ajax.php et /wp-json/.
Regardez les règles de sécurité : plugin sécurité, WAF hébergeur, Cloudflare. Un 403 n’est pas un “bug plugin” dans 50% des cas.

Si vous suspectez un cache “fantôme”, j’ai une règle simple : après chaque test, videz le cache et changez de navigateur (ou fenêtre privée). Vous éliminez un gros paquet de faux positifs.

Si vous êtes bloqué hors admin et que renommer un plugin ne suffit pas, renommez temporairement le dossier /wp-content/plugins en /wp-content/plugins-OFF. WordPress désactive tout. Ensuite, remettez le nom et réactivez un par un.

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
Vous collez un snippet “correctif” dans le mauvais fichier	Code mis dans un plugin tiers ou dans le thème parent	Utilisez un plugin custom ou le thème enfant. Ne modifiez jamais le core ni le thème parent.
Erreur PHP : Parse error: syntax error	Point-virgule manquant, parenthèse oubliée	Revenez à la dernière modification, comparez ligne par ligne, utilisez un éditeur avec coloration syntaxique.
Le bug “revient” après mise à jour	Vous aviez modifié un plugin du dépôt	Annulez le patch, faites un plugin custom, ou remontez le bug à l’éditeur.
Rien ne change malgré la désactivation	Cache plugin/serveur/CDN	Videz tous les caches + test en navigation privée.
Conflit lié à un hook	Hook inadapté ou priorité incorrecte	Déplacez le code vers `plugins_loaded` ou `init`, ajustez la priorité, testez.
REST/AJAX renvoie 403	Plugin sécurité, nonce cassé, WAF	Testez sans plugin sécurité (mode Health Check), vérifiez nonces et règles WAF.
Fonction “introuvable” (undefined function)	Fonction d’admin appelée côté front, ou dépendance non chargée	Inclure le bon fichier (si approprié) et utiliser le bon hook, ou revoir la dépendance.
Erreur après migration	PHP trop ancien, extensions PHP manquantes	Montez PHP à 8.1+ et vérifiez les modules requis par le plugin.

Le piège le plus fréquent chez les débutants : tester directement en production sans sauvegarde, puis essayer 10 choses à la suite. Au final, on ne sait plus ce qui a “réparé” ou “cassé”. Faites un test = une action = une note.

Variante / alternative

Méthode sans code (recommandée si vous débutez)

Health Check pour isoler sans impacter les visiteurs.
Query Monitor pour voir les erreurs, requêtes lentes, appels HTTP, hooks.

Méthode plus avancée (développeurs) : neutraliser un plugin sur une zone précise

Parfois, vous ne pouvez pas désactiver un plugin globalement (ex : SEO), mais vous devez empêcher son JS de se charger sur une page builder qui casse.

Exemple : empêcher un script d’un plugin de s’enqueue sur l’admin de l’éditeur (principe). Vous devez adapter le handle (nom interne du script) selon le plugin.

AVANT (cassé) — le plugin charge un script partout en admin (exemple conceptuel) :

<?php
add_action( 'admin_enqueue_scripts', function () {
    wp_enqueue_script( 'plugin-x-admin', plugins_url( 'admin.js', __FILE__ ), array(), '1.0', true );
} );

APRÈS (contournement) — dans un plugin custom, vous pouvez retirer le script sur une page précise :

<?php
/**
 * Contournement : désenregistrer un script uniquement sur certaines pages admin.
 * À mettre dans un plugin custom ou mu-plugin (pas dans le core).
 */
add_action( 'admin_enqueue_scripts', function ( $hook_suffix ) {

    // Exemple : ne pas toucher ailleurs, uniquement sur l’éditeur de contenu.
    if ( $hook_suffix !== 'post.php' && $hook_suffix !== 'post-new.php' ) {
        return;
    }

    // IMPORTANT : le handle doit correspondre exactement à celui du plugin.
    // Ici "plugin-x-admin" est un exemple.
    wp_dequeue_script( 'plugin-x-admin' );
    wp_deregister_script( 'plugin-x-admin' );

}, 999 ); // Priorité élevée pour passer après l'enqueue du plugin

Pourquoi ça aide : beaucoup de conflits Divi/Elementor/Avada viennent d’un script injecté partout. En le neutralisant sur les écrans sensibles, vous confirmez la source et vous gardez le reste du plugin.

Risques : vous pouvez casser une fonctionnalité du plugin sur cette page. Testez soigneusement.

Éviter ce problème à l’avenir

Vous n’éviterez pas tous les conflits, mais vous pouvez réduire drastiquement leur fréquence.

Évitez les doublons : 2 plugins de cache + 2 plugins de sécurité + 3 plugins “optimisation” = conflits quasi garantis.
Staging avant mise à jour : testez les mises à jour plugins/builder sur un clone.
Mises à jour groupées intelligentes : mettez à jour 5 plugins, pas 35 d’un coup. Notez ce que vous faites.
Gardez PHP à jour (8.1+) et surveillez les plugins non maintenus.
Centralisez vos snippets : un plugin custom “site-functions” vaut mieux que 12 snippets éparpillés.

Mini check-list avant d’installer un plugin

Date de dernière mise à jour récente (sur wordpress.org).
Compatibilité annoncée avec votre WordPress.
Support actif (tickets récents).
Fonctionnalité unique (pas un doublon).

Bonnes pratiques de code (si vous ajoutez vos propres snippets)

Évitez les collisions : préfixez vos fonctions, et accrochez-vous aux bons hooks.

<?php
/**
 * Exemple : préfixe unique + hook adapté
 * À mettre dans un plugin custom.
 */

// Sécurité : pas d'accès direct
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'init', function () {
    // Votre code
} );

Si vous développez plus sérieusement, passez à des classes (ou namespaces) pour limiter les collisions. C’est souvent là que les “conflits mystérieux” disparaissent.

Ressources

Questions fréquentes

Comment savoir si c’est un conflit de plugins ou un bug de thème ?

Testez avec un thème standard (idéalement via Health Check). Si le bug disparaît en changeant de thème, c’est un conflit plugin/thème ou un bug du thème.

Je ne peux plus accéder à /wp-admin, je fais quoi en premier ?

Renommez le dossier du dernier plugin activé via FTP/SFTP. Si vous ne savez pas lequel, renommez temporairement /wp-content/plugins pour désactiver tout, puis réactivez progressivement.

Pourquoi le bug n’apparaît que pour moi (admin) ?

Les admins chargent plus de scripts (barre d’admin, éditeur, pages de réglages). Un conflit JS ou une erreur PHP dans l’admin peut ne pas toucher les visiteurs.

Pourquoi le bug n’apparaît que sur mobile ?

Souvent un script conditionnel, un cache différent, ou une minification qui sert des bundles distincts. Vérifiez la console mobile (ou émulation) et désactivez l’optimisation pour tester.

Est-ce que désactiver un plugin “casse” mes contenus ?

Ça dépend. Si vos pages utilisent des shortcodes du plugin, ils peuvent s’afficher en texte. D’où l’intérêt de tester via Health Check ou staging.

Elementor/Divi affiche une erreur JSON, c’est forcément un plugin ?

Très souvent oui (sortie parasite, erreur PHP, sécurité, cache/minify), mais pas toujours. Vérifiez debug.log et la console, puis testez en mode Health Check.

Quel est le moyen le plus rapide si j’ai 60 plugins ?

WP-CLI + désactivation par lots + lecture de logs. Vous divisez votre temps par 5 par rapport à des clics dans l’admin.

Dois-je laisser WP_DEBUG activé en permanence ?

Sur un site public, évitez d’afficher les erreurs. Vous pouvez laisser WP_DEBUG_DISPLAY à false et activer temporairement le log en cas de besoin, puis le couper une fois le diagnostic terminé.

J’ai trouvé le plugin coupable, je fais quoi ensuite ?

Mettez à jour, cherchez un réglage, contactez le support avec votre message d’erreur exact, et remplacez le plugin si nécessaire. Si c’est un conflit avec un autre plugin, documentez la combinaison et évitez de les faire cohabiter.

Est-ce que “vider les permaliens” peut résoudre un conflit ?

Ça ne résout pas un conflit de code, mais ça corrige beaucoup de 404 après ajout de CPT, règles SEO, ou changements de structure d’URL. C’est une vérification rapide.