Corriger les conflits de mise en page avec Avada

Si votre page Avada a “l’air cassée” d’un coup (colonnes empilées, marges absurdes, slider qui déborde), le problème vient rarement d’Avada lui-même. Dans mon expérience, c’est presque toujours un conflit d’assets (CSS/JS), un cache trop agressif, ou un CSS global ajouté “vite fait” dans le thème enfant.

Le problème

Les conflits de mise en page Avada (Fusion Builder) se manifestent souvent sans message clair à l’écran. Vous les voyez sur le front-end, parfois uniquement sur mobile, parfois uniquement quand vous êtes connecté.

Quand il y a un message, je retrouve souvent des erreurs JavaScript dans la console navigateur ou des erreurs PHP dans les logs. Exemples réalistes :

Uncaught TypeError: Cannot read properties of undefined (reading 'init')
    at fusionBuilderApp.init (fusion-builder.min.js:1)

Uncaught ReferenceError: jQuery is not defined
    at fusion-something.min.js:1

PHP Fatal error:  Uncaught Error: Call to undefined function fusion_library() in /wp-content/themes/Avada-child/functions.php:42

Quand et où ça apparaît :

Front-end : colonnes qui passent en 100%, containers qui perdent leur largeur, éléments qui se chevauchent.
Admin : l’éditeur Avada Builder ne charge plus, spinner infini, boutons inactifs.
Après une mise à jour : Avada/Avada Core/Avada Builder mis à jour, puis cache/optimisation qui sert encore d’anciens fichiers.
Après activation d’un plugin : optimisation (minify/combine), sécurité (désactivation REST), plugin CSS/JS global, plugin de “performance” qui diffère jQuery.

À qui ça s’adresse : si vous débutez sur WordPress 6.9.4 (avril 2026) et que vous utilisez Avada/Fusion Builder, vous saurez à la fin :

Identifier si le souci vient du CSS, du JS, du cache ou d’un conflit plugin.
Appliquer 3 corrections fréquentes, avec du code sûr (PHP 8.1+) placé au bon endroit.
Tester proprement (console, Query Monitor, Health Check) sans “casser” votre site en production.

Résumé rapide

Commencez par vider tous les caches (plugin, serveur/CDN, navigateur) : c’est la cause n°1 après mise à jour Avada.
Désactivez temporairement l’optimisation CSS/JS (combine/delay/defer) : Avada Builder est sensible à l’ordre de chargement.
Traquez le CSS global ajouté dans “Custom CSS”, le thème enfant ou un plugin : un simple .container{width:100%} suffit à ruiner la grille Avada.
Vérifiez la console navigateur : un jQuery is not defined explique souvent un Builder qui ne répond plus.
Diagnostiquez sans risque avec Health Check (mode dépannage) + Query Monitor, sur WordPress 6.9.4.

Les symptômes

Voici les symptômes que je vois le plus sur Avada (Fusion Builder / Avada Builder). Plusieurs peuvent coexister.

Colonnes empilées : une rangée 1/2 + 1/2 devient 100% + 100% même sur desktop.
Largeur “pleine page” cassée : les containers Full Width deviennent “encadrés” ou au contraire débordent horizontalement (scroll X).
Espaces incohérents : marges/paddings doublés, sections “écrasées”, titres collés.
Polices/icônes manquantes : icônes Font Awesome invisibles, titres en police fallback.
Builder qui ne charge pas en admin : écran blanc, spinner, boutons qui ne répondent pas.
Shortcodes affichés en texte : vous voyez [fusion_text] au lieu du contenu rendu.
Erreurs 404 sur CSS/JS : fichiers dans /wp-content/uploads/fusion-styles/ ou /wp-content/cache/ introuvables.
Différences connecté / déconnecté : typique d’un cache de page ou d’un “delay JS” appliqué uniquement aux visiteurs.

Tableau de diagnostic rapide (utile quand vous ne savez pas par où commencer) :

Symptôme	Cause probable	Vérification	Solution
Colonnes cassées après mise à jour	Cache + fichiers CSS fusionnés obsolètes	Tester en navigation privée + vider cache plugin/CDN	Solution 1 (désactiver combine/delay, purger, re-générer)
Scroll horizontal (débordement)	CSS global sur `html, body` / `.container` / `img`	Inspecteur (Chrome DevTools) → élément qui dépasse	Solution 2 (corriger CSS global, wrapper Avada)
Builder admin ne répond plus	Erreur JS (jQuery, defer, conflit plugin)	Console → erreurs rouges + onglet Network	Solution 1 + Solution 3
Shortcodes affichés	Plugin Avada Builder/Core désactivé, filtre de contenu, bloc HTML brut	Extensions → Avada Core/Builder actifs ?	Solution 3 (ordre de hooks, contenu, sécurité)
CSS/JS 404	Permissions, cache, réécriture, CDN, fichiers générés supprimés	Network → statut 404 + chemin exact	Purger + regénérer + vérifier droits/rewrites

Pourquoi ça arrive

Version simple (débutant) : Avada construit vos mises en page avec une combinaison de CSS (pour la grille, les espacements, le responsive) et de JavaScript (pour les modules interactifs, le Builder, certains effets). Si un plugin modifie l’ordre de chargement, supprime un fichier, ou sert une version en cache, la mise en page part en vrille.

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

Avada et ses plugins (Avada Core / Avada Builder) enregistrent et chargent des assets via l’API WordPress (wp_enqueue_scripts côté front, admin_enqueue_scripts côté admin). Référence : wp_enqueue_script().
Les plugins d’optimisation réécrivent le HTML final : ils combinent, minifient, “diffèrent” (defer/delay) des scripts. Un script Avada qui doit s’exécuter après jQuery ou après un autre module peut se retrouver exécuté trop tôt.
Un CSS global (thème enfant, “Custom CSS”, plugin) peut surcharger des sélecteurs très génériques. J’ai souvent vu un *{box-sizing:border-box} ou un reset agressif casser des calculs de largeur.
Le cache (plugin + CDN + navigateur) peut servir un ancien fichier. Après mise à jour Avada, le HTML pointe vers une nouvelle version, mais le CDN renvoie l’ancienne, ou inversement.

Causes probables, du plus fréquent au plus rare :

Cache/optimisation : combine CSS/JS, delay JS, “remove unused CSS”, cache de page.
CSS global trop large (thème enfant, Custom CSS, plugin) qui touche .container, .row, img, iframe, body.
Conflit JavaScript : jQuery différé, script en double, erreur JS d’un plugin tiers.
Avada Core / Avada Builder désynchronisés : versions incompatibles, ou un des plugins désactivé.
Règles de réécriture / permissions : fichiers générés non accessibles, 403/404 sur assets.
Problèmes serveur : HTTP/2 push mal configuré, Brotli/CDN qui réécrit, WAF qui bloque REST/AJAX.

Prérequis avant de commencer

Sauvegardez avant de modifier quoi que ce soit. Ne modifiez jamais le cœur de WordPress ni les fichiers du thème parent Avada : travaillez dans un thème enfant ou un plugin custom.

WordPress : 6.9.4 (ou plus récent).
PHP : 8.1 minimum recommandé (8.2/8.3 souvent plus confortable). Référence : PHP: Supported Versions.
Outils :
- Query Monitor (gratuit) pour voir erreurs PHP, hooks, requêtes, scripts/styles chargés : wordpress.org/plugins/query-monitor.
- Health Check & Troubleshooting pour désactiver plugins/thème uniquement pour vous (mode dépannage) : wordpress.org/plugins/health-check.
Activer les logs (temporairement) via wp-config.php pour capturer les erreurs, selon la doc : Debugging in WordPress.

Exemple de configuration de debug (à remettre à false une fois le diagnostic terminé) :

/**
 * Active le debug WordPress (à désactiver après dépannage).
 * À placer dans wp-config.php, avant "That's all, stop editing!".
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Solution 1 : CSS/JS chargés dans le désordre (priorités, optimisation, cache)

Symptômes typiques : mise en page cassée après mise à jour, modules Avada inactifs, Builder qui ne répond plus, erreurs console jQuery is not defined ou Cannot read properties of undefined.

Le problème vient souvent d’un plugin de performance qui :

combine CSS/JS,
diffère (defer) ou retarde (delay) des scripts,
déplace jQuery dans le footer,
ou supprime des fichiers jugés “inutiles”.

Étape 1 (sans code) : test rapide en mode dépannage

Avec Health Check, activez le mode dépannage (vous seul le voyez), puis :

Désactivez le plugin d’optimisation (Autoptimize, WP Rocket, LiteSpeed Cache, etc.).
Videz le cache Avada (dans Avada > Performance / Cache selon votre version), puis le cache du plugin, puis le cache CDN.
Rechargez la page en navigation privée.

Si tout redevient normal : vous avez confirmé un conflit d’assets. Passez à l’étape 2.

Étape 2 (avec code) : empêcher un “defer/delay” sur les scripts Avada

Certains plugins appliquent defer via le filtre WordPress script_loader_tag. Un filtre est une fonction qui reçoit une valeur et doit la retourner (contrairement à une action qui exécute du code sans retourner une valeur).

Où coller le code : idéalement dans un mu-plugin (plugin must-use) pour qu’il reste actif même si vous changez de thème.
Chemin : /wp-content/mu-plugins/avada-assets-fix.php (créez le dossier mu-plugins s’il n’existe pas).

Sauvegardez avant de modifier. Une parenthèse manquante provoque une erreur 500.

AVANT (exemple de code “cassé” souvent ajouté dans functions.php) :

<?php
/**
 * Exemple de snippet problématique : ajoute defer à (presque) tous les scripts.
 * Je l'ai vu copié depuis des tutoriels anciens.
 */
add_filter( 'script_loader_tag', function( $tag, $handle ) {
	// ERREUR : on defer aussi les scripts qui doivent s'exécuter immédiatement (Avada, jQuery, etc.)
	return str_replace( ' src', ' defer src', $tag );
}, 10, 2 );

APRÈS (on exclut Avada + jQuery + quelques handles fréquents) :

<?php
/**
 * Plugin MU : exclusions defer/delay pour Avada (WordPress 6.9.4+, PHP 8.1+).
 * Fichier : wp-content/mu-plugins/avada-assets-fix.php
 */
defined( 'ABSPATH' ) || exit;

/**
 * Retire "defer" (ou empêche son ajout) sur des scripts critiques.
 *
 * Pourquoi :
 * - Avada Builder et certains modules attendent un ordre précis (dépendances JS).
 * - Si un script est defer alors que son dépendant ne l'est pas, on obtient des erreurs JS.
 */
add_filter( 'script_loader_tag', function( $tag, $handle ) {

	// Liste à adapter : utilisez Query Monitor > Scripts pour voir les handles réels.
	$critical_handles = array(
		'jquery',
		'jquery-core',
		'jquery-migrate',
		// Avada / Fusion (handles fréquents, selon versions)
		'fusion-builder-app',
		'fusion-scripts',
		'avada-scripts',
	);

	if ( in_array( $handle, $critical_handles, true ) ) {
		// On retire defer si un autre plugin l'a injecté.
		$tag = preg_replace( '/sdefer(=(['"]).*?2)?/i', '', $tag );
		$tag = preg_replace( '/sdata-no-defer(=(['"]).*?2)?/i', '', $tag );
		return $tag;
	}

	return $tag;
}, 100, 2 );

Pourquoi ça corrige

Avada s’appuie sur des dépendances JavaScript et un timing d’exécution. Quand un plugin “optimise” trop, vous vous retrouvez avec :

un script Avada exécuté avant jQuery,
ou des modules initialisés avant que le DOM soit prêt,
ou des événements non attachés (boutons inactifs dans le Builder).

En excluant les handles critiques, vous laissez le plugin d’optimisation travailler sur le reste, sans casser Avada.

À vérifier (diagnostic précis)

Console navigateur : l’erreur jQuery is not defined doit disparaître.
Onglet Network : les scripts Avada doivent répondre en 200 (pas 404/403).
Query Monitor > Scripts : vérifiez l’ordre et la présence des fichiers.

Solution 2 : sections “pleine largeur” cassées (container, thème enfant, CSS global)

Symptômes typiques : containers full width qui ne le sont plus, colonnes qui débordent, scroll horizontal, sections qui “collent” au bord, ou au contraire tout est enfermé dans une largeur fixe.

Le déclencheur classique : un CSS global ajouté dans :

Avada > Options > Custom CSS,
Apparence > Personnaliser > CSS additionnel,
le thème enfant (style.css),
un plugin de snippets CSS,
ou un plugin de page builder tiers.

Le piège fréquent : surcharger .container/.row

AVANT (CSS “cassé” que je vois régulièrement) :

/* Exemple problématique : trop générique */
.container {
  width: 100%;
  max-width: 100%;
}

.row {
  margin-left: 0;
  margin-right: 0;
}

Pourquoi c’est dangereux : Avada utilise ses propres wrappers et une grille. Si vous forcez .container ou .row, vous cassez des calculs de marges/paddings et le responsive.

Diagnostic : trouver le CSS qui gagne

Ouvrez la page cassée.
Clic droit > Inspecter (Chrome/Firefox).
Sélectionnez un élément qui déborde (souvent un container).
Regardez l’onglet “Styles” : vous verrez la règle exacte et le fichier qui l’applique.

Si la règle vient de votre thème enfant ou du CSS additionnel, corrigez-la en la limitant au bon contexte.

Correction : scoper votre CSS au lieu de toucher les classes génériques

APRÈS (CSS corrigé, ciblé) :

/* Exemple corrigé : on cible uniquement une zone spécifique */
.page-id-123 .banniere-custom .container {
  max-width: 1200px;
  margin-left: auto;
  margin-right: auto;
}

/* Et si vous voulez du full width, ciblez votre wrapper, pas .container global */
.page-id-123 .banniere-custom {
  width: 100%;
  max-width: 100%;
}

Où coller ce CSS :

Le plus propre : thème enfant > style.css.
OK pour débuter : CSS additionnel (Personnaliser).
Évitez de multiplier les endroits (sinon vous ne savez plus d’où vient la règle).

Cas Avada courant : overflow-x caché “pour masquer” un débordement

J’ai souvent vu des utilisateurs ajouter ceci pour “supprimer le scroll horizontal” :

html, body { overflow-x: hidden; }

Ça masque le symptôme, pas la cause. Le jour où un module a réellement besoin de déborder (slider, animation), il se fait découper. Cherchez plutôt l’élément fautif (DevTools) et corrigez sa largeur/marge.

Option avancée (avec code) : charger un CSS correctif uniquement sur certaines pages

Si vous ne voulez pas toucher au CSS global, chargez un fichier correctif page par page via un hook. Un hook est un point d’accroche dans WordPress : une action ou un filtre. Ici, on utilise l’action wp_enqueue_scripts.

Où coller le code : functions.php du thème enfant (ou plugin custom).
Sauvegardez avant de modifier : une virgule oubliée peut casser le site.

AVANT (mauvaise pratique : CSS inline énorme sur tout le site) :

<?php
add_action( 'wp_head', function() {
	// ERREUR : CSS injecté partout, difficile à maintenir, impact perf
	echo '<style>.container{max-width:100%!important;}</style>';
} );

APRÈS (enqueue propre + ciblage) :

<?php
/**
 * Thème enfant : charge un CSS correctif seulement sur une page.
 * Fichier : wp-content/themes/Avada-child/functions.php
 */
add_action( 'wp_enqueue_scripts', function() {

	// Exemple : ne charger que sur la page ID 123.
	if ( ! is_page( 123 ) ) {
		return;
	}

	wp_enqueue_style(
		'avada-child-layout-fix',
		get_stylesheet_directory_uri() . '/assets/css/layout-fix.css',
		array(), // Dépendances (si besoin, ajoutez le handle du style Avada)
		'2026-04-05'
	);
}, 20 );

Pourquoi c’est mieux : WordPress gère le chargement, le cache navigateur, et vous évitez de polluer toutes les pages.

Solution 3 : shortcodes Fusion non rendus et JS Builder cassé (hooks, REST/AJAX, sécurité)

Symptômes typiques :

Vous voyez des shortcodes Avada en clair (ex : [fusion_text]).
Le Builder charge partiellement, puis se fige.
Des appels réseau échouent (403/401) sur /wp-json/ ou admin-ajax.php.

Cause fréquente : Avada Builder/Core désactivé, ou versions incohérentes

Avada s’appuie sur des plugins compagnon. Vérifiez dans Extensions :

Avada Core : actif
Avada Builder : actif

Si l’un est inactif, certains shortcodes ne seront plus enregistrés, donc WordPress les affiche en texte.

Cause fréquente : un filtre qui “nettoie” le contenu et casse les shortcodes

J’ai souvent croisé ce snippet (copié depuis de vieux articles) qui supprime les shortcodes dans le contenu :

AVANT (cassé) :

<?php
/**
 * Exemple problématique : supprime les shortcodes du contenu.
 * Résultat : Avada ne peut plus rendre ses éléments.
 */
add_filter( 'the_content', function( $content ) {
	// ERREUR : retire tout ce qui ressemble à un shortcode
	$content = preg_replace( '/[[^]]+]/', '', $content );
	return $content;
}, 5 );

APRÈS (on évite de toucher au contenu, ou on limite à un cas précis) :

<?php
/**
 * Correction : ne supprimez pas les shortcodes globalement.
 * Si vous devez nettoyer un contenu, faites-le sur un champ spécifique,
 * ou sur un type de contenu précis, et jamais via une regex globale.
 */
add_filter( 'the_content', function( $content ) {

	// Exemple : ne rien faire sur les pages Avada (le plus sûr pour débuter).
	if ( is_singular() ) {
		return $content;
	}

	return $content;
}, 5 );

Pourquoi ça corrige : Avada utilise des shortcodes (ou des blocs/structures internes selon configuration). Les supprimer au niveau de the_content revient à retirer la “recette” de mise en page.

Cause fréquente : REST API bloquée (sécurité) et Builder qui dépend d’appels API

Certains plugins de sécurité ou snippets bloquent la REST API. Or, l’éditeur moderne WordPress et plusieurs builders s’appuient sur /wp-json/ (même si Avada a ses propres mécanismes).

AVANT (snippet dangereux, trop agressif) :

<?php
/**
 * Exemple courant : bloque TOUTE la REST API.
 * Effets : éditeurs et builders cassés, intégrations KO.
 */
add_filter( 'rest_authentication_errors', function( $result ) {
	if ( ! is_user_logged_in() ) {
		return new WP_Error( 'rest_forbidden', 'REST API désactivée.', array( 'status' => 403 ) );
	}
	return $result;
} );

APRÈS (on limite le blocage, et on laisse au moins les routes nécessaires) :

<?php
/**
 * Version plus prudente : ne bloquez pas la REST API globalement.
 * Si vous devez restreindre, faites-le par route et avec une logique claire.
 *
 * OÙ : plugin custom ou mu-plugin (évitez functions.php si vous testez souvent).
 *
 * Risque sécurité : mal configurer ce filtre peut exposer des données.
 * Testez en staging.
 */
add_filter( 'rest_authentication_errors', function( $result ) {

	// Si une autre auth a déjà échoué, on respecte.
	if ( is_wp_error( $result ) ) {
		return $result;
	}

	$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? (string) $_SERVER['REQUEST_URI'] : '';

	// Exemple : autoriser tout /wp/v2/ et laisser WordPress gérer les permissions.
	// Adaptez à votre politique réelle.
	if ( str_contains( $request_uri, '/wp-json/wp/v2/' ) ) {
		return $result;
	}

	// Bloquer uniquement certaines routes custom (exemple).
	if ( str_contains( $request_uri, '/wp-json/mon-plugin-prive/' ) && ! is_user_logged_in() ) {
		return new WP_Error(
			'rest_forbidden',
			'Accès REST restreint.',
			array( 'status' => 403 )
		);
	}

	return $result;
} );

Référence officielle sur l’API REST : developer.wordpress.org/rest-api.

Cause fréquente : AJAX admin bloqué (nonce/permissions) ou WAF

Si le Builder fait des appels à admin-ajax.php et que vous voyez 403/401, vérifiez :

Plugin de sécurité/WAF (Wordfence, Cloudflare WAF, ModSecurity) qui bloque une requête.
Cache qui met en cache une réponse AJAX (mauvaise config).
Nonce expiré : un nonce est un jeton anti-CSRF. S’il est invalide, WordPress rejette l’action.

Référence sur les nonces : Nonces (WordPress Security).

Vérifications après correction

Après chaque solution, faites les tests dans cet ordre (sinon vous pouvez “valider” un faux positif à cause du cache) :

Purger : cache Avada, cache plugin, cache serveur, cache CDN.
Navigateur : recharge forcée (Ctrl+F5) + test en navigation privée.
Console : plus d’erreurs rouges liées à Avada/jQuery.
Mobile : test responsive (outil dev) + un vrai téléphone si possible.
Connecté/déconnecté : ouvrez une fenêtre privée pour simuler un visiteur.

Si vous utilisez Fusion Builder/Fusion Slider : testez une page “simple” (1 container, 2 colonnes, 1 bouton). Ça permet de voir rapidement si la grille est revenue.

Si ça ne marche toujours pas

Quand ça résiste, je procède toujours de façon méthodique, sinon on tourne en rond.

1) Vérifier les erreurs (logs + Query Monitor)

Ouvrez wp-content/debug.log (si WP_DEBUG_LOG est activé).
Installez Query Monitor et regardez :
- Erreurs PHP
- Scripts/Styles chargés
- Requêtes HTTP

2) Health Check : isoler thème/plugins sans casser le site public

Activez le mode dépannage.
Laissez Avada + Avada Core + Avada Builder.
Désactivez tout le reste.
Réactivez un par un jusqu’à reproduire le bug.

Quand vous trouvez le plugin fautif : cherchez une option “exclude” (exclure scripts Avada du delay/combine) avant de le supprimer.

3) Vérifier les 404/403 sur assets (Network)

Dans DevTools > Network :

Filtrez sur “CSS” puis “JS”.
Repérez les statuts 404/403.
Ouvrez l’URL dans un nouvel onglet : si ça 404, ce n’est pas un souci de navigateur, c’est serveur/réécriture/permissions/CDN.

4) Permaliens / réécriture

Un réflexe utile : aller dans Réglages > Permaliens et cliquer “Enregistrer” (sans changer). Ça régénère les règles de réécriture.

Référence : flush_rewrite_rules() (ne pas appeler ça à chaque page, seulement ponctuellement).

5) Vérifier mémoire PHP

Avada peut être gourmand, surtout avec beaucoup de modules et d’options. Un manque de mémoire peut provoquer des comportements bizarres (et pas toujours une erreur nette).

Référence : Increasing memory allocated to PHP.

6) Dernier niveau : désactiver temporairement tous les caches côté serveur

Cache Nginx/FastCGI
Varnish
CDN (mode développement)

J’ai déjà vu un CDN servir un CSS Avada vieux de plusieurs jours malgré une purge “réussie” côté plugin. Le test ultime : bypass CDN (hosts, ou URL directe origin si possible) pour confirmer.

Pièges et erreurs courantes

Symptôme	Cause probable	Solution recommandée
Erreur 500 après ajout d’un snippet	Code collé au mauvais endroit, point-virgule manquant	Retirer le snippet via FTP, utiliser un mu-plugin, valider la syntaxe
Builder figé, console: jQuery is not defined	Plugin perf qui diffère jQuery	Solution 1 (exclure handles critiques, désactiver delay/defer pour Avada)
Colonnes empilées partout	CSS global sur .container/.row	Solution 2 (scoper le CSS, supprimer les règles génériques)
Tout marche connecté, cassé déconnecté	Cache de page + JS delay différent pour visiteurs	Désactiver cache de page sur pages Builder, purger, exclusions
Shortcodes affichés	Avada Builder/Core inactif ou filtre the_content destructif	Activer plugins Avada, retirer regex “nettoyage”, Solution 3
Fix appliqué mais rien ne change	Cache navigateur/CDN non purgé	Navigation privée + purge CDN + versionner le CSS (query string)
Snippet “defer” ne marche pas	Mauvais hook, mauvaise priorité	Utiliser script_loader_tag avec priorité élevée (100), vérifier handles
CSS/JS 404	Permissions fichiers, dossier uploads/cache supprimé	Réparer droits, regénérer assets, vérifier règles de sécurité serveur

Erreurs que je vois souvent chez les débutants (et qui coûtent du temps) :

Copier le code dans le thème parent au lieu du thème enfant.
Tester directement sur production sans sauvegarde ni staging.
Oublier de vider le cache du plugin ET du CDN (et croire que “ça ne marche pas”).
Utiliser un tutoriel d’optimisation vieux de 5 ans qui “defer tout” (incompatible avec des builders modernes).
Confondre action et filtre : un filtre doit retourner la valeur.

Variante / alternative

Méthode sans code : exclusions dans votre plugin d’optimisation

La plupart des plugins de performance permettent d’exclure :

des scripts par URL ou par mot-clé (fusion, avada),
des pages (éditeur, pages Builder),
ou de désactiver “delay JS” uniquement sur certaines pages.

Si vous débutez, c’est souvent le meilleur compromis : moins de risques qu’un snippet PHP mal collé.

Méthode plus avancée : profiler précisément les assets

Pour les profils techniques, vous pouvez :

Utiliser Query Monitor pour lister les scripts/styles et leurs dépendances.
Comparer le HTML rendu (View Source) entre mode normal et mode dépannage.
Si vous avez WP-CLI, vérifier la config et faire des purges ciblées (selon votre stack).

Référence WP-CLI (officiel) : WP-CLI Commands.

Éviter ce problème à l’avenir

Faites les mises à jour dans l’ordre : WordPress 6.9.4+ → Avada (thème) → Avada Core/Builder → plugins. Puis purge complète des caches.
Évitez les snippets “optimisation magique” qui appliquent defer/async partout. Les builders modernes ont besoin d’un ordre stable.
Centralisez votre CSS : un seul endroit (thème enfant) plutôt que 4 emplacements. Vous retrouverez vos règles.
Scopez votre CSS : préférez .page-id-123 .mon-bloc plutôt que .container global.
Gardez un staging : même un staging “cheap” évite de casser votre site public.
Surveillez la console après chaque ajout de plugin : une seule erreur JS peut casser toute l’UI.

Si vous devez ajouter un snippet, privilégiez un mu-plugin et versionnez vos changements. C’est plus facile à désactiver en urgence via FTP.

Ressources

Questions fréquentes

Dois-je désactiver Avada Builder si je n’édite plus mes pages ?

Non si vos pages existantes en dépendent. Si le contenu est construit avec des éléments Avada, désactiver Avada Builder/Core peut afficher des shortcodes en clair ou casser le rendu.

Pourquoi le problème n’apparaît que sur mobile ?

Souvent parce qu’un CSS global ou une optimisation “critical CSS” ne couvre pas les breakpoints, ou parce qu’un script responsive est retardé. Testez en désactivant temporairement “remove unused CSS” et “delay JS”.

J’ai corrigé le CSS, mais je ne vois aucun changement

C’est presque toujours du cache. Purgez cache plugin + CDN, puis testez en navigation privée. Si vous chargez un fichier CSS, changez son numéro de version (comme 2026-04-05) pour forcer le navigateur.

Où est le meilleur endroit pour coller un snippet PHP ?

Pour du dépannage Avada, je privilégie un mu-plugin (dans /wp-content/mu-plugins/) : il reste actif et vous pouvez le retirer rapidement via FTP si vous faites une erreur.

Quelle est la différence entre une action et un filtre ?

Une action exécute du code à un moment donné (ex : wp_enqueue_scripts). Un filtre reçoit une valeur et doit la retourner modifiée ou inchangée (ex : script_loader_tag).

Est-ce qu’un plugin de cache peut casser Avada ?

Oui, surtout s’il combine/diffère le JavaScript ou s’il met en cache des pages qui ne devraient pas l’être (pages d’édition, pages avec contenu dynamique). Les exclusions par page et par script règlent généralement le problème.

Pourquoi j’ai un écran blanc dans le Builder mais pas sur le site public ?

Parce que l’admin charge des scripts différents. Une erreur JS en admin (ou une restriction REST/AJAX) peut casser le Builder sans affecter le front-end.

Un “reset CSS” peut-il suffire à casser la mise en page ?

Oui. Les resets trop agressifs sur img, iframe, .container, .row ou des règles globales sur box-sizing peuvent casser la grille. Scopez vos règles à votre bloc.

Je vois des 404 sur des fichiers CSS générés : je fais quoi ?

Commencez par purger et regénérer (Avada + plugin cache). Ensuite vérifiez permissions/droits sur wp-content/uploads. Si un CDN est actif, purge côté CDN aussi.