Divi 5 : corriger les bugs fréquents après installation

Si vous venez d’installer Divi 5 et que votre site passe soudain en “mise en page cassée”, que le Visual Builder refuse de se charger, ou que vous voyez des erreurs REST dans la console, vous êtes dans un cas très courant : un mélange de cache, d’ordre de chargement des scripts, et de sécurité (nonce/cookies) qui se télescopent.

Le problème

Après installation ou activation de Divi 5 sur WordPress 6.9.4 (avril 2026), certains sites rencontrent des dysfonctionnements immédiats : l’éditeur visuel ne charge pas, les styles ne s’appliquent plus, ou l’administration devient instable.

Voici des messages typiques que je vois dans les logs PHP, dans la console du navigateur, ou dans les réponses réseau (onglet “Network”).

Uncaught TypeError: Cannot read properties of undefined (reading '...')

REST API: 401 Unauthorized /wp-json/...

403 Forbidden (CSRF token missing or incorrect)

Failed to load resource: the server responded with a status of 404 (Not Found) /wp-content/themes/Divi/...

There has been a critical error on this website.

Où ça apparaît :

Front-end : CSS manquants, menu sans style, modules Divi non alignés, animations absentes.
Admin : Visual Builder qui boucle (“Loading…”) ou écran blanc sur l’éditeur.
API : erreurs sur /wp-json/ (REST API) et requêtes AJAX (souvent en 401/403).

Circonstances typiques :

Juste après l’installation de Divi 5 (ou migration Divi 4 → Divi 5).
Après une mise à jour WordPress 6.9.x ou un plugin de cache/CDN activé.
Après activation d’un plugin de sécurité/WAF (pare-feu applicatif) ou règles serveur plus strictes.

À qui ça s’adresse : blogueurs débutants (mais je donne aussi des vérifications “pro”). À la fin, vous saurez isoler la cause, corriger proprement (sans bricoler le core), et valider que Divi 5 charge bien ses assets et que l’éditeur communique correctement via REST/AJAX.

Résumé rapide

90% des cas : cache (plugin/CDN/navigateur) + optimisation JS/CSS qui casse l’ordre de chargement.
Erreurs 401/403 REST : nonce/cookies bloqués (plugin de sécurité, WAF, règle ModSecurity, “SameSite”).
Visual Builder en boucle : REST API inaccessible, ou JS minifié/retardé (“defer/delay”) trop agressif.
404 sur fichiers Divi : réécriture (permalinks), chemin CDN, ou permissions.
Erreur 500 / critique : PHP trop bas, mémoire insuffisante, ou snippet cassé dans functions.php.

Les symptômes

Voici les symptômes les plus fréquents après installation de Divi 5, classés du plus “visible” au plus “piégeux”.

Mise en page sans style : typiquement, les CSS Divi ne se chargent pas ou sont remplacés par une version en cache.
Le Visual Builder ne charge pas : écran “Loading” infini, ou retour à l’admin sans erreur claire.
Modules qui ne répondent pas : clics inactifs, glisser-déposer impossible, popups qui ne s’ouvrent pas.
Erreurs dans la console : TypeError, chunk load failed, erreurs de CORS, 401/403 sur /wp-json/.
Erreur 500 / écran blanc : souvent un conflit plugin, une limite mémoire, ou un code copié au mauvais endroit.
Shortcodes Divi affichés en texte : contenu importé mais builder non actif, ou conflit avec un plugin qui filtre the_content.
Problèmes “uniquement sur production” : CDN, cache serveur, HTTP/2 push, minification, ou règles WAF.

Tableau de diagnostic rapide (très utile quand on débute et qu’on ne sait pas par où commencer).

Symptôme	Cause probable	Vérification	Solution
Style cassé / CSS absent	Cache + minification CSS/JS	Onglet Network: CSS en 404 ou non chargé	Désactiver optimisation, exclure Divi, purger caches
Builder “Loading…”	REST bloquée (401/403) ou JS retardé	Console + Network sur /wp-json/	Exclure /wp-json/, corriger nonce/cookies, WAF
Erreur 500 / critique	PHP/mémoire/snippet cassé	WP_DEBUG + logs serveur	Augmenter mémoire, corriger code, conflit plugin
404 sur des assets	Permaliens / rewrite / permissions	Réglages > Permaliens + test direct URL fichier	Régénérer permaliens, vérifier .htaccess/Nginx
Contenu Divi en shortcode	Builder non actif / filtre contenu	Désactiver plugins, vérifier thème actif	Réactiver Divi, isoler plugin qui filtre

Pourquoi ça arrive

Version débutant : Divi 5 est un constructeur visuel. Il charge beaucoup de fichiers (CSS/JS) et fait dialoguer votre navigateur avec WordPress via des requêtes internes (REST API et AJAX). Si un cache, une optimisation ou une sécurité bloque ou modifie ces échanges, vous voyez des symptômes très variés.

Version technique : Divi 5 dépend d’un chargement cohérent des scripts (ordre, dépendances, chunks), de cookies de session valides, et de nonces WordPress. Un nonce est un jeton de sécurité temporaire qui empêche certaines attaques (CSRF). Si un plugin retarde/diffère des scripts (defer/delay), minifie en cassant un module JS, ou si un WAF bloque des requêtes REST, le builder se retrouve “à moitié chargé”.

Causes probables (du plus fréquent au plus rare) :

Optimisation agressive (cache, minification, combinaison, “delay JS”, CDN) qui change l’ordre ou sert des fichiers obsolètes.
Blocage REST/AJAX (plugin de sécurité, WAF, règles serveur, cookies/nonce) → 401/403.
Conflit plugin (souvent : optimisation, sécurité, traduction, ou un plugin qui filtre le contenu).
Limites serveur (mémoire PHP, OPcache, timeouts) → erreurs 500 ou “critical error”.
Réécriture/permalinks cassés après migration → 404 sur endpoints ou assets.
Erreur humaine : snippet copié dans le mauvais fichier, point-virgule oublié, hook inadapté.

Compatibilité page builders : vous pouvez avoir Divi 5 installé même si vous utilisez parfois Elementor ou Avada sur d’autres pages. Les conflits arrivent surtout quand plusieurs builders injectent leurs propres scripts globaux (optimisation, lazy-load, librairies). Les solutions ci-dessous restent valables : elles ciblent WordPress 6.9.4 et le chargement correct des assets, pas un “truc Divi-only” fragile.

Prérequis avant de commencer

Avant toute modification, sauvegardez. J’ai vu trop de sites cassés par un simple copier-coller dans functions.php.

Sauvegarde : fichiers + base de données (idéalement via votre hébergeur).
Environnement de test : une copie staging si possible.
Versions : WordPress 6.9.4, PHP 8.1+ recommandé (8.2/8.3 souvent plus confortable), Divi 5 à jour.
Activer le debug WordPress (temporairement) pour voir les erreurs PHP.
Outils :
- Query Monitor (requêtes, hooks, erreurs PHP, REST).
- Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs).
- Accès à la console navigateur (Chrome/Firefox) + onglet Network.

Activer WP_DEBUG (sur staging, ou temporairement sur prod) dans wp-config.php :

/**
 * Active le debug WordPress (à utiliser temporairement).
 * À 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 ); // Évite d'afficher les erreurs aux visiteurs

Référence officielle : Debugging in WordPress.

Solution 1 : réparer les CSS/JS Divi 5 qui ne se chargent pas (enqueue, cache, ordre)

Quand Divi 5 “perd” ses styles ou que l’éditeur charge sans interactivité, la cause n°1 est un plugin de performance qui :

combine/minifie des scripts en cassant des modules,
retarde (“delay”) des scripts indispensables,
sert une version en cache d’un fichier qui a changé après mise à jour.

Diagnostic rapide :

Ouvrez votre page en navigation privée.
F12 → onglet Network → filtrez sur “CSS” puis “JS”.
Rechargez (Ctrl+F5). Cherchez des 404, 403, ou des fichiers servis depuis un domaine CDN inattendu.

Le cas classique : “je combine/minifie tout”

Vous avez peut-être ajouté un snippet trouvé sur un vieux tutoriel (souvent pré-WordPress 6.5) qui force le “defer” sur (presque) tous les scripts. Avec Divi 5, c’est une recette pour un builder instable.

AVANT (cassé) : code typique collé dans functions.php (thème enfant) ou un plugin de snippets.

add_filter( 'script_loader_tag', function( $tag, $handle ) {
	// MAUVAISE IDÉE : on diffère presque tout, sans exclusions.
	if ( false === strpos( $tag, 'defer' ) ) {
		$tag = str_replace( '<script ', '<script defer ', $tag );
	}
	return $tag;
}, 10, 2 );

Pourquoi ça casse : certains scripts doivent s’exécuter dans un ordre précis, ou avant que le DOM ne soit “prêt”. En différant tout, vous changez l’ordre réel d’exécution. J’ai souvent vu ce bug sur des sites qui utilisaient aussi un plugin de cache qui “delay JS” : double peine.

APRÈS (corrigé) : on conserve une optimisation raisonnable, mais on exclut les scripts critiques (Divi/Builder, jQuery si nécessaire, et surtout tout ce qui touche à l’éditeur). Vous collez ce code dans functions.php du thème enfant ou, mieux, dans un plugin custom (recommandé).

<?php
/**
 * Plugin Name: BPCAB - Correctifs Divi 5 (assets)
 * Description: Exclusions de defer/delay pour éviter les bugs Divi 5 après installation.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Filtre = "hook" qui modifie une valeur.
 * Ici, on modifie la balise <script> générée par WordPress.
 *
 * Objectif : éviter de différer des scripts critiques (Divi/Builder/REST).
 */
add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {

	// Liste d'exclusion : adaptez si vous identifiez des handles précis via Query Monitor.
	$excluded_handles = array(
		'jquery',
		'jquery-core',
		'wp-api',
		'wp-api-request',
		'wp-polyfill',
	);

	// Exclusion "par motif" sur l'URL si le handle n'est pas fiable (cas fréquent avec des bundles).
	$excluded_src_patterns = array(
		'/et-core/',   // souvent utilisé côté Divi/ET
		'/divi/',      // prudence
		'/builder/',   // prudence
		'admin-ajax.php',
		'/wp-json/',
	);

	// 1) Exclusion par handle
	if ( in_array( $handle, $excluded_handles, true ) ) {
		return $tag;
	}

	// 2) Exclusion par motif d'URL
	foreach ( $excluded_src_patterns as $pattern ) {
		if ( is_string( $src ) && str_contains( $src, $pattern ) ) {
			return $tag;
		}
	}

	// 3) Sinon, on peut ajouter defer, mais sans casser le type="module" si présent.
	if ( ! str_contains( $tag, ' defer' ) && ! str_contains( $tag, ' type="module"' ) ) {
		$tag = str_replace( '<script ', '<script defer ', $tag );
	}

	return $tag;

}, 10, 3 );

Où coller ce code :

Option propre : créez un fichier wp-content/plugins/bpcab-divi5-fixes/bpcab-divi5-fixes.php, collez le code, puis activez le plugin.
Option “rapide” : functions.php du thème enfant (moins robuste si vous changez de thème).

Sauvegardez avant de modifier. Une parenthèse oubliée dans functions.php suffit à provoquer un écran blanc.

Cache et CDN : le vrai “faux problème”

Avant de toucher au code, faites ces purges dans cet ordre (sinon vous testez un site qui n’existe pas vraiment) :

Purger le cache du plugin (LiteSpeed Cache / WP Rocket / etc.).
Purger le cache serveur (hébergeur) si disponible.
Purger le cache CDN (Cloudflare, etc.).
Vider le cache navigateur (ou navigation privée).

Si vous utilisez Elementor ou Avada en parallèle : appliquez la même logique. Les optimisations “globales” cassent n’importe quel builder moderne.

Solution 2 : corriger les erreurs REST/AJAX (nonce, cookies, sécurité, WAF)

Quand Divi 5 ne peut plus enregistrer, charger le builder, ou récupérer des données, vous voyez souvent :

401 Unauthorized sur /wp-json/
403 Forbidden sur admin-ajax.php
Erreurs “nonce invalid” (parfois visibles uniquement dans la réponse JSON)

Traduction débutant : WordPress refuse une requête car il pense qu’elle n’est pas légitime. Soit le navigateur n’envoie pas les bons cookies, soit un pare-feu modifie/bloque la requête, soit un cache sert une page “connectée” à un visiteur non connecté.

Étape 1 : vérifier que la REST API répond

Test simple : ouvrez cette URL (en étant connecté à l’admin) :

https://votre-site.tld/wp-json/

Vous devez obtenir un JSON (une structure de données), pas une page HTML de blocage. Si vous voyez une page “Access Denied”, un challenge, ou un HTML d’un WAF, vous avez la cause.

Doc officielle REST API : WordPress REST API Handbook.

Étape 2 : cas fréquent — cache qui met en cache les pages admin/éditeur

Certains réglages de cache (ou un CDN mal configuré) mettent en cache des pages qui ne doivent jamais l’être : /wp-admin/, wp-json, ou des endpoints utilisés par le builder.

Sans entrer dans la config spécifique de chaque plugin, la règle est simple :

Excluez /wp-admin/, /wp-json/, admin-ajax.php du cache.
Désactivez temporairement “Delay JS” et “Combine JS” pour tester.

Étape 3 : cas fréquent — plugin de sécurité/WAF qui bloque admin-ajax ou wp-json

J’ai souvent croisé ça avec des règles trop strictes : elles bloquent des requêtes POST vers admin-ajax.php ou /wp-json/, ou elles filtrent certains paramètres.

Diagnostic :

Consultez les logs du plugin de sécurité (événements bloqués).
Consultez les logs serveur (ModSecurity, WAF hébergeur).
Dans Network, ouvrez la requête en 403 et regardez la réponse : parfois le WAF “signe” sa page.

Fix côté WordPress (propre) : s’assurer que WordPress envoie bien les en-têtes no-cache sur les pages sensibles, et éviter qu’un proxy les mette en cache. Ce n’est pas magique contre un WAF, mais ça aide avec certains reverse proxies mal réglés.

Collez dans un plugin custom (ou functions.php du thème enfant) :

<?php
/**
 * Empêche le cache sur les pages où Divi/WordPress ont besoin d'une session cohérente.
 * Utile si un proxy/CDN est un peu trop "zélé".
 */
add_action( 'send_headers', function() {

	// Ne pas toucher au front-end public.
	if ( ! is_admin() && ! wp_doing_ajax() ) {
		return;
	}

	// En admin/AJAX, on force des en-têtes anti-cache.
	nocache_headers();

	// Certains proxies respectent mieux ces directives explicites.
	header( 'Cache-Control: no-store, no-cache, must-revalidate, max-age=0' );
	header( 'Pragma: no-cache' );
}, 20 );

Pourquoi ça aide : Divi 5 s’appuie sur des requêtes authentifiées. Si une réponse est mise en cache et resservie, vous pouvez vous retrouver avec un nonce/cookie incohérent, donc un 401/403.

Étape 4 : corriger un “mixed content” ou un domaine incohérent (www vs non-www)

Divi 5 souffre vite si votre site alterne entre :

http:// et https://
www et non-www

Vérifiez Réglages > Général : “Adresse web de WordPress” et “Adresse web du site” doivent être strictement identiques.

Référence : Nonces (WordPress Security) (utile pour comprendre pourquoi ça casse).

Solution 3 : régler les 404, l’éditeur qui boucle, et les erreurs 500 (permalinks, rewrite, mémoire, PHP)

Cette solution couvre trois familles de bugs qui se ressemblent mais n’ont pas la même cause : 404, boucles de chargement, et erreurs critiques.

Cas A — 404 après installation/migration : permaliens et règles de réécriture

Symptômes :

Des pages fonctionnent, d’autres renvoient 404.
Le builder charge mais certaines requêtes internes échouent.

Fix débutant (sans code) :

Allez dans Réglages > Permaliens.
Ne changez rien, cliquez Enregistrer.

Ça régénère les règles de réécriture (rewrite rules). Beaucoup de 404 “après installation” se règlent comme ça.

Doc officielle : flush_rewrite_rules() (à ne pas appeler à chaque page, voir plus bas).

Cas B — erreur critique / 500 : mémoire PHP et snippets cassés

Si vous voyez “There has been a critical error on this website.”, commencez par regarder wp-content/debug.log (si WP_DEBUG_LOG est actif) ou les logs PHP de l’hébergeur.

Erreur réaliste n°1 : un snippet copié dans le mauvais endroit (ex : dans wp-config.php mais au mauvais emplacement), ou un point-virgule oublié.

AVANT (cassé) : exemple volontairement faux.

define( 'WP_MEMORY_LIMIT', '256M' )  // Point-virgule manquant => fatal error

APRÈS (corrigé) : dans wp-config.php, avant la ligne “stop editing”.

/** Augmente la mémoire PHP côté WordPress (ne remplace pas la limite serveur). */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin/éditeur

Pourquoi : Divi 5 (comme Elementor/Avada) peut solliciter fortement l’admin. Si votre limite est à 128M, vous pouvez avoir des erreurs aléatoires, surtout avec plusieurs plugins.

Référence PHP (limites mémoire, configuration) : PHP memory_limit.

Cas C — boucles de chargement : OPcache et fichiers “pas à jour”

Plus rare, mais je l’ai vu sur des hébergements agressifs : OPcache garde en mémoire de vieux fichiers PHP après mise à jour. Résultat : Divi/WordPress pensent charger une version, le serveur exécute une autre.

Diagnostic : le bug apparaît juste après mise à jour, disparaît “tout seul” quelques heures plus tard, ou après redémarrage PHP-FPM.

Fix : demandez à l’hébergeur de purger OPcache / redémarrer PHP-FPM. Côté WordPress, vous ne pouvez pas forcer ça proprement sans accès serveur (et je déconseille les scripts “opcache_reset()” en prod : risque sécurité si mal protégé).

Vérifications après correction

Ne vous contentez pas de “ça a l’air mieux”. Testez de façon reproductible.

Test front-end : ouvrez une page Divi en navigation privée → le CSS doit être correct dès le premier chargement.
Test builder : ouvrez le Visual Builder, déplacez un module, sauvegardez, rafraîchissez → la modification doit persister.
Test REST : ouvrez /wp-json/ → vous devez voir du JSON, pas un HTML de blocage.
Console : aucune erreur rouge liée à des fichiers manquants (404) ou refusés (403).
Query Monitor : regardez “HTTP API Calls” et “PHP Errors”. Zéro fatal error, et pas de 401/403 répétés.

Si vous utilisez Divi 5 avec Elementor ou Avada sur le même site : vérifiez une page créée avec chaque builder. Un cache mal réglé peut casser un builder et pas l’autre, ce qui donne de faux indices.

Si ça ne marche toujours pas

Procédure de dépannage que j’applique quand le problème est “collant”. Faites-la dans l’ordre : vous évitez de changer 10 paramètres à l’aveugle.

1) Isoler un conflit plugin/thème sans casser le site (Health Check)

Installez Health Check & Troubleshooting, puis :

Activez le mode dépannage (seulement pour vous).
Désactivez tous les plugins sauf Divi (et ceux indispensables).
Testez le builder.

Si ça marche en mode dépannage, vous avez un conflit. Réactivez les plugins un par un, en testant à chaque fois.

2) Vérifier les erreurs PHP et la version PHP

PHP 8.1 minimum recommandé. Si vous êtes en 8.0 ou 7.4 : vous jouez avec le feu (sécurité + compat).
Regardez wp-content/debug.log et les logs serveur.

3) Vérifier les permissions fichiers

Symptôme : 403/404 sur des fichiers dans wp-content/themes/ ou wp-content/uploads/.

Dossiers : 755 (souvent)
Fichiers : 644 (souvent)

Si vous ne savez pas : demandez à l’hébergeur. Ne “chmod 777” jamais : risque sécurité.

4) Vérifier la réécriture (Apache/Nginx)

Si les permaliens ne se régénèrent pas, vous avez peut-être un souci de configuration serveur (mod_rewrite, règles Nginx). C’est fréquent après migration.

Référence : WordPress sur Apache.

5) Vérifier la console navigateur et les requêtes réseau

Je le répète parce que ça fait gagner des heures : si le builder ne charge pas, la console et Network disent presque toujours pourquoi (chunk en 404, 403 WAF, CORS, etc.).

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
“Loading…” infini dans Divi 5	REST API bloquée (401/403), JS retardé	Exclure /wp-json/ et scripts Divi des optimisations, vérifier WAF
CSS absent après mise à jour	Cache CDN/plugin sert une ancienne version	Purger tous les caches (plugin, serveur, CDN, navigateur)
Erreur critique juste après ajout d’un snippet	Code collé au mauvais endroit, point-virgule oublié	Restaurer backup, corriger la syntaxe, utiliser un plugin custom
Shortcodes Divi visibles	Builder désactivé, conflit plugin qui filtre the_content	Isoler via Health Check, désactiver le plugin fautif
“Nonce invalid” / 403 admin-ajax	Cookies bloqués, cache sur pages privées, WAF	Exclure admin/AJAX du cache, vérifier domaine https/www, logs sécurité
Tout marche en local, pas en prod	CDN/WAF/OPcache/optimisation serveur	Désactiver CDN temporairement, purger OPcache via hébergeur, comparer headers

Erreurs humaines que je vois souvent :

Copier le code dans style.css au lieu de functions.php (ou l’inverse).
Confondre action et filtre : une action exécute du code à un moment donné, un filtre modifie une valeur et doit retourner quelque chose.
Utiliser un hook trop tôt (ex : manipuler des scripts avant que WordPress ne les enregistre).
Tester directement sur production sans sauvegarde ni navigation privée.

Variante / alternative

Méthode sans code : repartir d’une configuration “safe” côté performance

Si vous débutez, la meilleure approche est souvent :

Désactiver temporairement minification/combinaison/delay JS.
Vérifier que Divi 5 est stable.
Réactiver les optimisations une par une, en excluant Divi/REST dès que nécessaire.

Ça marche aussi pour Elementor et Avada : vous cherchez le réglage qui casse l’ordre d’exécution JS.

Méthode développeur : isoler les handles exacts à exclure via Query Monitor

Avec Query Monitor, onglet “Scripts”, vous voyez les handles réellement enqueued. Un handle est l’identifiant interne d’un script dans WordPress. Vous pouvez alors exclure précisément ces handles dans le filtre script_loader_tag (Solution 1) au lieu de matcher des bouts d’URL.

Doc officielle sur l’enqueue : wp_enqueue_script().

Éviter ce problème à l’avenir

Évitez les snippets “magiques” qui promettent 100/100 PageSpeed en différant tout. Ils datent souvent d’avant les builders modernes.
Préférez un plugin custom plutôt que coller du code dans functions.php. Vous gardez vos correctifs même si vous changez de thème.
Documentez vos exclusions cache (un simple fichier texte) : /wp-json/, admin-ajax.php, pages de builder.
Mettez à jour par étapes : WordPress, puis Divi, puis plugins. Testez entre chaque.
Surveillez les erreurs : un plugin comme Query Monitor en staging, et des logs propres en prod.

Si vous devez flush les permaliens en code (ex : à l’activation d’un plugin), faites-le uniquement sur activation, jamais à chaque chargement :

<?php
/**
 * Exemple sûr : flush rewrite rules uniquement à l'activation.
 * À placer dans un plugin (pas dans functions.php).
 */
register_activation_hook( __FILE__, function() {
	flush_rewrite_rules();
} );

register_deactivation_hook( __FILE__, function() {
	flush_rewrite_rules();
} );

Pourquoi : flush_rewrite_rules() est coûteux. L’appeler sur chaque page peut ralentir fortement le site.

Ressources

Questions fréquentes

Divi 5 est-il compatible avec WordPress 6.9.4 ?

Oui, dans la pratique c’est une combinaison courante en 2026. Les problèmes après installation viennent plus souvent du cache/optimisation/sécurité que d’une incompatibilité “pure”. Gardez Divi et WordPress à jour, et testez en staging.

Dois-je désactiver mon plugin de cache pour utiliser Divi 5 ?

Non. Mais vous devrez souvent exclure certains endpoints (REST/AJAX) et éviter les options “delay JS” trop agressives. Si vous activez une option et que le builder casse, vous avez trouvé le coupable.

Pourquoi j’ai des 401/403 sur /wp-json/ alors que je suis connecté ?

Le plus fréquent : cookies bloqués (domaine incohérent www/non-www), cache sur pages privées, ou WAF qui bloque des requêtes POST. Vérifiez la cohérence des URLs du site et testez en désactivant temporairement sécurité/CDN.

Est-ce que je peux mettre les snippets dans un plugin “Code Snippets” ?

Oui, mais avec prudence. Un snippet cassé peut encore planter le site si le plugin l’exécute partout. Je préfère un petit plugin custom versionné (même minimal), car vous contrôlez mieux ce qui est chargé.

Le builder marche pour moi, mais pas pour un autre administrateur : pourquoi ?

Souvent un cache navigateur, une extension, ou une politique cookies différente. Faites tester en navigation privée, sans extensions, et comparez les requêtes réseau (401/403).

J’ai une erreur 500 uniquement quand j’ouvre le Visual Builder

Ça pointe vers une limite mémoire, un timeout, ou un fatal error déclenché sur une route spécifique (REST/AJAX). Activez WP_DEBUG_LOG, reproduisez le bug, puis lisez wp-content/debug.log.

Divi 5 + Elementor sur le même site : c’est une mauvaise idée ?

Ce n’est pas “interdit”, mais ça augmente le risque de conflits (scripts globaux, optimisation, CSS). Si vous devez le faire, évitez les optimisations qui combinent/diffèrent tout, et testez chaque builder après chaque mise à jour.

Dois-je “flush permalinks” régulièrement ?

Non. Faites-le quand vous changez de structure de permaliens, migrez le site, ou installez un plugin qui ajoute des routes. En code, uniquement à l’activation/désactivation d’un plugin.

Quelle est la première chose à regarder quand Divi 5 “ne charge pas” ?

La console et l’onglet Network. Vous verrez presque toujours un 401/403 (REST/AJAX), un 404 sur un chunk JS/CSS, ou un script bloqué par une optimisation.