Un site chez un client transport nous a fait perdre une matinée entière avant qu’on comprenne le vrai coupable : l’éditeur Elementor s’ouvrait, affichait sa mascotte animée pendant l’infini, puis rien. Aucun message d’erreur visible pour l’utilisateur, juste une roue qui tourne. Ce symptôme unique a en réalité une dizaine de causes possibles, et les traiter dans le mauvais ordre fait perdre un temps considérable.
Voici la méthode que nous appliquons désormais systématiquement : diagnostic avant correctif, jamais l’inverse. La console JavaScript du navigateur et les logs PHP donnent presque toujours la réponse en moins de cinq minutes.
Symptôme : la roue tourne sans fin
L’écran de chargement d’Elementor correspond à une phase précise : le navigateur charge l’interface JavaScript de l’éditeur, puis effectue une requête AJAX vers admin-ajax.php (action elementor_editor_get_config et consorts) pour récupérer la configuration du site — widgets disponibles, contrôles, kit actif. Si cette requête échoue, timeout, ou renvoie une erreur PHP au lieu de JSON, l’éditeur reste bloqué indéfiniment sans message clair.
Étape 1 : ouvrir la console du navigateur
Avant tout, ouvrez les outils de développement (F12), onglet Console, puis rechargez la page de l’éditeur. Deux types d’indices apparaissent généralement :
- Une erreur JavaScript explicite, souvent liée à un conflit avec le script d’un autre plugin.
- Dans l’onglet Réseau, la requête vers
admin-ajax.phprenvoie un code 500, 503 ou un contenu HTML au lieu de JSON — signe d’une erreur PHP fatale côté serveur.
Si la requête renvoie du HTML commençant par une trace d’erreur PHP, la cause est presque toujours serveur. Si elle ne part même jamais, ou est bloquée avec un code 403, il faut regarder du côté de la sécurité.
Cause n° 1 : memory_limit insuffisant
L’éditeur Elementor charge en une fois de nombreux composants PHP et JavaScript : widgets natifs, widgets Pro, contrôles, styles. Sur un hébergement mutualisé avec un memory_limit par défaut à 64 ou 96 Mo, la limite est souvent atteinte pendant la construction de la configuration, provoquant une erreur fatale silencieuse côté PHP.
// Dans wp-config.php, avant la ligne "That's all, stop editing!"
define( 'WP_MEMORY_LIMIT', '256M' );
Elementor recommande officiellement un minimum de 256 Mo pour un confort d’édition correct, davantage si le site utilise de nombreux plugins d’extension de widgets (essential addons, widgets tiers).
Cause n° 2 : conflit avec un autre plugin
La méthode la plus fiable reste la désactivation méthodique : désactivez tous les plugins sauf Elementor et Elementor Pro, rouvrez l’éditeur. S’il s’ouvre, réactivez un par un jusqu’à identifier le coupable.
- Désactiver tous les plugins non essentiels.
- Tester l’ouverture de l’éditeur.
- Réactiver un plugin, retester, répéter.
- Une fois le plugin fautif identifié, chercher un correctif ou une alternative côté éditeur du plugin.
Cause n° 3 : mod_security ou un pare-feu applicatif
Certains hébergeurs mutualisés activent des règles mod_security agressives qui bloquent les requêtes POST contenant certains motifs (balises HTML dans un champ, mots-clés considérés suspects). L’éditeur Elementor envoie régulièrement du contenu HTML complet via AJAX pour sauvegarder vos modifications : une règle mal calibrée peut intercepter ces requêtes avec un code 403, sans que rien ne s’affiche côté WordPress.
Le signe distinctif : la requête AJAX échoue avec un 403 renvoyé directement par le serveur web, avant même d’atteindre PHP. Il faut alors contacter le support de l’hébergeur pour faire exclure les routes admin-ajax.php et wp-json/elementor/* des règles les plus strictes, ou demander une liste blanche pour l’IP de votre atelier de développement.
Cause n° 4 : un cache trop agressif sur l’admin
Plus rare, mais déjà rencontré : un plugin de cache qui met en cache des pages de l’administration, y compris les réponses AJAX. La configuration doit toujours exclure /wp-admin/ de tout cache de pages, sans exception.
Notre réflexe sur un nouveau site client : vérifier le memory_limit effectif via
phpinfo()avant même d’ouvrir l’éditeur pour la première fois. Cela évite neuf incidents sur dix avant qu’ils ne se produisent.
Prévention
Une checklist simple à appliquer sur chaque nouveau projet limite drastiquement ce type d’incident :
- Fixer
WP_MEMORY_LIMITà 256M minimum dès l’installation. - Exclure
/wp-admin/de tout cache de page. - Documenter les règles mod_security actives chez l’hébergeur avant de démarrer.
- Limiter le nombre de plugins d’extension de widgets Elementor à ce qui est réellement utilisé.
En résumé
Un écran de chargement bloqué n’est jamais un hasard : c’est toujours une requête AJAX qui échoue quelque part entre le navigateur et PHP. La console réseau du navigateur donne la nature de l’échec en quelques secondes, ce qui évite de tester des correctifs au hasard. Dans l’ordre de fréquence que nous observons sur nos projets : memory_limit, conflit de plugin, puis règles de sécurité serveur.
